This is a case where I wouldn't try to re-invent the wheel.
Use the menu-bar path: Tools>Security>User and Group Accounts
Add the new user, associate the user with any groups as appropriate. Set your permissions based on groups and let all your users derive their abilities from their group memberships.
You cannot (and should not) set the password. But you could clear it. The idea is that you, even as a security manager, should never know another person's password. You have the ability to CLEAR the password but not to actually know it. Only the user should have the ability to set his/her own non-blank password.
This falls under the category of TRUST - but I'm not talking about trusting you. I'm talking about trusting the user. Because that privacy of password is a link in the chain of trust that says, "When user XYZ does something, I can legitimately hold XYZ responsible for it. And XYZ knows it, so knows to be careful." If the password is not private, the user has a defense that "the security manager could have done this." If so, then you cannot hold XYZ's feet to the fire when something bad happens.