As everyone know that Drupal store password using SHA2 method which involves Encryption + Hashing + Salt on it.
I have a list of passwords which are currently used by some of my clients in Drupal. Since we have migrated the whole system to Custom PHP therefore we are unable to use the same passwords. And we really don't want to ask everyone in the database to generate a new passwords.
If there is any way, where we could change all the passwords which are in SHA2 (Drupal - 512 Encryption) to support our new system which is currently having MD5/SHA1 (PHP Mysql database).
Any help would be appreciated.
You really do not want to go to MD5. It's dead as far as a password hashing method goes. You should be moving to password_hash and something like Bcrypt at the absolute minimum.
Remember, when someone logs in and you verify their password is correct that's your chance to update how the password is hashed in the database. If they're using a weak method, switch to a strong one and save their user record. Nobody will know what you've done.
After a year or so you can always force-expire all the old-format passwords if you're concerned about that lingering liability. All of your active users will be unaffected.
I wouldn't suggest changing to another password format and especially not MD5. Since you already have the passwords you can implement the Drupal password hashing in your own application and just continue using the existing passwords.
More information about the password formats can be found for example in this question.
I think you should use a 'transition'. For example use your new system but let the old password in the database.
In your code, on user login you get the password (ex: $_POST['pwd']), and crypt it using a strong algorithm (not MD5). Then, you can insert it in a new field of your database.
So, your new database could have a field 'old_pwd' that contains the old password and a field 'pwd' that contains the new password using your new algorithm. According to me this is the easiest to do this migration.
Password checking code is pretty similar in Drupal 7 and 8 and easy to borrow, it does not have any strong dependency on Drupal component. It should be pretty easy to add support for Drupal's hashes to your password checking code. Allowing use to authenticate using their password by storing Drupal's hashes in your database.
To migrate to your new hashing algorithm, simply re-hash passwords on successful authentication. This way, old hashes will be replaced over time.
Drupal has a similar mechanism to ensure transparent updates or old MD5 hashes. Look at the user_check_password() and user_needs_new_hash() to see how it could be done.
Related
I plan to migrate a system developed with PHP Laravel that hashed users password with bcrypt, so just wanted to know is there anyway to convert them somehow in order to make new NodeJS system (with bcrypt) to reuse the current password fields? or the only way forward is to ask user to reset passwords?
Are you asking if the hashed password data (stored on the server, for example) can be used in another bcrypt implementation in node, or something else?
Using modules in node should work with the existing password data (as someone already suggested), but remember to use the same exact salting method and options as the previous bcrypt implementation in PHP, obviously, so that bcrypt generates the same data as before. As long as all options and input into bcrypt are the same, the bcrypt implementation in node should produce the same results and be able to be used.
Using the bcrypt or bcryptjs modules in node with the existing passwords should work just fine.
I have a WP website and another website with similar service. I want to duplicate db user password and email fields into new mysql database.
$A$B6NS8Cv837YVS1c/JKLE1 - WP password (example)
83703ccdb3cb2dad97f76f986400b43f87b989ce - Another website MD5 password (example)
And the question is how I can transfer WP user's passwords to a new mysql table so they can work?
Thanks
You will copy the md5 password into your new system.
Then you can have a login screen which does the exact same hashing on the entered password and compares the two.
Encryption is one way so you will never know the password but you certainly will be able to use it in another system.
As someone mentioned in the comments you will need to know exactly how WordPress hashes the password but this should all be in the source code.
However if you have other users already in the system that use a different hashing system you will need to flag them to decide what hashing to do.
When they do decide to change their password or via recommendation, you can migrate them to the other hashing system.
You can't - it's rather the point of hashing passwords that you can't undo it. You could potentially use a rainbow table to try and crack the MD5 hashes and get the original password before re-hashing it the way Wordpress does it, but if your users' passwords are vulnerable to such an attack, you should probably be concerned for their account security!
Personally, I would announce to the users that a big merge is happening, and for safety reasons they must change their password. A lot of people will probably just "change" it to the same thing, and that's fine, because internally you're just rehashing the password and can then delete the old, unsafe MD5 hash.
I've been hired to rebuild a actively used application that was built on CodeIgniter 1.7.3 (on a PHP 4.2 server) using Laravel 4 on a new PHP 5.3 server.
The system has about ~500 users whose passwords are encrypted with a salted SHA-1 hash. I'd like to use bcrypt to increase the application's security as well as to integrate with Laravel 4's authentication system.
How would you suggest migrating these users passwords?
The whole point of a hash is that you can't recover the original password.
You have three options:
Store bcrypt hashes of the SHA1 hashes, then SHA1 hash each password before bcrypting it on every login.
This may not be a good idea.
Upgrade each hash next time that user logs in. (so that you have the plain text to hash)
This is the best option, but you need to keep your SHA1 hashes and transition code until every single user logs in
Reset every user to a random bcrypted password and force them all to use Forgot Password to change it back.
You probably don't want to do this
Add a column to your database that tells the system which hashing algorithm has been used
On login, check the credentials as normal
If they're using the old one and login is successful - bcrypt the password they entered and update their password and algorithm in the database.
You could create a random password for each user and send out a notification email to everyone with their new password. But this will result in confusion if a user doesn't see the email.
I recommend that you add another db field for the bcrypt value and then create an entry when a user logs in for the first time after the change. You can use either a separate field or delete the old hash to keep track.
When your active users have migrated, feel free to use the random password approach for the rest of your userbase to finish the migration.
Before I knew better, I implemented a login system with md5 as the hashing algorithm. Now that I do know better, I'd like to move to using PHPass. My problem is that the system is already in production and asking all users to change their passwords would be the mother of all headaches.
I've come up with a simple enough solution, but given my previous mistake I'd like to make sure I'm not making an equally grievous mistake due to ignorance.
My solution is as follows:
Change
md5($_POST['pass'])
check md5 hashed password against database value
To
md5($_POST['pass'])
pass md5 hashed password to $hasher->HashPassword()
use $hasher->CheckPassword() to check the re-hashed password against value from DB
Just for clarity, I'm only re-hashing the md5 version because that's what I already have in the DB. It's not intended as an added security measure (although if it is, that's great!).
MD5() problem is WAY exaggerated on this enthusiast programmers community site. Nothing actually bad in this hashing algorithm, especially in comparison with other parts of usual newbie application. Using phpass techniques on a usual PHP site is like using a safe lock on a paper door of a straw hut.
Most important thing in keeping passwords safe against virtual possibility of being stolen and used against the same user on other sites (oh, my!) is password strength and salt. Not hashing algorithm itself. No hashing technique would protect silly pass like "1234" or "joe".
So, md5 + strong password + average salt is better than usual password + phpass
There is not a ingle reason to phpass existing md5 hash
A sensible migration algorithm is
check this user record for the new hashing flag.
if it's set -
go for phpass auth
if not:
md5($_POST['pass'])
check md5 hashed password against database value
if correct:
phpass($_POST['pass'])
save result in the database
set new hashing flag for this record
done
The problem you're talking about isn't really specific to PHPass, but hashing passwords in general. It's basically just double-hashing. This topic has been talked about already in another question: Is "double hashing" a password less secure than just hashing it once?
If you have a look there, you can see that there is still debate over whether double hashing is worse, since it reduces the range of characters passed into the second (or subsequent) hashing function. However, it slows down the hashing process, combating brute force attacks, but only doing it twice won't act as much of a speed bump.
If you didn't want to have to deal with the double hashing, what you could try doing was adding a flag field to your users database table, and set that to true for all new users who join after you setup the new PHPass form of hashing. Then, when a user log in, if they don't have the flag field set, use the old hashing system, or the modified version you have detailed in your question. If they do have the flag field, you can use whatever new hashing process you have set up.
Update: Actually, building on that, what you could try is having that flag setup, and once they go to log in under the old system, if it is a match, then you'll still have their unhashed password in your $_POST data, so you can then run that through your new hashing setup, save the new hash, then set the flag to true, since they've been upgraded to the new hashing method. From then on, they'll be using the new hashing method.
You're getting some pretty dubious advice here, so you might want to ask on IT Security. Contrary to what some folks have said, the password hashing algorithm does matter; you want to use salting and a slow hash such as bcrypt, scrypt, or PBKDF2. See: Which password hashing method should I use?, Do any security experts recommend bcrypt for password storage?, How to securely hash passwords?, Most secure password hash algorithm(s)?. PHPass is a good library.
To migrate your users over to PHPass, you'll want to have two password hash databases: the old one (with MD5 hashes), and the new one (with PHPass hashes). Initially, the new one will be empty. When a user logs in, check whether you have an entry for them in your old password hash database (with MD5 hashes), and if you don't find an entry there, look in the new password hash database (with PHPass hashes). If you find an entry in the old database, you'll want to use MD5 to hash and check their password. If it is correct, you'll want to hash their cleartext password using PHPass, insert it into the new password hash database, and remove them from the old password hash database. If you don't find an entry in the old database, you can check for an entry in the new database and check the validity of their password with PHPass. Basically, you gradually migrate each user over from old-style to new-style hash when they next log in. Does this make sense?
My method makes sure that the password is at least 8 characters long and contains non-random garbage characters ("garbage" meaning possibly unprintable/null characters):
function pass_hash ($password) {
# take first 8 characters of the raw md5 hash
$hashslice = substr(md5($password, true), 0, 8);
# add it to the password and hash again
return md5($password . $hashslice);
}
If you don't like md5, just use sha1, the principle is the same.
How can I allow a change of password with md5 in mind. When the accounts are being created the passwords are being entered in md5. So now when i display the password field of course they are in md5 (don't worry for testing purposes i am showing the password in the field instead of displaying hashes or dashes).
So how do i go about changing the passwords then? When they are changed they also need to be in md5.
Don't display anything in the password field. Have 3 fields. One for the original password (for security), and 2 for the new password (one for verification).
When submitted, check the old password, if it's right, md5 the new one and save it.
In the database you overwrite the old MD5 hash with the new MD5 hash. Or are you asking a user interface question?
The MD5 hash is a one-way hash that cannot be decrypted, so there's no need to display it. Changing the passwords updates the database with a new MD5 hash.
So how do i go about changing the passwords then?
I think you should read You're Probably Storing Passwords Incorrectly
(Article from author stackoverflow.com):
We learned that in a password hashing
scheme, speed is the enemy. We learned
that MD5 was designed for speed. So,
we learned that MD5 is the enemy.
If you must store your passwords(Please also read below for more tips) use phpass to store your passwords securely. I advice you to read the article on the site explaining How to manage a PHP application's users and passwords. It will teach you how to do it securely using email verification tokens.
Just for the fun of it I also created a library(please also read below) which does this for you using the excellent phpass. It is hosted at github and you can take a look at it if you like. Especially you should have a look at Authentication Class together with AuthenticationTest.
OpenID
Furthermore I would like to point out you should use something like OpenID, Facebook Connect, Google Friend Connect instead. You should not be storing your passwords because it is risky business like The Dirty Truth About Web Passwords explains.
Jeff Atwood:
I'm not here to criticize Gawker. On
the contrary, I'd like to thank them
for illustrating in broad, bold relief
the dirty truth about website
passwords: we're all better off
without them. If you'd like to see a
future web free of Gawker style
password compromises -- stop trusting
every random internet site with a
unique username and password! Demand
that they allow you to use your
internet driver's license -- that is,
your existing Twitter, Facebook,
Google, or OpenID credentials -- to
log into their website.
I also have a nice OpenID library available at github which uses LightOpenID with openid-selector. You can see a demo up and running at my shared hosting provider: http://westerveld.name/php-openid/