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

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?

►  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

One of many sites that offers tables of hashes of

passwords plus

discussion forums

So what is this hashkiller.com?

►  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  

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

InformationWeek on LinkedIn

~  

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

►  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

Available in

2003 People!

►  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

hashcat  

►  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  

►  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

►  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

►  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

hLp://xkcd.com/936/  

Wise words

thisisaveryverylongpassword (27 chars) thisisavery (11 chars)

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

Use verrrrry long passwords

Create Strong Passwords

The source—The Rainbow Series

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.”

►  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

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:

►  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

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.

Session ID: Session Classification:

?Hoyt  L.  Kesterson  II  Senior  Security  Architect  Hoyt.Kesterson@TerraVerdeServices.com  602  316  1985  ScoLsdale,  Arizona  

STU-R33B Intermendiate