Postfix + MySQL ENCRYPT(), How does it verify the password with randomizing salt?

I've implemented my mail server as dictated here.

It works perfectly fine. My curiousity revolves around entering users into the database and authenticating them

Running:

INSERT INTO users (email, password) VALUES ('sales@example.com', ENCRYPT('password'));

Multiple times will give a different hash for the encrypted password as its utilizing a random s开发者_Python百科alt. I.e. If I enter sales@example.com three times with the same password each hash is different...

My question to this is, how is it that the Postfix server can actually authenticate the password when a user logs in via a mail client?

There isn't any problem per say as it works fine, more just to satisfy my curiosity so I can fully understand whats going on behind the scenes to properly authenticate the encrypted password.

---

Postfix compares the password from the database to a new encrypt done with the salt(password from db).

to encrypt:

update user set password = ENCRYPT('1234') where id = 1

to check password:

SELECT u.* FROM user u where u.email ='admin@dominio.com' 
and ENCRYPT('1234', u.password) = u.password

---

Read man crypt: it returns the salt in the first two chars of the return value.

So the salt is not lost, you can compare the encrypted string to the result of crypt( 'pass', $first_two_chars_of_encrypted_value ).

---

You must use ENCRYPT('pass','salt') to force a salt, otherwise the salt is lost forever and you have no way of recovering it. Fairly pointless function without it. It's a terrible function to use, though, because the security is so minimal; use PASSWORD() or OLD_PASSWORD() instead.

ENCRYPT() uses the system crypt(), which may use all or only the first 8 characters, must be printable 7-bit ascii, generally uses 1 round of a DES-based hash, and is completely unportable. Avoid it.