Storing Passwords

Never store passwords�in plaintext!

Data Governance

1

Storing Passwords

• Instead, store a hash of the password
• User can prove they have the correct password if the stored hash equals the hash of the thing they just typed

Data Governance

2

Bad Passwords ☹

• You are guaranteed to have users whose passwords are bad:
• asdf
• password
• 1234

​

​

Data Governance

3

Mitigating Bad Passwords That Were Stolen

• Now assume that someone has stolen your entire hashed password table

​

• Hashing algorithms are easy to discover/guess

​

• It’s easy to find the�(bad) passwords in�your stolen table
• asdf = 3da541…
• password = 5baa61…
• 1234 = 7110ed…

​

​

Data Governance

4

Mitigating Bad Passwords That Were Stolen

• Salting adds a small amount of randomness to users’ passwords, to make identical passwords have non-identical hashes
• Harder for hackers to find commonly-used passwords

Data Governance

5

Mitigating Bad Passwords That Were Stolen

• Salting also makes it harder to find pairs of users who share passwords
• App developers
• Hackers who were able to find one password through another means (eg, brute force, social engineering)

Data Governance

6

Bad Passwords

• Salting isn’t intended to protect individual passwords
• It protects the entire set of passwords

​

• Imagine using the same salt value for all users
• Can still find groups of users with shared passwords
• Can still find�users with�known-bad�passwords

Data Governance

7

Using Salts Correctly

• Use long salt values
• If hackers can precompute the hashes for known-bad passwords, they can also precompute them with all possible salt values

​

• Our example salts only had 1296 possible values

Data Governance

8

Using Salts in HW5

• Store the salt in a separate column or field

​

• When checking for password matches, extract original salt before hashing the user’s input with the extracted salt

Data Governance

9