From: klondike <klo...@kl...> - 2012-03-04 03:38:53
|
Hi, For now and thanks to Lanowen inspiration I'll propose an improvement over the current password storage scheme based on how tiger processes data that allows storage of unpadded encrypted passwords from which the only guessable data is the password length. The current state of art is as follows: S tells C GPA randomdata (at least 24 byte long) C tells S PAS base32(h(password|randomdata)) S calculates h(password|randomdata) and checks if it matches. This basically means that we have to either store the password in plain text to be able to check the value of the hash or keep random data constant and force a particular session hash in order to check the password allowing for replays. What we can do when h is the tiger algorithm is instead pad the password with enough data, which we'll call salt or S, to make a whole number of blocks (for example for an 16 character password this means 48 bytes of data) and store the result of the first iterations of tiger_block over said blocks along with this random data and the total number of iterations done. To prevent dictionary attacks we must ensure that salt is long enough (for example 16 bytes). Thus the protocol will work as follows: S tells C GPA salt|randomdata (at least 24 byte long) C tells S PAS base32(tiger2(password|randomdata)) S calculates tiger2(res,its,randomdata) and checks if it matches. Where tiger2 is a special implementation using res as initial values and adding its to the message length used for padding. For efficiency reasons randomdata shouldn't be longer than 55 bytes which ensures that no extra blocks are added when padding making hashing faster. Now the question is, what vulnerabilities does this proposal have? Well, since salt is constant along connections a passive eavesdropper may be able to guess the length of the password (modulo 64) by looking at which bytes on the GPA command are constant. Similarly somebody with access to the password database can know the exact password length by looking at the values of S and its. Obviously since passwords longer than 64 bytes are rare this usually means the eavesdropper can know the exact password size which can make dictionary attacks slightly easier against unsecure passwords by limiting the passwords to those of that fixed length. Please note that even when using a random data the attacker can still use dictionary attacks but they may be a bit harder since the password length will be unknown. So well, this still means we need something safer for password based authentication that allows the server to store the data in an unusable (for the attacker) state and ensure zero knowledge password proof is used for safety reasons, in my case my propossal is SRP with PBKDF2 though I'd like to hear some discussion. Yet for now and whilst we get this safer method into ADC (and wait for clients and servers to support it) we can use this proposal here to keep the passwords stored in an encrypted state (though usable for authentication against the server if guessed) whilst minimizing the amount of information we give to a passive eavesdropper. And now as usual, DISCLAIMER: Usually attacks on hashing functions tend to be independent from the padding used on the last block but this doesn't means attacks against the unpadded hash function are unexistant thus if any appears against unpadded tiger as used here don't say you weren't warned. |