Putting passwords in a properties file?
in [Java Help]
|
Prev: Some projects were hidden because they exist in the workspace directory
Next: light weight types
From: Mike Schilling on 25 Sep 2009 13:11 grz01 wrote: > On Sep 25, 3:29 pm, Nigel Wade <n...(a)ion.le.ac.uk> wrote: >> I would think it's pretty robust. It's what UNIX does (and maybe has >> always done). UNIX doesn't store passwords in the passwd database (or >> whatever other database it uses e.g. LDAP). It uses the crypt hashing >> function and stores the hash. Any time it needs to authenticate a >> password against the hash it crypts the password using the same >> algorithm and compares that to the stored hash. >> >> -- >> Nigel Wade > > > No, its not quite what un*x does anymore -- piece-of-cake today to > brute-force the passwd file if you use public pw-hashes. As illustrated in Cliff Stoll's wonderful _The Cuckoo's Egg_.
From: alexandre_paterson on 27 Sep 2009 12:05 On Sep 25, 5:11 pm, grz01 <gr...(a)spray.se> wrote: .... > The pw-hashes must be stored in a protected place (unless you're fine > with "toy security"). Wait... (my post is apparently unrelated to the OP's problem btw) I agree that storing {hash} is stupid, but long before shadow passwords Un*x systems where already storing: {hash(password+salt),salt}. (a long time ago it was a lame 12-bit salt, but nothing stops me nor anyone from using a much bigger salt, which I sure did ;) Are you saying that storing {hash(password+64-bit salt), 64-bit salt} without the equivalent of shadow passwords would be "toy security"?
From: alexandre_paterson on 27 Sep 2009 12:17 On Sep 25, 6:11 pm, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: .... > > No, its not quite what un*x does anymore -- piece-of-cake today to > > brute-force the passwd file if you use public pw-hashes. > > As illustrated in Cliff Stoll's wonderful _The Cuckoo's Egg_. What the 20-years old book shows is a dictionary attack on a passwd file that is using no salt. Modern Un*x distro ('modern' as in "since at least 20 years") are storing {hash(password+salt),salt} instead of {hash} as I explained in the other post. The attack used in the book only works on the most naive form of password hash storage. What about you guys all bring your dictionary attacks/rainbow tables/ terabytes of memory/tables supercomputers and I publish here in the clear a cryptographic hash of a password using a 32-bit salt (and the 32-bit salt used of course)? Then we'll see if it's "piece-of-cake" and "toy security" and if 20 years old romance is adapted to modern form of password hash storage :)
From: Dave Searles on 27 Sep 2009 12:43 alexandre_paterson(a)yahoo.fr wrote: > On Sep 25, 5:11 pm, grz01 <gr...(a)spray.se> wrote: > ... >> The pw-hashes must be stored in a protected place (unless you're fine >> with "toy security"). > > Wait... (my post is apparently unrelated to the OP's problem btw) > > I agree that storing {hash} is stupid, but long before > shadow passwords Un*x systems where already storing: > > {hash(password+salt),salt}. > > (a long time ago it was a lame 12-bit salt, but nothing stops me > nor anyone from using a much bigger salt, which I sure did ;) > > Are you saying that storing {hash(password+64-bit salt), 64-bit salt} > without the equivalent of shadow passwords would be "toy security"? It seems to me that if you have the hash and the salt, and know the algorithm for convolving the password with the salt, then you can still carry out a dictionary attack. On the other hand, if the password is something like zs1df3rh, good luck with that.
From: Tom Anderson on 27 Sep 2009 13:00
On Sun, 27 Sep 2009, Dave Searles wrote: > alexandre_paterson(a)yahoo.fr wrote: >> On Sep 25, 5:11 pm, grz01 <gr...(a)spray.se> wrote: >> ... >>> The pw-hashes must be stored in a protected place (unless you're fine >>> with "toy security"). >> >> Wait... (my post is apparently unrelated to the OP's problem btw) >> >> I agree that storing {hash} is stupid, but long before >> shadow passwords Un*x systems where already storing: >> >> {hash(password+salt),salt}. >> >> (a long time ago it was a lame 12-bit salt, but nothing stops me >> nor anyone from using a much bigger salt, which I sure did ;) >> >> Are you saying that storing {hash(password+64-bit salt), 64-bit salt} >> without the equivalent of shadow passwords would be "toy security"? > > It seems to me that if you have the hash and the salt, and know the algorithm > for convolving the password with the salt, then you can still carry out a > dictionary attack. > > On the other hand, if the password is something like zs1df3rh, good luck with > that. The point is that without a salt, you can make one pass through the dictionary and recover *all* the passwords in the file: for word in dictionary: hashedWord = hash(word) for username, hashedPassword in passwordFile: if (hashedPassword == hashedWord): print username, hashedWord # pwned! Whereas with a salt, you need to do a different computation for each user: for word in dictionary: for username, salt, hashedPassword in passwordFile: hashedWord = hash(word, salt) if (hashedPassword == hashedWord): print username, hashedWord # pwned! Note that in the former case, the hashing operation is inside the word loop; in the latter, it is inside the loop over the passwords. If you have w words and u users, then the former is O(w) to crack all users, whereas the latter is O(w*u) to crack them all. Correspondingly, the time taken to crack any one user is something very vaguely like O(w/u) in the former case, and O(w) in the latter. Which means that Alexandre's challenge is actually rather silly. Adding salt doesn't make any single password more secure, it makes the population of passwords more secure. If he's giving us a single password to work on, then the salt will make no difference. tom -- There is no latest trend. |