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.
Related
I'm trying to keep in my app which user is connected. I'm really not sure if I'm doing this correctly. So here is how I plane to do it:
First I use my Slim API to check if the username and password are correct and if has access privilege.
If it returned the username and his privilege level, I will store them in a cookie and use those two information in the app.
The problem is that I'm afraid that if I store the username in a cookie, someone could try to change the cookie and put an other username instead.
Is it alright to only use the username for my requests to the DB as soon as the user is connected (like get all item of a user using the name of the user), or should I use a more secured and efficient way, if there is one?
P.S: I'm not asking how to have my site remember the user when he go back to the site. I'm asking how I should remember the username and other information while my user is still on my site in a secured way.
You should generate a long random number password and store that in a cookie. This random number is essentially just another unique password for this user. So, on the server side, you only store a properly salted hash of this random number. Think of this like a Hash key for that user stored in DB, and you use this HASH key to decrypt the long ramdom password.
You could encrypt these informations in the cookie, so nobody can steal these ones. Each time a user is trying to launch your application check if the credentials in the cookie are still correct (Is this username in your databse ? Is the accreditation level correct for this user ?). So you know if these informations have been changed. If they aren't correct you invite the user to login again.
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.
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.
While developing my app, I suddenly can't login using Auth anymore, according to Cake, the password or username is not correct.
When I track the query, the password (hashed) that Cake is looking for is not the one that the user has. I matched the query password to the User table in MAMP.
What can be the reason of this sudden error? What can Cake make looking for another password that not exists in the user table.
all error logs are clear
I can register a user without any issue
I use everything the standard Cake way (Auth, register process etc)
Many thanks!
well, most likely, you changed the salt value in core.php or hash mehod, or both. That's the only 2 reasons the hash is different for the same password.
I am interested in testing the incoming password field for a particular admin level password. If it matches, I want it to manually have Auth log in with whatever username they want (submitted via form)
My understanding is Auth, in taking the data, will only authorize it if it sees the same email/hashed password in the database. Is there a way to get around this check to manually set it? Even $this->Auth->login(..) will do this check right?
$this->Auth->login($userId)
Auth::login accepts either a username/password combination or simply a user id (the primary key of the user model in the database).
see my answer here: Using username instead of email in CakePHP's Auth Component
It's not the same question, but the idea is, when the login fails, you can intercept it and do what you want.