secure passwords-theory-and-practice

20
Safe Passwords – In theory & practice Akash Mahajan Web Security Consultant @makash on Twitter http://akashm.com @makash | akashm.com - That Web Application Security Guy

Upload: akash-mahajan

Post on 01-Sep-2014

2.741 views

Category:

Technology


2 download

DESCRIPTION

A look at the risks of not encrypting passwords in your web applications. Also a basic introduction to hashing passwords with salts.

TRANSCRIPT

Page 1: Secure passwords-theory-and-practice

@makash | akashm.com - That Web Application Security Guy

Safe Passwords – In theory & practiceAkash Mahajan• Web Security Consultant• @makash on Twitter• http://akashm.com

Page 2: Secure passwords-theory-and-practice

Something to think about In Dec 2009 a hacker released 32

million passwords of the users of rockyou.com

It is a social gaming company. Those passwords were the 1st instance

of such a huge number of passwords being available for analysis

@makash | akashm.com | That Web Application Security Guy

Page 3: Secure passwords-theory-and-practice

Something to think about A password analysis from rockyou.com

revealed All passwords were being stored in clear

text! 30% of the passwords were less than 6

characters 60% of the passwords were a limited set

of alphanumeric The most common password “123456”

@makash | akashm.com | That Web Application Security Guy

Page 4: Secure passwords-theory-and-practice

Something to think about Only 0.2% of all the passwords were what

would be considered strong. These passwords were longer than 8

characters Contained a mixture of special characters,

numbers and both upper and lower case. 23,000 passwords were set to “rockyou”

But even for the 0.2% people with strong passwords it didn’t matter, the passwords were still being stored in clear text.

Source: Imperva Consumer Passsword Practices report

@makash | akashm.com | That Web Application Security Guy

Page 5: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Protecting User Information User data protection has many different

levels. This changes for financial data, medical data etc.

At the minimum if we assume the worst wherein either the server is hacked or the database is copied the first level of protection will be encryption. Based on the type of encryption and the strength of the keys the original data can be recovered.

Page 6: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Protecting User Information If our base goal is to protect the user

login information stored in the database ( and not travelling over the wire/network ) then we need to use 1 way encryption ( also called hashing ) with a salt  ( a randomly generated seed value ).

saltedhash(password) = hash(hash(password).salt)

Page 7: Secure passwords-theory-and-practice

Different ways to store passwords in web apps Passwords in clear text.

Simplest indicator, forgot password email will give you the password!

Password is hashed No way to get the original password back

easily, forgot password will send a unique link

Password is hashed with a static salt Password is hashed with a dynamic salt

@makash | akashm.com | That Web Application Security Guy

Page 8: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

What is hashing? When we talk about hashing I mean

“Cryptographic hash function” only From Wikipedia A cryptographic hash function is a procedure that

takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an accidental or intentional change to the data will change the hash value. The data to be encoded is often called the "message," and the hash value is sometimes called the message digest or simply digest.

Page 9: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

What is hashing? Ideally each digest/hash created by the

hashing function is completely unique. The hashing is defined as 1 way encryption. Once you hash a message there is no way to

get the original back from the digest/hash. Till today MD5 is popular for most basic web

applications not storing sensitive data. But SHA-1 and SHA-256 are preferred if you are going to implement your application now.

Page 10: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Crypto Hash Functions The most common ones being used for

storing passwords are MD5 – 32 bit SHA-1 - 160 bit SHA-256 – 256 bit

If this all looks so secure and hi-fi why do we need to do anything else with passwords?

Page 11: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

What are Rainbow Tables A rainbow table is a precomputed table for

reversing cryptographic hash functions, usually for cracking password hashes.

Tables are usually used in recovering the plaintext password, up to a certain length consisting of a limited set of characters. It is a form of time-memory tradeoff, using less CPU at the cost of more storage.

The basic defence is to employ a salt to make this attack infeasible.

Page 12: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Project Rainbow Crack It is easier than it sounds Image http://project-rainbowcrack.com Tables can be downloaded from the

same website.

Page 13: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

What is a salt? A salt consists of random bits consisting

one of the inputs to a one-way function. The other input is usually a password or

passphrase. The output of the one-way function can

be stored rather than the password, and still be used for authenticating users.

Page 14: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

What is a salt? The benefit provided by using a salted

password is rendering a simple dictionary attack against the stored values rather impractical provided the salt is large enough.

Without salts, an attacker who is cracking many passwords at the same time only needs to hash each password guess once, and compare it to all the hashes.

Page 15: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Clear text password attacks Users reuse passwords, stolen

passwords will be used to login to other websites.

The attacker needs to just steal the database of the web application somehow.

Once that is done the passwords and email user names will yield many more accounts.

Page 16: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Hashed password; no salt attacks Passwords are stolen. The attacker has

all the hashed passwords stored locally. All they need to do is run it against

rainbow tables they have to get the original passwords.

Considering the basic passwords people choose this will yield many account credentials to them.

Page 17: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Hashed password; static salt attacks Attacker steals database. They will need to steal the static salt

present in the source code of the application.

Once they have that then they can run their rainbow tables to get the original passwords.

Page 18: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Hashed password; static salt attacks Based on the length of the salt the

storage of rainbow tables can become very huge

For a salt with 12 bits 4096 possible salt values. Therefore 4096 rainbow tables at least.

Page 19: Secure passwords-theory-and-practice

@makash | akashm.com | That Web Application Security Guy

Hashed password; dynamic salt attacks Passwords are stolen. The attacker has

all the hashed passwords stored locally. Now to check against each and every

hashed password they need to generate a dynamic salt for each user entry.

Even if two users have the same password after hashing with dynamic salt the hash created will look completely different.

Page 20: Secure passwords-theory-and-practice

@makash | akashm.com - That Web Application Security Guy

Questions? Any questions About me

Akash Mahajan ( google me ) That Web Application Security Guy Web Security Consultant @makash on Twitter || http://akashm.com