Podcast: Play in new window | Download
Subscribe: iTunes | Android | RSS
Justin and Jason discuss StartupGuild’s early growth and some ideas for it’s future, how Anonymous is targeting Sony executives and whether Jason should start a podcast on government corruption, genetic screening and designer babies, the cost of context switching when juggling multiple client projects, the types of problems for which Node.js is best suited, the stupidity of blaming the Microsoft stack for MySpace’s demise, what’s driving Pluggio’s recent growth trend and ideas on how to goose it even more, dynamically adjusting equity allocations in bootstrapped startups and an update on Jason’s experiment with applying extrinsic motivation.
A few things:
1) Gattaca
2) I’m not a security expert, but there a few things to consider:
a) We are considering the case where the attacker already has access to your database. In that sense, the added time for using SHA2 vs SHA1 is not likely to protect you that much more (recommendations for SHA2 are not for password storage on the DB, but for document signing/public key stuff)
a) I believe that the recommended length of a salt is 12 random characters–and the primary reason for a salt is to decrease the probability of collisions with your hash, which makes them less susceptible to “birthday” attacks. The problem I see with Justin’s approach is that many user’s may have the same password and thus the same salt. Furthermore, how do you guarantee the length of the salt is sufficient (requiring 12 character passwords is not going to make users on most sites happy–especially if the consequences of compromise of the account is not high to them)? I think it’s safer to just go with the random approach
b) On this score, stretching and bcrypt may be your best bet–while I understand stretching, I still have a few questions:
1) NSA verified SHA1 and NIST ran the contest for SHA2 (and is still running the contest for SHA3), is there any certification for bcrypt?
2) For stretching, this is a naive question, but is it possible to make the hash less secure through repeated application (stretching)?
3) For Jason, I think both bcrypt and stretching preserve the length of the hash of password+salt, but how do you plan to handle going from SHA1 to SHA512 for people who use appignite without having to migrate the database?
I should note that the presence of the SALT also prevents rainbow table attacks, but beyond that I believe it is the birthday attack which determines the length that you set…
The reason I believe that using the password as a salt is less secure than a random stored salt, is that you are still relying on the strength of the password.
For example say my password is ‘password’, salting that will result in ‘passwordpassword’. If you look up some reasonable password dictionaries, many of the top used passwords will also have entries for doubles of the same password. ‘passwordpassword’ in md5 is 9dbb300e28bc21c8dab41b01883918eb, and a basic reverse lookup site:http://md5.gromweb.com/ found it.
Where as ‘password[12 chars of random text]’ will be much less likely to already be in a rainbow table.
My point:rainbows tables already have entries for doubles of many passwords, obviously it will be a small set, and reasonable passwords will not have entries for their doubles, but the basic hacker with a reasonable rainbow table will have more immediate successes, I believe in this senario than if the salt was random and stored else where.
@peter I didn’t think salt worked that way, I though it was an additional parameter to an encryption function that acted as a random seed for the algorithm
Regarding the salt discussion, the difference if that if the salt is a predetermined algorithm (in this case the password itself), then you can create *one* rainbow table for all the most common passwords that applies to all the entries in the database.
If the salt is a completely random number, a different rainbow table must be constructed for *each* entry in the database, which is more expensive.
😀
Why wouldn’t I increase my child’s ‘luck surface area’ 😉 through genetic modification?
I’d have to say as naturalist though, that such a quantity wouldn’t merely be just a function of the genome. If we define a state as the structure of all that exists, then the current state is merely a mapping of a previous state which was mapped to a state before that. If we’re to believe that transition between states is deterministic, all you’re left with is a regress of inevitable states. If there’s anything we can call a genetic luck surface area, it wasn’t just decided for me before I was born, but before I was even conceived.
Precomputed attacks become much easier if the salt isn’t random. To use a precompted attack against systems using Justin’s method :-), I would precompute hash values using, say, the most popular 2000 passwords as salts. In other words, I would precompute 2000 dictionaries. If I wanted to use a precomputed attack against systems using, say, a random 32 bit salt, I would need to precompute about 4 billion dictionaries. You can use additional steps after this, but it doesn’t alter the fact that a reasonable sized random salt provides much better protection against precomputed attacks.
I get why I’m wrong now, just needed a few thumps on the head!