For one of my webapps I'm using ASP.NET MVC 5. For sometime I used default password hashing algorithm. I would like now to switch to custom hasher.
But the question is: What happens to exising data? How do I update hashes for exising users?
You cannot update hashes for existing users.
The only option really is to add a column to the database table indicating the hash method, and write code to support both the old and new hashing methods contingent on the value found in that column.
If you like, you can update each user's hash as they sign on individually (since that is the only time the site has the cleartext password available). But there is no way to update the hashes on a batch basis whilst offline.
Related
I know there was question like this million times, but I was unable to find answer that will fit my needs.
I'm building something like small internal password manager for my company, to store login data for various servers and so on.
When new user is registered, his password will be saved in database in salted/hashed version so no one can get access to it (and for that part I think it's all ok, correct me if I'm wrong).
But then, when user is logged in, he is able to add new server with it's login details.
Question is, how to store those.
Because, at some point, I have to present this login details to user in plain text (that is whole point of this application).
Best I could came up with is using some kind of symmetric encryption.
Idea is that app will crypt login details with symmetric encryption and save it in that way into database, and then when data is needed once again will extract data from database, decrypt it with same key and present to user (and key should be in source code of application?).
It could be asymmetric encryption but it's the same if public and private key are stored in same source code, then there is no any benefit of using it?
That doesn't seem too secure, but I can't think of anything better.
Is there any better way to do this, to store this login data?
If it's important to you, application will be in PHP and database is Oracle
I would just use symmetric encryption. The standard steps are:
Derive a symmetric key from a user-supplied password (e.g. PBKDF2 or scrypt)
Encrypt the data using AES-128-CBC or better with a good random IV
HMAC the result (e.g. HMAC_SHA256) or just use AES GCM mode
Store IV+ciphertext+MAC in the database.
This can all run in a browser these days (see crypto-js and aes-js). That way the server never gets to see the plaintext password (not sure if this is a requirement).
The MAC can also serve as a password hash, i.e. if the MAC validation fails, then it means the supplied password is incorrect.
We have a Wordpress site which we are going to gradually rebuild using the cakePHP framework. We will replace different parts of the Wordpress site incrementally, so we need to implement some sort of single sign on to allow authorization across both frameworks during the time while both frameworks are running side by side.
We have a pretty good strategy for how to do this. In short, we will duplicate all user rows in two different tables: one table for Wordpress (wp_users) and a different table for Cake (users). [More details outlined here (in case you're interested).]
This means when we create a user in Wordpress or Cake, we create the same user in the other table as well. This is "mostly harmless"...
We are struggling with the different password hashing strategies between Wordpress and Cake. In order to save the same user password in both tables, we need to figure out how to hash it so that each respective framework can check it.
Wordpress uses a pretty advanced hashing algorithm: PHPass. Cake (by default) seems to offer a choice of more traditional algorithms: SHA1, md5, blowfish... with optional salting.We're stuck on the fact that Wordpress generates/emails a default password to new users and then immediately saves a hashed version in the DB. This hashed version of the password is pretty useless to cake, unless we can figure out how to replicate all of the Wordpress authorization protocols (which seems somewhat daunting for new Cake users).
Is there an elegant solution to this problem?
I would suggest to keep user management centralised in either Wordpress or CakePHP until the migration to CakePHP is completed.
As of CakePHP 2.3, bcrypt/blowfish is officially supported for hashing passwords;
http://book.cakephp.org/2.0/en/core-libraries/components/authentication.html#using-bcrypt-for-passwords
However, if you already have your Single-Sign on working, why not leave the password syncing for the time being? Once migration to CakePHP is complete, consider the following options;
Send an email to all users containing a unique link to reset their password; resetting the password will actually create a hashed password in CakePHP and enable the new account. The unique links should be invalidated after that (also make sure that the link will expire after a certain period anyway)
Because both CakePHP and PHPass use bcrypt/blowfish, you may be able to copy the hashed passwords to CakePHP when migration is completed. However, you will need to determin 'how' PHPass passwords and salts are stored (separate fields? single field with a delimiter?). You may have to write your own Authorize Object that will pick the right 'salt' from the database
I need to synchronize three of them but I have already 18k Asp.Net Members. (Offline synchronization)
So how can I convert default "Password Hashing" of Wordpress and Drupal to Asp.Net Membership's (SHA1 with Salt) ?
I don't know if you can. MD5 and SHA1 are uni-directional algorithms. This is why they are used. They provide security for the user passwords. So you will not be able to revert the hash back to the passwords. Nor can you convert from MD5 to SHA1 directly.
In this scenario I think you are stuck with resetting the Drupal and Wordpress user passwords when you merge. (See edits for alternate solution.)
EDIT: This post had a interesting idea / solution. Write some custom code to generate the SHA1 passwords upon your users first logging in. Collect the SHA1 hashes, and use those during merge. Any users you don't get, force them to do a password reset.
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.
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