Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Because of a hardware issue i need to migrate many virtual users to a new machine. Their passwords stored in MySQL encrypted with ENCRYPT which using crypt()eventually.

Maybe it's my fault but salt wasn't added when passwords were stored so they're totally random. My basic idea was to dump the database then import it. When i tried to store the same string in the same machine with ENCRYPT it gave me different results. Will users' passwords work on the new machine?

Update on environment and encrypting method:

  • The old machine is running Debian Etch with MySQL 5.0
  • New machine will run Debian Squeeze with MySQL 5.1
  • The encrypting method is MySQL's default ENCRYPT
  • Salt wasn't added originally
  • I don't know the passwords

Thank you for your feedback, fabrik

share|improve this question
If you're migrating to a different operating system (the hardware is irrelevant), it's possible (but rare) that they might use different algorithms to encrypt passwords. If you want reassurance on that, you need to say exactly what the old and new OS are, and possibly how MySQL was configured (I don't know where or even if MySQL can be configured to use a non-default algorithm, e.g. MD5 or Blowfish or SHA-256). – Gilles Apr 14 '11 at 19:24
@Gilles thank you for your comment, see my update on my question. – fabrik Apr 15 '11 at 6:20
If you're upgrading to a more recent version of the same OS, you have nothing to worry about. Making previously-existing passwords unusable would be a huge incompatibility! – Gilles Apr 15 '11 at 8:39
@Gilles i hope you're right :) – fabrik Apr 15 '11 at 9:03

From the provided link to ENCRYPT()

If no salt argument is given, a random value is used.

salt is a 2 character string, saved in the beginning of the encrypted text. e.g. encrypting a string with salt='df', 'df' is in the start of the output product.

mysql> SELECT ENCRYPT('hello','df');
| ENCRYPT('hello','df') |
| dfbVa429UeC0U         | 
1 row in set (0.00 sec)

Another example, no salt

mysql> SELECT ENCRYPT('hello');
| ENCRYPT('hello') |
| oBSydDfeNx5ug    | 
1 row in set (0.00 sec)

Now use the first two characters of the previous string as salt

mysql> SELECT ENCRYPT('hello','oB');
| ENCRYPT('hello','oB') |
| oBSydDfeNx5ug         | 
1 row in set (0.00 sec)

Same output.

You most probably won't have a problem, but just to be 100% sure (that crypt implementation is the same), create a test account on the old machine and migrate it to the new one. Check if the password works for both of them.


salt is ALWAYS stored in the first letters of the password's encrypted string. There is NO WAY salt is lost, without salt users wouldn't be able to login in your old machine in the first place. You do not need to (and you shouldn't) know any passwords.

If you're migrating from etch to squeeze, the most sensible way to go, is to setup a testing server with Debian Squeeze. You do not need hardware to do that, setup a VirtualBox guest for example. Then create a new user in your old machine and migrate his account to the testing machine. If the password works for both machines, then you 're good to go, it's the only way to be 99.9% sure. Testing migrations is a must anyway, you should worry about a lot more problems appearing in them.

share|improve this answer
@forcefsck at first sight i thought this what i'm looking for. Unfortunately i know nothing about what is hello and that's my problem. I don't want to decrypt these encrypted strings but i'd like to be sure about my newly imported database will accept original passwords. – fabrik Apr 14 '11 at 12:37
@fabrik: how come you write English and know nothing about 'hello'? ;) Well, hello is just hello here--a test string to demonstrate the ENCRYPT behavior. – alex Apr 14 '11 at 12:50
@alex I'm glad you're so funny but the original problem for me is not too funny. And i hope you're just kidding about hello. – fabrik Apr 14 '11 at 13:07
@fabrik, I'm not decrypting anything, I'm just showing how the password checking mechanism is able to match two encrypted strings of the same password by extracting salt from the already stored value. Which is why the system works where it is currently. – forcefsck Apr 14 '11 at 13:15
@forcefsck oops maybe i was really equivocal. I totally understood your example but i think it won't solve my problem, because i know nothing about users' passwords to write a script then insert passwords into the new database as you wrote. – fabrik Apr 14 '11 at 13:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.