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: Lew on 30 Sep 2009 16:23 Arne Vajhøj wrote: > You are correct. > > My mistake. > Thank you, Arne, for demonstrating how a person can take correction without thinking that someone accused him of lying. You learned something, and so did everyone reading this thread. You are a true asset to the Java programming community. -- Lew
From: Ken on 1 Oct 2009 02:02 Arne Vajhøj wrote: > Dave Searles wrote: > > Arne Vajh�j wrote: > >> 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. > > > > Whaaat? Nonsense. > > It is true. > > >> The use of salt makes all dictionary attacks more difficult, because > >> it invalidates pre-calculated dictionaries. > > > > Moving the hashing of the dictionary out of the loop only occurs when > > there's a loop (multiple passwords being attacked) to move it out of. > > It's that move that salting makes impossible. > > It is: > > no salt => > > for username, hashedPassword in passwordFile: > word = lookup_in_internet_database(hashedPassword) > print username, word # pwned! > > same salt for all users => > > for word in dictionary: > hashedWord = hash(salt, word) > for username, hashedPassword in passwordFile: > if (hashedPassword == hashedWord): > print username, word # pwned! > > different salt for each user => > > for word in dictionary: > for username, salt, hashedPassword in passwordFile: > hashedWord = hash(word, salt) > if (hashedPassword == hashedWord): > print username, word # pwned! > > Arne If the system has proper file system security in place and they still manage to get to the hash file then we must assume that the salts will be known too (unless they are on yet another system). It would be a very good idea to set up some sort of tripwire to set off the fact that someone has read your hashes. I think simple is best. There is nothing wrong with clear text passwords stored on a system that has good file security, few admins, few but well known and well tested network services AND is physically secure. The last part can't be overlooked. This will sound a little extreme but if you want to talk about "hacked" think about how long it would take to get into your personal system using someone else computer and just your wits... now think about how fast it would be with a fire axe starting at your front door. In most cases the second is more practical. Protecting the password file in the ways described is a good thing but if you consider the security measures that have all ready failed to allow this, why not just assume that the attacker has write access too!
From: Dave Searles on 1 Oct 2009 15:16 Arne Vajh�j wrote: > Eric Sosman wrote: >> Arne Vajh�j wrote: >>> 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. >> >> Don't you mean "polynomial" instead of "exponential?" >> The number of possible passwords of length N from an alphabet >> of size R is exponential in N, but only polynomial in R. >> Increasing from R to R+r gives polynomial, not exponential, >> growth. To get exponential growth, lengthen the password from >> N to N+n symbols. > > You are correct. You are both correct. "Leet" substitutions like "pa55w0rd" polynomially increase the search space by increasing R. Things like "password1" appending random digits, concatenating more than one word, etc. increase the search space exponentially by increasing N (assuming longer suffixes may be used, e.g. "password117", and longer chains of words). The best defense is still random alphanumeric chars; that gives you the fastest exponentially-growing search space for a given number of characters. It's the "all suffix, zero dictionary words" limiting case.
From: Dave Searles on 1 Oct 2009 15:16 Lew wrote: > Arne Vajh�j wrote: >> You are correct. >> >> My mistake. > > [gratuitous personal attack deleted] Bite me.
From: Dave Searles on 1 Oct 2009 15:18
Arne Vajh�j wrote: > Dave Searles wrote: >> Arne Vajh�j wrote: >>> 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. > [misquotes me] Hey! >> Whaaat? Nonsense. > > It is true. No, it is not; I am NOT a liar. >>> The use of salt makes all dictionary attacks more difficult, because >>> it invalidates pre-calculated dictionaries. >> >> Moving the hashing of the dictionary out of the loop only occurs when >> there's a loop (multiple passwords being attacked) to move it out of. >> It's that move that salting makes impossible. > > It is: > > no salt => > > for username, hashedPassword in passwordFile: > word = lookup_in_internet_database(hashedPassword) > print username, word # pwned! > > same salt for all users => > > for word in dictionary: > hashedWord = hash(salt, word) > for username, hashedPassword in passwordFile: > if (hashedPassword == hashedWord): > print username, word # pwned! > > different salt for each user => > > for word in dictionary: > for username, salt, hashedPassword in passwordFile: > hashedWord = hash(word, salt) > if (hashedPassword == hashedWord): > print username, word # pwned! > > Arne I don't consider "no salt" and "same salt for all users" to be meaningfully distinct. "Same salt for all users" is really just "no salt" with a slightly different hashing algorithm. |