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: Lothar Kimmeringer on 30 Sep 2009 05:11 jebblue wrote: > On Tue, 29 Sep 2009 10:28:58 +0200, Lothar Kimmeringer wrote: > >> Problem is that databases etc. don't accept hashes of passwords but only >> the real stuff. > > What about Base 64 encoding of the hash? That wouldn't change anything. We're not talking about password a server-application expect from others while they authenticate themselfs to the server but the server needs to authenticate itself to some other process (e.g. the database working in the backend). So you need the real password to be able to do so. A hash is a one way function, i.e. after hashing a password (or any other value) you have no way to calculate the original passwort out of a hash, so if you only have a hash-value it doesn't matter if you send it to the peer as raw data, base-64-encoded or with caramel-flavor, the authentication will fail. Regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions!
From: Arne Vajhøj on 30 Sep 2009 13:54 Lothar Kimmeringer wrote: > senatov wrote: >> it is a good idea and standard solution to write in config file >> not a password self , but his controll summ, hash number etc etc. >> >> It's much more convinient to use. > > Problem is that databases etc. don't accept hashes of passwords > but only the real stuff. That is not a problem - it is the entire point in using hashes - if the client send the hash to the server, then it is storing the password unhashed in the database. Arne
From: Arne Vajhøj on 30 Sep 2009 13:56 Tom Anderson wrote: > On Mon, 28 Sep 2009, Mike Schilling wrote: >> Dave Searles wrote: >>> I still think the surest bet is to avoid using dictionary-attackable >>> passwords. :) >> >> Absolutely, which is why many environments require passwords to >> contain both letters and numbers. > > Which is absolutely not a good defence. "pa55w0rd" and "password1", > which are the kind of thing this rule usually engenders, are not a lot > more difficult to guess than "password" - it's a small constant-factor > increase in the amount of work a password cracker has to do. The effect is still exponential related to length. Arne
From: Arne Vajhøj on 30 Sep 2009 13:59 Dave Searles wrote: > markspace wrote: >> Dave Searles wrote: >>> >>> 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. >> >> >> A dictionary attack pre-computes the hash, and then just scans the >> password file for a simple string match. The salt defeats this, >> because each bit in the salt doubles the storage needed for the >> dictionary. >> >> <http://en.wikipedia.org/wiki/Salt_%28cryptography%29> >> >> You're right in that if the password itself is weak and could be >> guessed, then all bets are off. > > As Tom explained, the salt does not make any single password harder to > crack, but it does slow down an attack aimed at getting all (or the > first) dictionary-vulnerable password. > > I was thinking in terms of protecting a particular targeted account > (yours, say, or the superuser account), while you two were apparently > thinking more of protecting all of the accounts in some statistical sense. No no no. The use of salt makes all dictionary attacks more difficult, because it invalidates pre-calculated dictionaries. Use of different salts per user makes it more difficult to find one among many passwords. Arne
From: Arne Vajhøj on 30 Sep 2009 14:05
Tom Anderson wrote: > 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. You use of big-O is rather unconventional. But we understand the point. Very important: you logic assumes different salts per user. That is good practice. But I think it should be emphasized. > 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. The use of salt makes all dictionary attacks more difficult, because it invalidates pre-calculated dictionaries. Use of different salts per user makes it more difficult to find one among many passwords. Arne |