Not quite secure

Go ahead and start the application. Try creating a new user with user1 as the password. Log out of the application, then use the instructions on the Welcome page to open the H2 console and view all of the users' passwords. Did you notice that the hashed values for the newly created user and user1@example.com are the same value? The fact that we have now figured out another user's password is a little disturbing. We will solve this with a technique known as salting.

Your code should now look like this: calendar04.04-calendar .

Would you like some salt with that password? If the security auditor were to examine the encoded passwords in the database, he'd find something that would still make him concerned about the website's security. Let's examine the following stored username and password values for a few of our users:

Now, note that the encrypted password of the hacker@example.com user is exactly the same as the real user! Thus, a hacker who had somehow gained the ability to read the encrypted passwords in the database could compare their known password's encrypted representation with the unknown one for the user account, and see they are the same! If the hacker had access to an automated tool to perform this analysis, they could likely compromise the user's account within a matter of hours.

While it is difficult to guess a single password, hackers can calculate all the hashes ahead of time and store a mapping of the hash to the original password. Then, figuring out the original password is a matter of looking up the password by its hashed value in constant time. This is a hacking technique known as rainbow tables.

One common and effective method of adding another layer of security to encrypted passwords is to incorporate a salt. A salt is a second plaintext component, which is concatenated with the plaintext password prior to performing the hash, in order to ensure that two factors must be used to generate (and thus compare) the hashed password values. Properly selected salts can guarantee that no two passwords will ever have the same hashed value, thus preventing the scenario that concerned our auditor, and avoiding many common types of brute force password cracking techniques.

Best practice salts generally fall into one of the following three categories:

• They are algorithmically generated from some pieces of data associated with the user, for example, the timestamp that the user created
• They are randomly generated and stored in some form
• They are plaintext or two-way encrypted along with the user's password record

Remember that because the salt is added to the plaintext password, it can't be one-way encrypted—the application needs to be able to look up or derive the appropriate salt value for a given user's record in order to calculate the hash of the password, and to compare it with the stored hash of the user when performing authentication.