Half hashed passwords for safer storage

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Post Reply
klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Half hashed passwords for safer storage

Post by klondike » 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 :P).
* 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.

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: Half hashed passwords for safer storage

Post by klondike » 28 Mar 2012, 21:35

No edit? Well this propossal ensures a long enough salt will be used always, yeah 65 bytes of salt is more than enough but there is no way to use less with 63 character passwords (which will otherwise have 1 byte).

* 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 whose size is twice 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 + the hash blocksize (or all of them if 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 n, hs.
* When issuing a GPA we issue r plus at least 24 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, n, hs and s. We initialize the state of the hash function to h' and process r (minus the first n characters) concatenated with s, afterwards we pad the result taking into account the real size of the hash is the size of the data we hashed now plus 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. We also fixed the issue that only one byte of data is salted when the password size % blocksize is blocksize -1.

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 128 bytes (for tiger) of additional data on the protocol (which when converted to base32 are around 206 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.[/quote]

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Half hashed passwords for safer storage

Post by Crise » 10 Apr 2012, 12:52

ADC really needs a login sequence that would allow client to send a hashed password when registering, ie. transmit plain text password to hub the least number of times possible (preferably not at all). That said I haven't thought so much as to what that would mean in practice.

Post Reply