4. What happens with a leak
Site is compromised.
Data is extracted.
Hackers use data maliciously.
Data is posted on pastebins.
Everyone swarms to see who can crack the most passwords.
5. Why the surge in leaks
Legacy systems are showing their age.
Frameworks are now ubiquitous.
High availability of network penetration and data extraction tools.
Growing technical debt due to fast development times.
Highly coordinated attacks.
6. Vulnerabilities
Failing to follow basic security
processes while coding, e.g. SQL
Injection.
Passwords (and other sensitive
information) aren’t handled properly.
7. SQLMap
SQL Injection exploit tool.
Automatically identifies multiple types of vulnerabilities.
Easy to use.
Can give you the entire contents of a database, including
the schema!
8. Post leak hazards
If even after all the preventive
measures the leak happens?
You should’ve hashed the
passwords… correctly.
9. What is Hashing…
Algorithm that generates a fixed-length “digest”
for a given “key”. The digest is:
Reproducible
Fixed-length.
Cannot be “un-hashed” back to the source.
Cannot find “collisions” mathematically.
10. Birth of Hash
Hashing comes from cryptography.
MD5 (128 bit) – Very broken and too
small.
SHA-1 (160 bit)
SHA-2 (224, 256, 384, 512 bit)
SHA-3 (in development)
Some Cryptographic Hash families
Very fast
Use little memory
Hardware implementable
12. Password Cracking
Brute Force - Run all possible combinations in a key space through the
algorithm to see what matches. 3 billion guesses per second with a
moderate video card.
Mask Attack
• Common Pattern:
UllllllNS
U = Uppercase
L = Lowercase
N = Number
S = Special Character
• Mimic languages.
• Mimic names.
• Use 1337 speak.
• Mimic password
requirements.
Dictionary Attack -
Huge lists of:
• Popular passwords
• Every word in a particular language
• Names
• Combinations
14. What we have so far…
I can get hit with a zero-day exploit and lose my
hashes.
Hashcat can brute-force most of my hashes in a
few minutes…
15. Goal of Hashing
To make it prohibitively expensive for
ANYONE to brute-force a hashed
password. Even you.
Prohibitively expensive = It requires a
lot of time and resources to guess a
single password.
16. How to achieve the goal?
Stop using cryptographic hashing
algorithms!
Use a salt. (Really important!)
Use password hashing algorithm with key
stretching.
17. Salt
Defends against dictionary attacks and rainbow tables
Slows down brute-force attacks.
Without salt, the entire list can be attacked at once. With salt, every password must be attacked individually.
Randomly generated bytes to combine with a password
before hashing.
19. Two important password hashing algorithms
bcrypt
•Expensive key setup that uses salt & password.
•Implicitly requires a salt.
•Uses more memory.
•Runs slowly on GPUs and FPGAs.
•Widely used and vetted.
•Work factor increases exponentially.
•Example hash string: $2a$05$vUOkFKPjgL1IvXt.8ptmE.FSvdTrW7VqC8b7.Fxbld3LPO1TR08Vi
PBKDF2
•Uses SHA-256.
•Uses little memory.
•Runs faster on GPUs, but still costly with a proper work factor.
•Work factor increases linearly.
21. Hashing Best Practices
Use a standard vetted library. Don’t add customizations.
Make the work factor configurable.
Be able to re-hash a password when the work factor changes after a
successful login.
Be able to reset/lock accounts in bulk.
Unit test for known hash keys & values to ensure it’s doing what you think
it’s doing.
22. Measures
As an organization:
• Guard against hacks.
• Detect leaks – install trip wires.
• Plan for leaks.
• Ask hard questions before a leak happens.
As a user:
• Use KeePass to store your passwords.
• Enable two-factor auth everywhere.
• Use unique high-entropy passwords.
• Use at least 15 characters.
23. Thank You!
• With appropriate hashing, the good guys need to
be right just once but the bad guys need to be
right all the time!
Editor's Notes
Lots (LOTS) of high-profile password leaks in 2012.
(Twitter too..)
LinkedIn link was one of the biggest (and high profile) at 6.4M.
Cracked passwords are usually posted to pastebin.
People use the same IDs and passwords repeatedly, so once an ID/pass is compromised, hackers try other sites.
Yahoo, AOL, etc., can’t just up and change their entire auth system.
If lots of people are using a specific framwork (e.g. Ruby on Rails) and a vulnerability is found, …. Presto!
Every company should have people in charge of security, not just at an engineering level, but at a product level.
Even if you are up to date with everything, you can still get hacked due to other issues, zero-day exploits, etc.
There are always bugs.
SQLMap is a sql injection scanner.
Use this for auditing your web apps.
Metasploit
w3af
Grabber
Watcher
These algorithms make it easier for attackers to brute-force passwords because they use so few resources.
These algorithms make it easier for attackers to brute-force passwords because they use so few resources.
At zero day exploit, everyone picks the hashes and starts attempting to brute-force them.
As much as it would take me to buy a Lamborghini atleast…
It should be difficult for anyone to brute-force a password no matter how much inside information they have, including:
The hashing algorithm
The salt
The hash
Related account information
Salts defeat pre-computed tables by changing the output hash.
Two users with the same password will have different hash, because the salt is different.
Should be unique each time a password is hashed.
Never re-use a salt.
Doesn’t need to be huge. 8-12 bytes if fine.
Work Factor = Amount of key stretching done
By cycling the output back into the hash function, we can determine how much computational power is required to compute the digest.
A bcrypt hash string contains all the information required to check a password.
$2a$05$vUOkFKPjgL1IvXt.8ptmE.FSvdTrW7VqC8b7.Fxbld3LPO1TR08Vi
$2a version of bcrypt
$05 work factor
vUOkFKPjgL1IvXt.8ptmE. Salt
FSvdTrW7VqC8b7.Fxbld3LPO1TR08Vi Hash
PBKDF2 is an official standard because it’s based on an official standard.
Even if you know the salt, a predictable patterned password containing 9 characters will take many years to brute-force.
Salt – Stop bulk attacks.
Key stretching – slows down attacks.
Hard Questions:
How do you detect a leak?
At the engineering level? Database level? Application level?
Play a war game where there was a leak.
How do you handle it?
How do you determine which accounts were impacted?
How do you communicate that information?
How do you lock those accounts or monitor them for suspicious activity?
Can you put your app in a read-only mode, no changes to the db?
Can you lock out especially sensitive parts of your application?
How do you fix the vulnerability?
