I'm migrating an application from ColdFusion to ASP.Net MVC and have a little problem I cannot seem to get my head around. The original application stores user's passwords in a MD5 hash format with no salt in the database. I'm using the ASP.Net membership store and would like to allow for as seamless a transition for the existing users as possible. Here's the possibilities I was thinking of...
1) Since I cannot decrypt the values of their current passwords, I was thinking of storing this old password in a table, checking against it on login... if it's not empty and their password matches, I prompt them to update their password, which would then set the password properly in the asp.net membership table and wipe out their old password, never to be checked again.
2) Users login with their email, not their screen name, so I was thinking of resetting everyone's password to their screen name and forcing them to change it after first login. The only problem is that I'm not sure I can update their password via SQL without the current password. Executing the aspnet_Membership_SetPassword proc doesn't appear to encrypt the password in its own.
What you say?
I've used a variant of #1 in a live application. It worked great, users never noticed the change as far as I was aware.
A couple of refinements:
You don't need to prompt them to update their password; they provided you the cleartext to log in (and you know it's the correct cleartext since it hashed correctly), so just go ahead and set that as their password.
Make sure you clear the legacy password hash if they use the password reset functionality.
I would under no circumstances use option 2; it's wildly insecure.
One other thing -- it is possible to set a password without knowing their current one, it just requires two steps.
Reset the user's password. You now know the reset password.
Use the newly reset password to set the password to a known value.
I had a similar situation recently- An old application of mine used a salted MD5 and I very much wanted to upgrade without affecting my users. What I ended up doing was wrapping the original hash in a better hash and then re-salting it to mitigate the loss of resolution.
For example my initial hash was MD5(pass + salt)
I upgraded everything to SHA256(MD5(pass+salt) +salt) - that way my app is secure and I never needed to find out the original passwords or reset anything.
Once your new authentication process is in place simply run an update script over all existing users in the DB. It is a little bit of a pain but is essentially seamless for you users.
--
Bah- I apologize, this isn't really tailored to ASP.net membership as I'm using a custom auth class on my application. I still think it is one of the more sound methods for performing the upgrade, but i'm not sure of the ASP.net membership specifics.
Option 2 is a pretty big security risk. If anyone knows the email of a screen name can log hijack that account before the rightful owner logs in. Knowing or guessing the email of most popular site users (ie. most tempting ones to hijack) may be more prevalent than you think.
Related
We decided to use Firebase custom authentication because we need to login by either username or email, or phone number in the future. For this we will write our own auth server (in nodejs) that will use Firebase as its backend for storing users with hashed passwords. Is this approach OK?
The solution you described is perfectly OK, just remember to use proper hash function and a salt. Also, it's OK, if user can read their hashed password (user knows his password anyway).
As for the other existing solutions, I don't think there is anything you can use. One part of the problem is that Firebase is quite young project. Also, doing the 'general login system' is quite complicated issue, and I'm not sure, if configuring of such a beast wouldn't be more complicated than coding it from scratch (which BTW is quite straightforward).
How to retrieve password back in original form in Asp.Net Identity System from PasswordHash column?
You don't.
The whole idea behind hashing algorithms is that they're one way processes. With some work you could swap out hashing for encryption of passwords, but A) if you've used the default (which is a hashing algorithm) and you've already got users in the database, you aren't getting those passwords back, and B) there are good security reasons passwords are hashed instead of encrypted.
If you just need to reset the password for the user and you have access to the source code, there's plenty of ways to do this. This SO Q&A is a good start.
Actually what i have to do is: In Admin module of my project i have to show existing users with their credentials ie username/email and their password......so reset password wont work.
The off-the-shelf ASP.net Membership Provider and tables do not appear to be PCI-compliant. Has anyone already implemented a PCI-Compliant Membership Provider for ASP.net? In particular, I am looking at the requirements for section 8.5:
8.5.2: Is user identity verified before performing password resets for user requests made via non-face-to-face method?
For this I am thinking an email with a reset token valid for no more than X hours. The default provider just generates a random value and sends it via email (although we could enable Security Question/Answer to fulfill this requirement).
8.5.5: Are inactive user accounts over 90 days old either removed or disabled?
Default provider does not support this action. We could tie into the OnLoggingIn to do some checks prior to allowing to the login attempt to proceed.
8.5.9: Are use passwords changed at least every 90 days?
Should be able to check this OnLoggedIn. If last password date > 90, redirect to the password change form instead of the desired content.
8.5.12: Must an individual submit a new password that is different from any of the last four passwords he or she has used?
I do not believe the membership tables for the default providers support this. We could add a password history table and stick an entry in every time someone creates a new password. These could then be checked in the OnChangingPassword event of the ChangePassword control.
I am fully capable of doing this myself, but if there is already something out there I'd like to take advantage.
Couldn't find any out-of-box solutions, so will be following James's advice and writing my own.
Am using ASP.NET membership authentication in a small website and i just noticed some thing funny during testing. Am trying to enable user to change their login password any time they wish, i dragged a change password control to the form, i changed the password for my test account, but now all passwords are still working.
I can login with the old password as well as the new password with this particular test account. If i try with any other random characters as the new password, i cant successfully login (which OK). But if type the old password, am able to login, if i type the new password, am still able to login, am finding this very strange.
Refresh your browser and/or clear your browsing history. I've had this problem before.
I've also had this problem before (its because you are testing locally) even when you think you have cleaned browsing history, make sure you clean the cache and cookies, a few times, and then try it out. (I even open different browsers to check)
If this doesn't work (which it will) try debugging your code, or better yet grabbing the sql call using SQL profiler, which will show what you are passing, and you can try the query in your sql database and see if it returns anything.
Mostly its because you are probably testing locally tho
I am very new to web application (ASP.NET). I have source code and database for a complete project.
ASP.NET (Authentication) control is used for login. I don't know the password right now but i can get the login name and password in encrypt format from the database table.
How could I login to the application with only this little information available.
As the control are dynamically created on the pages, it is very hard to debug and find them on runtime.
How could i proceed for login by encrypted password? or is there a way to login by overcoming Authentication control.
The password is probably SHA1 encrypted. Basically what you have to do is SHA1 encrypt the password the user gives you and compare that to the password in your database. Because SHA1 always results to the same thing if the input is the same, you will know that the users given password is correct if both hashes match.
SHA1 encryption is a form of hashing and cannot be reversed.
No, hashed passwords in the database are non-reversible intentionally. This keeps anyone (a hacker?) from reading your database and being able to log in.
As Sam152 said, the passwords are likely SHA1 hashed, so if the passwords are not stored with salt, you can build a rainbow table to find the original password. If they are salted, you need to know the salt to build the rainbow table as well.
You could try implementing custom MembershipProvider by derriving from this class. Then you just override method ValidateUser to meet your requirements. Also remember to modify Web.config.
The point of hashed passwords is that a they can't be used by folks not knowing the decrypted password.
There should be a way to reset the password for users. You could do this and log in based on the reset password.
If you are trying to log in to an active user's account, you may want to consider the implications in doing so without their knowledge (if that is the case). However, if it is just a test user, reseting the password is probably the least cumbersome way. That functionality or procedure should probably be part of web app anyway.
If it's the standard ASP.NET membership stuff, I think it uses a stored proc to check the DB. Just change that and have it return true or whatever.
Adding to the above answers SHA1 encryption output is 40 byte. You should check the length of the encrypted password to get an idea about the kind of encryption..since hash algorithm has predefined no of output bytes, this would help you map with the kind of algorithm and then you should look for possibile salt usage as #MattGWagner said...is the tables in database that stores user information seems like aspnet_users,aspnet_membership, etc? Then this should be the standard authentication provided by windows..Just google and see how it works