MySQL Password Hashing Method Old VS New

Mysql password hashing method old vs new

Yeah, that looks like a toughie. Without cooperation from your hosts or the ability to change password formats or client libraries, you don't have a lot of options.

Honestly, my first choice would be to ditch Dreamhost. That's probably a lot of work, but if they're going to be stuck using old incompatible stuff, it will continue to be problematic.

If that's not an option, what about a joint automated process? You could export the data on the Slicehost side into a CSV file and massage it into whatever format is necessary for Dreamhost, and then upload it to the Dreamhost server. You could have a cron script on the Dreamhost server check periodically for the uploaded file and process it (making sure to move or delete it after it was successfully processed).

What kind of hash does mysql use?

I don't think you will be able to decrypt password stoed in MySQL table and it's of no use using password which is stored in mysql.user table.

You should be using password that is being set when User is created in your application, If you have lost password of users then you can reset it using mysqladmin

SET PASSWORD FOR 'user-name-here'@'hostname-name-here' = PASSWORD('new-password-here');

Differences in Password Hashing Between MySQL and MariaDB

As far as I know, MariaDB and MySQL use the same password hashing currently. Check

https://mariadb.com/kb/en/library/password/

https://dev.mysql.com/doc/refman/5.7/en/password-hashing.html

But as far as I see the first password looks like it was produced by old MySQL version password hashing algo (the one that could be obtained by OLD_PASSWORD()). So if your MySQL server used the new password hashing algo you could just copy values from mysql.user, but as it's not your case, you'll have to manually change passwords of users you want to migrate.

Updating password hashing method, is the original way off base?

This is merely code obfuscation. It adds absolutely nothing to the password itself. The first couple of lines are merely preparing yet another static salt which is prepended to the password, they're just trying to obfuscate the salt itself. Which is pointless, because the code that generates the salt is right there in plain sight. In the end its an MD5 hash with two static salts, which is the same thing as an MD5 hash with a longer salt, which is just plain insecure.

Is it ok to let password_hash() handle salts ...

Yes, absolutely. Each salt needs to be uniquely randomly generated for each password. password_hash does just that. You could be generating your own salt randomly, but why would you? You'd also need to ensure that you're using a proper source of randomness, which password_hash already does for you.

Hashing MySql passwords gives: Authentication with old password no longer supported, use 4.1 style passwords

First, a couple things about authentication in general;

There are normally two types of authentication used in developing applications:

database authentication - This is how the application authenticates for access to the database

user authentication - This is how the user authenticates to your application for access

The article you link to above is talking about user authentication, whereas your question is actually about database authentication.

The original hashing algorithm used by MySQL (prior to 4.1) has been deemed to be unsecure. Version 4.1 implements a new hashing algorithm. The password in your connection string does not need to be hashed, the hashing is performed internally in your .Net connector during authentication to the database (it is done for you). The problem is if you've upgraded your database from a pre-4.1 version and not reset the password to use the new hashing.

You can do either of two things to rectify the situation. These scripts are run at the database.

1. To allow the database to accept the oldstyle hash run

SET old_passwords=TRUE

2. Set a new password using the new hashing

SET old_passwords=FALSE

SET PASSWORD=PASSWORD('your_new_password_here')

The suggestion is to use the second method and use the new hashing algorithm because it makes your database access more secure.

MYSQL 4 password hashing - MYSQL 5

"For compatibility purposes, the old_passwords system variable was
added, to enable DBAs and applications control over the hashing
method. The default old_passwords value of 0 causes hashing to use the
4.1 method (41-byte hash values), but setting old_passwords=1 causes hashing to use the pre-4.1 method. In this case, PASSWORD() produces
16-byte values and is equivalent to OLD_PASSWORD()"

• http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html

I suggest forcing everyone to create a new password, validated via email and a random key, and then store the new passwords with a good method (use something like PHPass or at least bcrypt with salt).

OLD_PASSWORD Function in 5.7.5+

It appears there is no equivalent to OLD_PASSWORD() using MySQL functions except if the server allows globals to be set. By executing the query SET @@global.old_passwords = 1;, as a user with super permissions, the PASSWORD() function then hashes passwords using the OLD_PASSWORD() algorithm.

If, like in our case above, you do not have a super user (Google CloudSQL does not support them), then a replacement algorithm is needed. Below are replacements for different languages:

C | Perl | PHP | Python | SQL

Disclaimer: MySQL's old password functions are a joke in modern day security, and should not be used if at all possible; these algorithms are a mess.

What is the latest in password hash algorithm/data encryption for mysql?

Do not encrypt passwords, when the attacker gets the DB he will also get the encryption key. Just using a hash function is not sufficient and just adding a salt does little to improve the security. Iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use a function such as ehash, PBKDF2, Bcrypt, passlib.hash or similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force.

NIST currently recommends PBKDF2 for a password verifier.

See:

• NIST Recommendation for Password-Based Key Derivation

• NIST Special Publication 800-63B: (Digital Identity Guidelines
  )

• Toward Better Password Requirements by Jim Fenton

---

Related Topics