Re: (Ovid) (2): Too Convenient Security?

It's not that keeping the salt seperate would be so hard, it's that it wouldn't buy you anything. A modern OS will protect the password hashes+salts together, so that even if a cracker gets the list of users, they've got nothing to work on. If you system gets so cornholed that the cracker can read the hashes, it's safe to assume that they can also get the salts.

The job of the salt is to prevent dictionary attacks, i.e. a precompiled list of passwords and possible hashes. You can think of the salt, then, as part of the hash itself.

What you're suggesting (and it's not a bad idea, just a really awkward one :-) is to effectively split the hash into two seperate pieces. If you did this it would actually make more sense to make each part half salt and half hash. Then store the two fragments independently, such that if one is compromised it doesn't mean doom for the other one. Trouble is, the two halves would have to be really different - different machine, different OS, different database, different admin password - just to be sure that a compromise on one wouldn't affect the other.

There's probably more mileage (and less heartache) in using a good, trutworthy crypt algorithm like MD5crypt or (better yet) bcrypt (as used in OpenBSD), whish uses Blowfish. And pick good passwords. The idea here is that the algo itself is such a swine that dictionary attacks are infeasible and brute-forcing a hash (even with the salt) takes too long to be practical.

Comment on Re: (Ovid) (2): Too Convenient Security?

Replies are listed 'Best First'.
Re: Re: (Ovid) (2): Too Convenient Security? by jreades (Friar) on Jan 08, 2002 at 04:14 UTC
It's not that keeping the salt seperate would be so hard, it's that it wouldn't buy you anything. A modern OS will protect the password hashes+salts together, so that even if a cracker gets the list of users, they've got nothing to work on. There might, however, be an exception to this principle -- two machines connected by a physical link or over a network using one of the secure protocols (ssh/https). In this scenario, you could, for instance, hash the password on one machine, hash the salt on the other, and then hash some form of the two together to gain access to the target machine... kind of a bizarre setup, but it just might work. In this situation, you acutally could keep your salts in one place and your keys in another. The two machines would have to be able to talk to each other in a trusted way (no man-in-the-middle attacks), but you're essentially requiring the cracker to gain access to two machines in order to understand what's going on. Of course, on the flip side you introduce new points of failure... especially over an insecure network. Just a thought, and I profess only the most basic knowledge of cryptography.	[reply]

Replies are listed 'Best First'.

Re: Re: (Ovid) (2): Too Convenient Security?
by jreades (Friar) on Jan 08, 2002 at 04:14 UTC

It's not that keeping the salt seperate would be so hard, it's that it wouldn't buy you anything. A modern OS will protect the password hashes+salts together, so that even if a cracker gets the list of users, they've got nothing to work on.

There might, however, be an exception to this principle -- two machines connected by a physical link or over a network using one of the secure protocols (ssh/https). In this scenario, you could, for instance, hash the password on one machine, hash the salt on the other, and then hash some form of the two together to gain access to the target machine... kind of a bizarre setup, but it just might work.

In this situation, you acutally could keep your salts in one place and your keys in another. The two machines would have to be able to talk to each other in a trusted way (no man-in-the-middle attacks), but you're essentially requiring the cracker to gain access to two machines in order to understand what's going on.

Of course, on the flip side you introduce new points of failure... especially over an insecure network.

Just a thought, and I profess only the most basic knowledge of cryptography.

[reply]