Doubly Salted passwords proposal

[klondike]

This is a proposal to fix a small drawback on the current Salted password system.

With the current system, either passwords have to be stored unencrypted on the database, or the same SALT has to be sent always. This new system uses an approach similar to the http digest algorithm in order to provide a way to ensure the password is SALT encrypted on both sides.

For this feature, the proposed identity flag is SALT2.

What this extension proposes is the modification of the GPA and PAS actions to support a two hash SALT system. The proposal is as follows.

When both, client and server support the SALT2 feature, then the GPA and PAS actions will instead be as follow:

GPA data1 data2 data3
Here data1 keeps its meaning being at least 24 random bytes encoded in base32.
data2 is a continuously increasing number which must be different at least between each correct authentication for the user. This number must be stored by the server. The value is also encoded in base32.
data3 is a string of data, no minimal length required, encoded in base 32. This string must be stored and be the same between sessions for the same user.

PAS data1 data2 data3
Here data1 is at least 24 random bytes encoded in base32.
data2 is a continuously increasing number which must be different between each authentication for the client. This number must be stored by the client. The value is also encoded in base32.
data3 is the result of applying the following operation: H(H(password+data3')+data1+data2+data1'+data2'). Where data3' data1' and data2' come from the previous GPA issued by the hub and data1 and data2 are the ones sent with the PAS command. The operation H() means apply the session hash function and + means concatenation of binary data. This data is encoded in base32.

This proposal allows both client and server to store the H(password+data3') instead of the plain text passwords, making it harder for an attacker to use the obtained data after an attack.

Also gives the client a saying when sending the salted password which may be useful to avoid certain attacks made by a rogue server like sending a weak data in the GPA allowing a precomputed dictionary attack.

[darkKlor]

Quick thoughts, before sleep.

Positives:
- Storing passwords on the server is naughty, anything that reduces that is good.

Negatives:
- If a server wants your password in plain-text it won't support SALT2... a client would need to fail or risk the server capturing the password.
- Using client certificates for authentication in ADCS would be better than passwords.

[Pretorian]

Without discussing whether this proposal is more secure or not, some things that should be noted;

A four character code is.. Four characters, not five...
It is probably most wise to either create a new command (3 characters) or to use named parameters, instead of  using positional parameters, since that could break previous implementations.

[cologic]

If the slightly insecure password protocol is updated again, better to just switch to and/or add support for something standard such as SRP.

[klondike]

Quick thoughts, before sleep.

Positives:
- Storing passwords on the server is naughty, anything that reduces that is good.

Negatives:
- If a server wants your password in plain-text it won't support SALT2... a client would need to fail or risk the server capturing the password.
- Using client certificates for authentication in ADCS would be better than passwords.

A client can detect that and warn the user. On certificates I agree public keys are the best approach.

Without discussing whether this proposal is more secure or not, some things that should be noted;

A four character code is.. Four characters, not five...
It is probably most wise to either create a new command (3 characters) or to use named parameters, instead of using positional parameters, since that could break previous implementations.

Not sure but can we use PAS2 and GPA2?

If the slightly insecure password protocol is updated again, better to just switch to and/or add support for something standard such as SRP.

SRP has the problem of using exponentiation which can make things a bit slow but anyway I agree, it could be a good approach. What I'm not very sure is if it will work well if the salt is always the same.

[Pretorian]

klondike: What you signal in the SUP or in the INF's SU field must be 4 characters ("BASE", "TIGR"). Command names ("INF", "STA", "GPA", "PAS") must be 3 characters.

[klondike]

klondike: What you signal in the SUP or in the INF's SU field must be 4 characters ("BASE", "TIGR"). Command names ("INF", "STA", "GPA", "PAS") must be 3 characters.

Ok, before rolling out the proposal, can you tell me if there is a way specified in the protocol to set the password for the user? (not to assert it during auth but to store it in the hub database). The SRP protocol involves the client choosing the SALT used to store the password for additional security.

I will try to get around that problem though, but I doubt it is possible.