So, I've been playing with asp:PasswordRecovery and discovered I really don't like it, for several reasons:
1) Alice's password can be reset even without having access to Alice's email. A security question for password resets mitigates this, but does not really satisfy me.
2) Alice's new password is sent back to her in cleartext. I would rather send her a special link to my page (e.g. a page like example.com/recovery.aspx?P=lfaj0831uefjc), which would let her change her password.
I imagine I could do this myself by creating some sort of table of expiring password recovery pages and sending those pages to users who asked for a reset. Somehow those pages could also change user passwords behind the scenes (e.g. by resetting them manually and then using the text of the new password to change the password, since a password cannot be changed without knowing the old one). I'm sure others have had this problem before and that kind of solution strikes me as a little hacky. Is there a better way to do this?
An ideal solution does not violate encapsulation by accessing the database directly but instead uses the existing stored procedures within the database...though that may not be possible.
I'm currently implementing an open source user management system on top of Spring + SpringSecurity, and here's how I'm addressing the lost password problem.
The user's account must have a preregistered email address.
To request a reset, the user enters their account name into a form.
A temporary "reset code" is generated and attached to the account, and emailed to the user embedded in a hyperlink.
On receiving the email, the user clicks the link which takes them to a page to enter their new password.
Before accepting the new password, the reset code (from the link) is checked against the stored code, to make sure it is correct and that it hasn't expired.
This avoids sending a password (in clear) in an email message. And it also protects against one person resetting another person's password just to be a nuisance, because the password reset only takes place after the link has been used.
But it does rely on the user's email account being secure, and in the email not being snooped while in transit. For some applications, this maybe an unacceptable risk.
Another piece of the equation is that you need to be really careful about changing a user's registered email addresses. At the very least, the user must enter their current password with the request to change address ... to prevent against hacking via unattended login sessions.
I recommend adding an additional level of checking, here are some options to choose from.
First you can save the requester's IP address in a database, then when they click the reset link compare that with the IP address of their current machine, if they match then reset the password. If the email is intercepted then the person attempting to reset the password must have a matching IP address.
Use a cookie and store a unique value, maybe a GUID, MD5 hash or something. So when the user makes a password reset request a cookie is stored on their machine and in the database, when the user clicks the link the local cookie must match the database value or they will not be able to reset their password.
In general I am totally against ever sending a password in Email, so I like the password reset link option more than a new plain-text password.
Related
I create a link to reset a user password like this :
https://localhost:5001/ResetPassword?id=a33183db-f7f6-45aa-b8dc-7fe101e04682&token=CfDJ8KXvGzIVoh9Knrlx
id is the user id ([dbo].[AspNetUsers].[Id]) and token is the result of UserManager.GeneratePasswordResetTokenAsync
Is there a security risk to put the user id directly in the url? Is it disadvised?
It all depends on your requirements and what you consider secure. In 99% application passing a random (looking) GUID in a link will not give any information to the external attacker. Unless somewhere in your application you have a page that shows user information based on ID (i.e. http://localhost/users/{id} ). But that can be counted as a vulnerability in itself (though depends on application).
So in this case I would say there is no major issue with giving out an ID. However if you are very paranoid, you can omit the ID and only pass a token in the link. Then on password reset page you can ask for an email again, get userID from that email and proceed with password reset.
I have a winform application that have user login form. I store my users login information in database with 3 parameters: username, hashed password, salt:
salt = random string that will be stored in database for every user
hashed password = MD5(MD5(inputPassword) + MD5(salt))
I want to have check box named Remember me in my login form, that when a user enter the correct information and check it, for the next time user open the program, their user information will be entered automatically, user just need to click login button.
I can't save the entered password directly and next time fill the password textBox with it because i know some softwares that can read textBoxes like this and it's not secure.
Question:
How I can do that without saving user password?
If I need to save some information, How encrypt them?
Is it necessary to change my security policy?
Note that this is Client/Server application and login form created for client side.
You can save the hashed value of password in your local database, and you can have a hidden check box, which tells you that you have filled the info from database which is already hashed and while asking authentication you do not need to hash the password value again.
EDIT If the user tries to enter the password manually then you can clear the text box value and alter the check box checked value, so that you know now the value is not the hashed one.
As per my understand, if you want to have remember me functionality then you should/must have your password stored in any form to authenticate the user.
One way is, have 2 functionality in your product. One to have a Hash and this will be in the database and I think you are doing it currently. Apart from this, also have functionality to Encrypt/Decrypt. When remember me is checked then just save the encrypted value in your app.config file. Now when ever the user opens the application again, check for the encrypted password and decrypt to authenticate user.
User dbw just posted my other approach :)
Hope it helps.
IMHO, this can't be done. If you are encrypting/hashing/salting and saving the password in DB then you can't really get it back in plain text.
Of course, you can trick the user (I will tell you how), but need to define what you want the user to do:
Enter at least password again (every time) even after user has asked to "remember me". This can be done easily, just retrieve the user id and keep password box blank. No tricks. Plain and Simple. Even Google do it for their sites.
Now trick time. Let the user enter the application without password but just username. You can just enter some default value in password box (user will think the password is actually retrieved but you will program such a way that whenever "remember me" option is selected, you will just auti-fill this info) and let the user go in. But this is not good option because potentially anyone using that system will be able to logon to your app. You will have to take a call as per your security requirement.
There is a functionality for this on windows. DataProtector and ProtectedData classes can be used to encrypt binary data based on machine information. You can specify the scope of the encryption to be User based or System based it can come in handy for this.
If you think it's better you can only serialize the Login Token information not the User credentials.
You just encrypt the serialized information and store that anywhere you want. And decrypt and deserialize it when you want to use it on startup.
I think so, yes.
You can check them out here:
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.dataprotector?view=netframework-4.7.2
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata?view=netframework-4.7.2
Hi I think I may have done this the wrong way round can anyone help explain how you hash/salt a password. Do you do it from the client or the webservice?
I have a datacontract which has a password datamember, in my service I do this to create a hash/salt of the password before it is saved:
So here is the process in which I was thinking.
Rest Service has https for secure connection
User creates account (along with password)
//to stop packet sniffing when user creates account https is used during POST so no one can see the password?
web service then creates a hash of the password to store it
//so if anyone did get access to the service/database they couldnt make much use of the data in terms of breaching accounts
Then some means to authenticate that user there after
Is this correct?
Sounds like you're on the right track. Hashing along with the salt value should never occur on client side, as attackers will have access to that code. And https would indeed secure the connection, disallowing others from reading the data.
During authentication you do the same thing: take the password the user entered via https, hash/salt that value, then compare the result hash with the value in the database. And of course if you ever return a Student object to the client, it should contain neither of the values.
It may be wise not to reuse the Password property of Student since now you can't tell whether it contains the plain password or the hashed value.
I am designing & developing "Reset Password" form, where user provides username/email address so that application will send a link in a email for the user to click and type a new password. My interest is all about that link, How should i go ahead doing these jobs( I am not looking for answers that will be based on opinion but rather industry practices, steps that worked for your applications).
Make sure link is not bookmark enabled(Don't allow him resetting the password with the same link)
If the links also contains expiry information, What should happen if he clicks expired link
you can also help me by providing other problems i may face with current plan of execution.
I have just implemented something similar.
User clicks "lost password" and enters email address.
On submit, generate a reset code so the main password is unaffected. (should be salt hashed too). Set a timeout for using the reset code.
User visits change password form. Enters email, reset code, new password and confirm password. On success, clear reset code and set new password, redirect to the login page.
I decided to make the reset code as part of the url as to make it easier for the users. As for bookmarking, well, you can't protect all users like that. If they want to bookmark that page, let them. The above measures should stop them submitting anything out of line.
On the reset form's submit you generate a random code, store it in a database(with expiry information if needed and a flag if it has been used) and include it as a parameter in the link.
The link brings the user back to the reset form where you check if the code(parameter) is in the database and has not expired or used already.
The approach that I like is to create a string that looks somehow like this: [username][currentPassword][expirationDate], hash it, and then create a link that looks like: resetPassword.php?username=[username]&exp=[expirationDate]&hash=[hash]
In resetPassword.php you verify this hash with the info in the GET params + the old password you had, and if hash matches, go on with reseting the password.
This way the link will expire whenever it should expire, and it will be impossible to reset the password with that link after the password was changed.
Another approach is to store the reset password code in the database.
I am implementing a reset password aspx page and in that page, I am doing the following with a Wizard.
I am asking the user for his/her username, checking to make sure username does exist before moving on.
In the second view, I want to ask the user to answer his/her security question. I want to display the question and validate what their answer is, and if valid, continue to third step. (At moment, I'm not sure how to retrieve the security question to display in the second.)
In third view, ask user to enter in new password.
I understand how to go about changing the password even without the old password, but just can't seem to figure out how to get the security question.
Anyone have any ideas??
Membership.GetUser().PasswordQuestion contains the Security Question.
Membership.GetUser().ResetPassword(securityQuestionAnswer) will generate a new random password for the user. You can then email this to the user.
http://msdn.microsoft.com/en-us/library/d90zte4w.aspx
If a password answer is required and an incorrect password answer is supplied, a MembershipPasswordException is thrown by the membership provider. If you wanted to allow the user to enter a password, you could check to ensure that this exception is not thrown, then change the password.