I have in my web application a role called "Administrator". Users who have this role should be able to modify the information about the registered users.
I am thinking about displaying a table with the user details such as e-mail, username, and be able to change them but I don't know what should I do if a users comes to the office physically, goes to an admin and asks for a password change (yes they can do that). Should the admin just press a reset button over the row and tell the user to check his e-mail when he arrives home and proceed with the recovery? (reset link for example) Or should the administrator reset the user's password and give him his new password in that very moment? The second approach is preferable as I was asked to do that...
I know that the admin shouldn't be able to see the original password as it should be hashed and unknown.
What are your thoughts about this? How would you implement this functionality? Thanks for your help.
There is no one perfect answer for this question. The question of workflow will always be dependent on the specific use-cases of an application and will depend on the context it is built in.
That being said, you are right about one thing - it is horrible, and I do mean horrible, security breach to let an Admin or any other user view a clear text password for someone else. So that's definitely off the table.
In your case, it seems giving the admin the right to change someone's password is the way to go. If you're worried about how it looks, don't be. Google Apps allows domain administrators to change the password for any email account under that domain.
Finally, I would suggest a small additional safety measure. When an Admin changes another user's password, store the old encrypted password in a column, don't delete it. When the admin set's the new password, shoot out an email to the user saying "Your password was changed by the Administrator, if you did not request for this, please click here". When they click on the link in the email, simply overwrite the new password with their old one.
That way in case an Admin is changing passwords without the user requesting it, you have a recourse for the user and the logs will keep you informed of how many time an admin has had a password reset revoked by the user.
Related
I've an Azure AD B2C setup that no matter which email I insert in forgot password email's field it will send the verification code email to that email.
Even if the email doesn't exists in the Users list.
Is this the default behavior?
This is the link I have for recover password
Is there any missing property in the url that force check if the email exists in User list ?
I can confirm the behavior but I couldn't find any reference on why exactly it works that way. Like many things in security, I'm pretty sure it's a design trade-off.
Some services (e.g. Evernote) do the same, i.e. they send a password reset email no matter if the address is registered with them or not.
On the upside, this is an early alert for the user that someone is trying to get access their (nonexistent) account, so a phishing attempt coming from a different website is likely.
The problem is that the user gets an unsolicited email message, and if somebody wants to annoy him/her, all it has to do is to send multiple reset password requests. The user is helpless, there's nothing he can do to stop the emails. So I presume the service mitigates this by limiting the number of reset password requests to a reasonable amount (say max 10/hour, but no more than 3 in any 5 minutes).
Other services (e.g. Dropbox) take the other approach and only send email messages to addresses registered with their service.
this prevents the "email bomb" issue
on the other hand, it doesn't alert the user about the login attempt
Like you, I would argue that the latter approach is better, as the only benefit I can see in the former one is the "early warning" issued to a user that's not even registered with your service. Also, understanding the early warning requires some user sophistication. But obviously Microsoft went the other way.
There's a Password Reset item in the Users blade, but the only options are None and All. Interestingly, the tooltip on this option mentions an nonexistent "Selected" option, so some more fine-grained settings may appear here in the future.
If you want to exists if the users exist before sending messages then you have to edit the SendCode Action . So it will only send verification code when user exists in B2C side.
Below is the very good link which can help you with that.
https://github.com/azure-ad-b2c/samples/tree/master/policies/pwd-reset-email-exists
It is by design. And it will try to send out the verification code without validating whether email exists or not.
By considering security measures this is how it should work.
Hello, StackOverflow Community.
I am currently programming an electron Application which contains a login.
My login is working perfectly but now I do not know how to correctly save the information from the user.
The user should not be able to edit the file or the cookie type of thing so that he cannot abuse the system to be another user without knowing his password.
I hope you can understand my problem and help me out!
When storing user data you shouldn't store it locally at all you should make an authentication key and store it in your database with your user, you then need to store this on the client side too. Normally people store this in memory therefore once the user exists the system they "sign out" if you don't want them to you could save it to some sort of settings file using something like electron-settings or a cookie using the electron API. Once you have this key you should use that to authenticate calls to your API and when doing so you should check that the key is valid for the user who is performing the action.
Example:
When UserA sends a message to UserB you should check that UserA's auth key equals the key which represents UserA in your database.
Using this method will make it hard for other users to "guess" other users keys and also keep user data safe from user interaction.
NOTE: Change the users auth key every time they login to prevent someone from stealing it!
I am looking to build a "reset password" function in my CakePHP app, and reading around the net I have decided to: Have the user type in their email address, send them an email with a link to http://www.mysite.com/users/reset_password/generated_uuid_that_expires_in_24_hours. This will present a form that allows them to change their password. Obviously the hiccup is that I don't know how to log the user in with a temporary password. Am I approaching this correctly? I am thinking that the url I send them would be a hashed version of their email plus a uuid to use as a temp password, and that I would perform a user id lookup based on the email that comes in the url....but still, I wouldn't know how to manually log them in so they can change their password.
I use the session approach.
after using the token from the email the user gets a
Tmp.User.id (as opposed to Auth.User.id)
in the session which will allow him to change the password.
afterwards it will be removed from the session again.
We have a forgot password system that allows a user to create a new password. It is going against Active Directory over LDAPS. Right now once a user goes to create a new password, we have to bind as an admin, change the password to a random string, then bind to the user account with that random string, then change the password to the one they provided. We do this because we have a password history policy of the last 5 used passwords.
This works fine now but the password history has the random strings as one of the previous passwords. Is there any way to bind with a user but without a password? The user would be authenticated before this by a security question.
I do it a different way. I create a dynamic object under the user's entry, expiring in a few days, with a generated uid attribute; send them a link containing that uid; that leads to the change password page, but logged in via a different LoginModule that sees the UID parameter, checks it, and if present and correct logs them in. In other words a kind of 'ticket' login.
The code that did the lookup bound/reconnected itself as the application itself, but that didn't actually matter because the connection for logging in is closed immediately, like all other LDAP connections in the application actually. When anything is done to the user's own entry, e.g. change password, update profile, a reconnect is done as that user using the password which I have saved in the session. When the user does anything else to LDAP it is really the application doing it so an application bind/reconnect is done as above. IOW the application itself is a user (or even several different users with different levels of permission).
Because a UID is much longer than a password, and because the entry containing it expires after a day or two, all this is rather more secure than generating a temporary password and shipping it around. The change password page could also have a security question on it if reached via the ticket login.
There are two password change operations in AD - reset and change. Reset is an administrative operation (which is what you are doing here). When you do a reset, you don't need to supply the current password. Change password is an end user operation whereby the user has to supply their current password in addition to the new password.
If you change your code to do a password reset and run in the context of a user with permissions to reset passwords, you should be good to go. If you need to honor password policy during the reset, there's a way to do this as well with a special LDAP control.
I've created a custom user model in my application. This user model is working fine, but there
are a couple of problems I have with it.
The change password link in the my register.html page doesn't work?
The default password box on the add/edit page for a user is a
little unfriendly.
Ideally, what I'd like is the two password fields
from the change password form on the add/edit user form in the admin,
which will automatically turn convert the entered password into a
valid encrypted password in Django.
This would make the admin system MUCH friendlier and much more suited
to my needs, as a fair number of user accounts will be created and
maintained manually in this app, and the person responsible for doing
so will likely be scared off at the sight of that admin field, or just
type a clear text password and wonder why it doesn't work.
Is this possible / How do I do this?
You can write your own view for editing user, or try to customize admin template for user.