<p>That's because Craft follows the standard procedure of <a href="https://en.wikipedia.org/wiki/Salt_(cryptography)">hashing passwords with what's called a "salt"</a> as a security measure.</p>

<p>Think about it this way - if a password were hashed without a salt, <em>every instance of the same password would result in the same hashed value</em>.</p>

<p>Example:</p>

<p>Suppose there are two users, Foo and Bar. They both choose <code>password123</code> as their password. When hashed without a salt, their passwords would look the same after hashing, which is a security flaw. </p>

<p>We can see this by testing it with any hash algorithm:</p>

<p>(I'm using md5 here for readability because it gives a shorter result - do not actually use md5 for anything secure)</p>

<p><code>password123</code> becomes <code>482c811da5d5b4bc6d497ffa98491e38</code>, and - without using a salt - would be stored that way for every user with the password <code>password123</code>.</p>

<p>The implication here is that the system is now vulnerable to a variety of attacks, like Lookup Tables and Rainbow Tables, which depend upon every instance of a password yielding the same hash.</p>

<p>Enter Salts. Salts are psuedo-random strings attached to the user's password prior to being hashed and stored. </p>

<p>In our Foo and Bar example, that would look something like this:</p>

<p>Foo chooses <code>password123</code>. The system generates a psuedo-random "salt" of <code>pg7n6yVBzWJbaxfF</code>, <em>combines them</em> into <code>pg7n6yVBzWJbaxfFpassword123</code>, and then hashes that result to get <code>d026a6847c743e23195cf37db2a66ae9</code>. In addition, Foo's generated salt is stored in the table, so that it can be used to test login attempts.</p>

<p>Bar does the same, but the system generates <code>Am6g4n0JEFdE1poH</code> as his salt. When combined with <code>password123</code> and hashed, it then yields a different result: <code>5e7b0bb4842ee8315105a62922c32894</code>.</p>

<p>Both users have the same password, but the final hashed result now has no traceable relationship to the original password in either case. If a malicious party were to try and search for <code>password123</code> by scanning the database for its hashed equivalent (in our example <code>482c811da5d5b4bc6d497ffa98491e3</code>), it wouldn't find anything.</p>

<p>The same principle applies to resetting your password - even if you choose the same password, that new instance of the password is re-salted, re-hashed, and stored as something distinct.</p>

CC BY-SA 3.0
2018-02-19T03:05:37.190Z
Sam, do you know if Craft passwords also have an application-wide "pepper" added? This would be an added layer of security for when the MySQL data was breached (such as via SQL injection) but without access to the PHP code.
Simon East
CC BY-SA 3.0
2017-01-05T17:25:11.583Z
2017-01-05T17:25:11.583Z
Sam LeBlanc
<p>When I reset my password with the same password I used before. 
I checked the MySQL database the old encrypted password is different from new encrypted password.</p>

<p>Do you guys know why?</p>

<password>
Craft password encryption
# Craft password encryption

(Asked by: username_0 on 2017-01-05)

When I reset my password with the same password I used before.
I checked the MySQL database the old encrypted password is different from new encrypted password.

Do you guys know why?

**Tags:** password

---

## 1 answers

### Answer by username_1 on 2017-01-05. Score: 7

That's because Craft follows the standard procedure of [hashing passwords with what's called a "salt"](https://en.wikipedia.org/wiki/Salt_(cryptography)) as a security measure.

Think about it this way - if a password were hashed without a salt, *every instance of the same password would result in the same hashed value*.

Example:

Suppose there are two users, Foo and Bar. They both choose `password123` as their password. When hashed without a salt, their passwords would look the same after hashing, which is a security flaw.

We can see this by testing it with any hash algorithm:

(I'm using md5 here for readability because it gives a shorter result - do not actually use md5 for anything secure)

`password123` becomes `482c811da5d5b4bc6d497ffa98491e38`, and - without using a salt - would be stored that way for every user with the password `password123`.

The implication here is that the system is now vulnerable to a variety of attacks, like Lookup Tables and Rainbow Tables, which depend upon every instance of a password yielding the same hash.

Enter Salts. Salts are psuedo-random strings attached to the user's password prior to being hashed and stored.

In our Foo and Bar example, that would look something like this:

Foo chooses `password123`. The system generates a psuedo-random "salt" of `pg7n6yVBzWJbaxfF`, *combines them* into `pg7n6yVBzWJbaxfFpassword123`, and then hashes that result to get `d026a6847c743e23195cf37db2a66ae9`. In addition, Foo's generated salt is stored in the table, so that it can be used to test login attempts.

Bar does the same, but the system generates `Am6g4n0JEFdE1poH` as his salt. When combined with `password123` and hashed, it then yields a different result: `5e7b0bb4842ee8315105a62922c32894`.

Both users have the same password, but the final hashed result now has no traceable relationship to the original password in either case. If a malicious party were to try and search for `password123` by scanning the database for its hashed equivalent (in our example `482c811da5d5b4bc6d497ffa98491e3`), it wouldn't find anything.

The same principle applies to resetting your password - even if you choose the same password, that new instance of the password is re-salted, re-hashed, and stored as something distinct.

> **Comments:**
> **username_2**: Sam, do you know if Craft passwords also have an application-wide "pepper" added? This would be an added layer of security for when the MySQL data was breached (such as via SQL injection) but without access to the PHP code.  

---

