in reply to Re: Too Convenient Security?
in thread Too Convenient Security?

I'm seeing now the dangers of a static salt, but I'm still wondering if it's too much trouble to keep the salt and password separate. Also, I should mention that even if a cracker grabs my salt (crackers grabbing salt?), that still doesn't grant them access to the database with the password hashes. Alternatively, getting access to the database doesn't give them access to the salt. That would seem more secure than the random salt.

Of course, since I was using a simple digest, this is much easier to crack than the Crypt::PasswdMD5, so a bruteforce is more feasible, though it's still going to be difficult).

So, are there any systems which have distinct salts for each password and keeps the salts separate? Would this be a good or bad idea?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: (Ovid) (2): Too Convenient Security?
by n3dst4 (Scribe) on Jan 07, 2002 at 22:39 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. 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.

[reply]
      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]

In Section Meditations