Sunday, December 23, 2012

Hashing Passwords Security Attacks


"Salt doesn't prevent dictionary attacks, just precalculated dictionary attacks. In particular, it protects against rainbow tables (http://en.wikipedia.org/wiki/Rainbow_table) and also ensures that cracking one user's password doesn't automatically let you crack any user who shares that password."

http://stackoverflow.com/questions/1111494/are-hashed-and-salted-passwords-secure-against-dictionary-attacks

Dictionary and Brute Force Attacks
Lookup Tables
Reverse Lookup Tables
Rainbow Tables

http://crackstation.net/hashing-security.htm

Here's how to avoid those problems:
Set-Cookie: userName=Alice; authCode=eeba95a4...
Where: authCode=HMAC(ROWID, userName + ipAddr)
When you receive this cookie, look up the user in the database, recompute/verify the authCode in the cookie, using ROWID and ip address of the request. No need to store cookies in the database.
For extra crypto points, throw a salt parameter into the mix:
Set-Cookie: userName=Alice; salt=59843...; authCode=eeba9...
Where: authCode=HMAC(ROWID, userName + ipAddr + salt)
Salt value is generated randomly for every cookie you produce. There's no need to keep it a secret.

http://stackoverflow.com/questions/8529196/cookie-security?rq=1

Here is what you do need to store on the server - in order to authenticate each request.
UserId (obvious)
CookieHash (made out of userId, some secret private key and crypto randomly generated number)
LastLogin
SessionRenewed (useful for when to cancel someone's session eg. renew cookieHash every 10 min, otherwise log out user)
LastIP
What I store in cookie is following
UserId
CookieHash

http://stackoverflow.com/questions/6010567/how-to-remember-users-with-cookies-in-a-secure-way

No comments:

Post a Comment