Half hashed passwords for safer storage
Posted: 11 Mar 2012, 05:31
First and as a bit of context the original post which still needed some polish: http://sourceforge.net/mailarchive/foru ... plus-devel
So after taking my math gear here is now the complete propossal which won't modify the client behaviour nor the protocol (insert a YAY here ).
* We define two functions hash1 and hash2.
* hash1 is a modified version of the hash which takes as input a password p, the password length l and a random block of data r with the hash block size and returns the internal status of the hash after hashing p+r' (excluding any padding) where r' is as many characters of the salt as are needed to make the data the size of the hash blocksize (or all of them is p has the size of the block it self).
* We then store h', r, the number of characters of r used n, and the size of p plus the previous number s, hs.
* When issuing a GPA we issue r plus at least other prepended bytes of random data d. Don't try to be smart making the size of the prepended data depend on the amount of bytes of r used by hash1, if you do then the password size information may be leaked.
* We receive the result as normal, we'll call that h2.
* Now we call hash2. Hash2 takes as input the status h', r (discarding the first n characters) prepended to s (which we call rs now), the size of rs, h' and hs. We initialize the state of the hash function to h' and process rs, afterwards we pad the result taking into account the real size of the hash is the size of rs+hs and finally return the appropiate amount of status h2'.
* If h2' is equal to h2 the authentication succeeds.
In this version since the amount of equal data of the salt is the same independently of the password size we ensure that the a passive eavesdropper can't know the password size from this data.
Cons:
* Although the password is hashed a hacker getting the database can still know the password length (which could speed up attacks slightly).
* Passwords need to be hashed and stored once for each supported hash algorithm.
* We need to pass 64 bytes (for tiger) of additional data on the protocol (which when converted to base32 are around 103 bytes).
* For common passwords more storage space is needed in the database.
Pros:
* Hash calculations on the server are slightly faster since we use precomputed results.
* The password is stored encrypted AND salted making attacks (even knowing the password size) a bit harder.
* The system requires no modifications of the protocol or client side.
* The system still ensures that an attacker listening to the conversation between the client and the server can't derive any information regarding the password (although he can try offline attacks).
Other considerations:
* The current GPA->PAS protocol is inherently unsecure since an active attacker can fool the client into providing an answer which he would later use against the server thus we still need other ways of authentication to ensure security.
* In a similar way there is still a problem when changing the password, currently the password is changed by sending it in clear text. Better ways of password change are also needed.
So after taking my math gear here is now the complete propossal which won't modify the client behaviour nor the protocol (insert a YAY here ).
* We define two functions hash1 and hash2.
* hash1 is a modified version of the hash which takes as input a password p, the password length l and a random block of data r with the hash block size and returns the internal status of the hash after hashing p+r' (excluding any padding) where r' is as many characters of the salt as are needed to make the data the size of the hash blocksize (or all of them is p has the size of the block it self).
* We then store h', r, the number of characters of r used n, and the size of p plus the previous number s, hs.
* When issuing a GPA we issue r plus at least other prepended bytes of random data d. Don't try to be smart making the size of the prepended data depend on the amount of bytes of r used by hash1, if you do then the password size information may be leaked.
* We receive the result as normal, we'll call that h2.
* Now we call hash2. Hash2 takes as input the status h', r (discarding the first n characters) prepended to s (which we call rs now), the size of rs, h' and hs. We initialize the state of the hash function to h' and process rs, afterwards we pad the result taking into account the real size of the hash is the size of rs+hs and finally return the appropiate amount of status h2'.
* If h2' is equal to h2 the authentication succeeds.
In this version since the amount of equal data of the salt is the same independently of the password size we ensure that the a passive eavesdropper can't know the password size from this data.
Cons:
* Although the password is hashed a hacker getting the database can still know the password length (which could speed up attacks slightly).
* Passwords need to be hashed and stored once for each supported hash algorithm.
* We need to pass 64 bytes (for tiger) of additional data on the protocol (which when converted to base32 are around 103 bytes).
* For common passwords more storage space is needed in the database.
Pros:
* Hash calculations on the server are slightly faster since we use precomputed results.
* The password is stored encrypted AND salted making attacks (even knowing the password size) a bit harder.
* The system requires no modifications of the protocol or client side.
* The system still ensures that an attacker listening to the conversation between the client and the server can't derive any information regarding the password (although he can try offline attacks).
Other considerations:
* The current GPA->PAS protocol is inherently unsecure since an active attacker can fool the client into providing an answer which he would later use against the server thus we still need other ways of authentication to ensure security.
* In a similar way there is still a problem when changing the password, currently the password is changed by sending it in clear text. Better ways of password change are also needed.