Secure passwords-theory-and-practice
Upcoming SlideShare
Loading in...5
×
 

Secure passwords-theory-and-practice

on

  • 2,793 views

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

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

Statistics

Views

Total Views
2,793
Views on SlideShare
2,783
Embed Views
10

Actions

Likes
0
Downloads
58
Comments
0

3 Embeds 10

http://www.linkedin.com 5
https://www.linkedin.com 4
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Secure passwords-theory-and-practice Secure passwords-theory-and-practice Presentation Transcript

  • Safe Passwords – In theory & practice
    Akash Mahajan
    • Web Security Consultant
    • @makash on Twitter
    • http://akashm.com
    @makash | akashm.com - That Web Application Security Guy
  • 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
  • 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
  • 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
  • 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.
    @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)
    @makash | akashm.com | That Web Application Security Guy
  • 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
  • @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.
  • @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.
  • 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?
    @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.
    @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.
    @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.
    @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.
    @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.
    @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.
    @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.
    @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.
    @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.
    @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
    @makash | akashm.com - That Web Application Security Guy