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.
|
