Ensuring Password Cracking Ain’t Easy [BSides Manchester 2014]

This talk will look at why using traditional hashing algorithms no longer cuts it and what we should be doing instead. Key Derivation Functions are the future of password storage, the resulting digest requires far more computational power to crack than traditional hashes. Variable work factors also allow us to scale the algorithm as hardware increases in power.

Transcript

1. Ensuring Password Cracking Ain’t Easy Or at least a little more difficult…
2. whoami • Michael Jack • 2nd Year BSc Ethical Hacking @ Abertay • Member of @AbertayHackers • Interested in Crypto (p/w storage, SSL & PGP mainly) • @MikeyJck • MikeyJck.io
3. 10 second plug Securi-Tay Information Security conference • launched in 2012 • Only Student Led InfoSec Con in UK • Abertay University, Dundee • 150 attendees • 13 talks • Community sponsors http://securi-tay.co.uk
4. The next ~30mins • Why does this matter? • What is a hash and how does it work? • Attacking hashes • scrypt, PBKDF2 & bcrypt • What we should be doing
5. Who cares? They’re only passwords right..
6. - Johnny Appleseed “people pick shit passwords”
7. • 123456 • password • 12345678 • 1234 • pussy • 12345 • dragon • qwerty • 696969 • mustang • letmein • baseball • master • michael • football shit passwords
9. Wasn’t just adobe
10. Threat Model • Offline attack • For KDFs we assume Brute Force • Need a lot of GPUs or ASICs • Crypto currency miners • Organised crime • Government(s) • People with HPCCs in their spare rooms…?
11. Hashing 101 • One way mathematical operation • If given the algorithm and output it’s impossible to calculate the input • a = b ( c ) • fixed length output (digest) • every unique input must produce a unique output (crypto collisions)
12. Hashing 101 every unique input must produce a unique digest (crypto collisions) very little difference > very different digests
13. Hashing 101 (Collisions) Taken from: Crypto ePrint 2010/643 “Construct MD5 Collisions Using Just A Single Block Of Message" M0 = single block 512-bit
14. Hashing 101 (Collisions)
15. Hashing 101 (Collisions)
16. Hashing 101 (Collisions) • Generated with Late 2012 MBP in 100 minutes (1hr 40m) • Not as neat as M0 block (larger than 512-bits) • Theoretical collision attacks against SHA1 (HashClash) • Bruce Schneier (2012) recommended moving to SHA2/SHA3
17. Salt with those fries? • Prefix/ affix securely generated string to stored passwords • Slows offline attack • Use Cryptographically Secure Pseudo-Random Number Generator • Unique salt(s) for each entry
18. Pepper? • Filippo Valsorda (https://filippo.io) • Hardcode a separate salt in the web server • attacker now needs to compromise web server for our separate salt • we can switch this out at defined time periods - help with breach detection?
19. Hashing 101 - Attacks • Dictionary • mangle rules/ markov chains • brute force • Rainbow tables
20. Hashing 101 • great for integrity checking • NOT good for passwords • where does that leave us..?
21. Key Derivation • Key Stretching/ Strengthening • Take 56bit key with search space 2s • ‘Expand’ search space by t bits • attacker now has to search a key space of 2s + t
22. PBKDF2 Password Based Key-Derivation 2 created by RSA Labs 2000 RFC 2898
23. PBKDF2 • Generally HMAC-SHA1/ SHA256 • Can be any pseudo random function • “PBKDF2 applies a pseudorandom function to derive keys” • more to it but complex math
24. PBKDF2 • essentially recessively hashes the input • parameterization of iteration count (c) • in 2000 original recommended iteration was 1k • the output length is defined by the underlying pseudo random function
25. PBKDF2 - Example • LastPass • concatenate email address + password • do c number of rounds (user defined default 5k) • use this as LastPass vault encryption key • = email & password always stay client side
26. created by Colin Percival for Tarsnap “Designed to be far more secure against hardware brute- force attacks” scrypt
27. scrypt - Objectives • improve on/ replace PBKDF2/ bcrypt • be a ‘memory-hard function’ - “is thus an algorithm which asymptotically uses almost as many memory locations as it uses operations” • don’t parallel well
28. scrypt - what is it? • Uses PBKDF2 on password • takes the bitstream feeds into ROMix • ROMix output back into PBKDF2
29. scrypt - ROMix • from Random Oracle Model • “a random oracle is an oracle (a theoretical black box) that responds to every unique query with a (truly) random response chosen uniformly from its output domain. If a query is repeated it responds the same way every time that query is submitted” - Wikipedia
30. scrypt • only 1 round of PBKDF2 • heavy lifting done by ROMix • Salsa 20 - crypto primitive • Salsa 20 - 1byte of RAM / 10 clock cycles (Core2) • All math is done in 32bit
31. scrypt • Cryptographically secure as PBKDF2 • takes a long time to compute • uses lots of ram • overall objective = make offline attacks slow(er) > more expensive
32. scrypt - parameterization • N = Work/ iteration factor • r = Block size (RAM) nBytes • p = Parallelization factor
33. scrypt - parameterization • Suggest defaults: Login <100ms • N = 214 • r = 8 • p = 1
34. scrypt - Caveats • scalability (when RAM use maximised) • RAM use on 1ms operations too low • 100ms operations upto ~32MB • still get acceptable digests/s - OpenWall have suggestions on improving
35. What should we use? • OWASP = PBKDF2 for FIPS compliance/ new systems • OWASP = scrypt for defending against massive hardware based attacks • scrypt if you can make it scale or protect very sensitive data • PBKDF2 for everything else
36. What can Users do? • Password manager (LastPass) • Multi Factor Authentication (http:// twofactorauth.org) • Jamie talking about MFA at half 2 this track
37. Thanks! Questions? • me@mikeyjck.io • PGP - keybase.io/mikeyjck • @MikeyJck