26
Session ID: Session Classification: Hoyt L Kesterson II Terra Verde Services STU-R33B Intermediate Everything We’re Doing With Passwords Is Wrong

Stu r33 b (2)

Embed Size (px)

Citation preview

Page 1: Stu r33 b (2)

Session ID: Session Classification:

Hoyt L Kesterson II Terra Verde Services

STU-R33B Intermediate

Everything We’re Doing With Passwords Is Wrong

Page 2: Stu r33 b (2)

The compliance chicken or egg

It irritates users. Makes it hard to remember passwords.

Six is not good but seven is?

Increases the number of possible values. Complexity rules lead to ugly passwords.

If not compromised, what’s the risk if you reuse?

Page 3: Stu r33 b (2)

►  In February 2011 Anonymous carried out a SQL injection attack against HBGary Federal.

►  They acquired three MD5 hashes and sent them to the gang at Hashkiller.com. ►  Back came 4036d5fe575fb46f48ffcd5d7aeeb5af:kibafo33 ►  kibafo33 was the password for email/Facebook/twitter/ and who-

know-how-many-other accounts of Aaron Barr, CEO of HB Geary Federal.

►  Anonymous was off to the races.

Cracking a password in real life

Page 4: Stu r33 b (2)

One of many sites that offers tables of hashes of

passwords plus

discussion forums

So what is this hashkiller.com?

Page 5: Stu r33 b (2)

►  The attacker either works with the password as entered by the user or as stored by the authenticator.

►  For the former, one can either social engineer for some good guesses, sniff it, or brute force by submitting passwords from a dictionary, a big list of possible passwords. ►  The latter can be done in parallel. ►  Should be slowed or blocked by system reaction to successive failed

attempts.

Determining a password

THC  Hydra  

Page 6: Stu r33 b (2)

User  supp

lies  

Password  

in  

Plaintext  

authen

7cator’s  System  

Hash  

Func7on  

Authe

n7cator’s  storage  

Hashed  

Password  

…should be cryptographically protected.  

Passwords stored at authenticator

Page 7: Stu r33 b (2)

InformationWeek on LinkedIn

Page 8: Stu r33 b (2)

 

~  

a  half  million  

hashes  

264  =  456,976  

Policy  =  4  lower  case  characters  

—let’s do a hypothetical They are not being reversed

Not difficult to build table of all possible hash values

Hashes are not broken

Page 9: Stu r33 b (2)

►  PCI DSS 8.5.10 & 11 say at least seven alphabetic and numeric.

►  Microsoft says at least eight also including special characters. ►  Failure codi#ed into compliance standards.

Put more possibilities in the set

Page 10: Stu r33 b (2)

Available in

2003 People!

Page 11: Stu r33 b (2)

►  If Lan Manager is enabled ►  Password converted to all uppercase; ►  Password padded to 14 characters; ►  Split into two 7-character parts, i.e. 56 bits; ►  Each part padded with a byte of zeros; ►  Each part used as a DES key to encrypt “KGS!@#$%” to produce two

“hash” values.

►  If you cannot turn off LM hashing, choose a password whose length is over 14 characters.

Backward compatibility is killing security

Page 12: Stu r33 b (2)

hashcat  

Page 13: Stu r33 b (2)

►  You would need a large table to hold all the possible hashes for a large set of passwords.

►  Rainbow tables provide a way to efficiently store the passwords and associated hashes.

►  More time to “search” but less memory ►  Tuples are associated in chains using reductions, i.e. a

transformation of the hash into plaintext. ►  ophcrack was #rst; RainbowCrack latest ►  Salting hashes makes tables of

hashed passwords useless.

At the end of the

RainbowCrack  

Page 14: Stu r33 b (2)

►  Add a salt into the hashing process. ►  Using different salt values gives different hash values for the same

password.

►  hashcat can use GPU, e.g. AMD Radeon HD 7970, to produce hashes very quickly. ►  4.7 billion MD5 hashes per second ►  2.2 billion SHA-1 hashes per second ►  Not fast enough for salting exhaustive dictionary unless constant salt

used by target. ►  Fast enough for salting selective dictionary.

1st line of defense—salt

Page 15: Stu r33 b (2)

►  At the Passwords^12 conference in December, Jeremi Gosney demonstrated his implementation of hashcat running on multiple GPUs ►  25 AMD Radeon GPUs ►  VirtualOpenCL (VCL) was extended to support 128 GPUs

►  Generates ►  348 billion NTLM hashes per second ►  180 billion MD5 hashes per second ►  63 billion SHA1 hashes per second ►  20 billion LM hashes per second

►  Six minutes to generate all possibilities

hashcat on roids

Page 16: Stu r33 b (2)

►  SHA-256 is not the answer ►  You want an algorithm that is fast enough to avoid a

perceptible delay to the user, but… ►  Makes the computing of a large number of hashes

untenable. ►  Fortunately, you don’t need

to write this yourself. ►  bcrypt, PBKDF2 ►  multiple iterations ►  adaptable to future hardware

2nd line of defense—difficulty

Page 17: Stu r33 b (2)

hLp://xkcd.com/936/  

Wise words

Page 18: Stu r33 b (2)

thisisaveryverylongpassword (27 chars) thisisavery (11 chars)

No complexity— no upper case, numerals, or special characters

Use verrrrry long passwords

Page 19: Stu r33 b (2)

Create Strong Passwords

Page 20: Stu r33 b (2)

The source—The Rainbow Series

Page 21: Stu r33 b (2)

Password Management Guideline

“Changed on a periodic basis to counter the possibility of undetected password compromise. …changed often enough … acceptably low probability of compromise during a password’s lifetime.”

Page 22: Stu r33 b (2)

►  For a continuous series of logon attempts are you hoping the new password is one that has already been submitted?

►  If the hash table attack software has the hash of your current password, it’s very likely that it also has the hash of the replacement password (and the password you’ll use a year from now).

►  Longer passwords kept for a longer time is a better defense. ►  Only change passwords when

►  there is a known or suspected compromise; or, ►  you want a stronger password.

The effectiveness of a prophylactic password change

Page 23: Stu r33 b (2)

Password Management Guideline

•  date and time of user’s last login,

•  location of user at last login; and,

•  unsuccessful login attempts since last login.

Upon successful login notify user of:

Page 24: Stu r33 b (2)

►  Requiring unmemorable passwords. ►  six-characters with at least one upper-case, one-lower case, one

numeral, and one special character.

►  Requiring a password change unless suspected or known to be compromised.

►  Inadequately protecting stored passwords. ►  There’s little excuse for not using a function that’s been around since

1999.

We shouldn’t be doing these at all

Page 25: Stu r33 b (2)

The compliance chicken or egg

What is this preventing? But difficult to convince auditor.

Auditor will accept very long passwords.

It will be difficult to convince auditor that length is enough.

What is this preventing? But difficult to convince auditor.

Page 26: Stu r33 b (2)

Session ID: Session Classification:

?Hoyt  L.  Kesterson  II  Senior  Security  Architect  [email protected]  602  316  1985  ScoLsdale,  Arizona  

STU-R33B Intermendiate