Re: idea for OTP system, comments desired
John Bethencourt writes:
Here's the protocol in a more concise form:
[first authentication]
Client --> username --> Server Client <-- 'initial password?' <-- Server Client --> initialpass --> Server Client <-- r_0 <-- Server Client --> h(h(s.r_0)) --> Server
[subsequent authentications]
Client --> username --> Server Client <-- r_x <-- Server Client --> h(s.r_x) --> Server Client <-- r_y <-- Server Client --> h(h(s.r_y)) --> Server
One thing that is unclear in your protocol is whether s, which I think is the same as initialpass, is stored permanently on the server. If so, then when the server receives h(s.r_x), it can do two checks. The check you described is that the hash of this matches the value the client sent previously, h(h(s.r_x)). The other is that the server can construct s.r_x since it knows both of these values, and then compare h(s.r_x) with what the client sent. This has two problems. First, it makes the sending of h(h(s.r_x)) unnecessary since the server can verify the client's response just using s. And second, s is a sensitive value which if stolen could be used at some later time to impersonate the user. So I will assume that the server doesn't store s, in which case I don't see why it needs to see initialpass in the first place. In that case the protocol basically says, each time you log on you provide a hash value for which you will provide the hash input next time you log on. The purpose of the r_x values is to keep the user from having to save state; he can compute h(h(s.r_y)) and then forget it, because next time he logs on the server will remind him of what r_y is. The main security problem I see is that an eavesdropper sees r_x and h(s.r_x), allowing him to do a dictionary attack on s. You could use a really slow hash function to slow this attack down, but it is a serious vulnerability. Given that you are using client software to authenticate, I suggest pursuing SPEKE-style password-authenticated key exchange. There are a number of these systems (some patented) which feature immunity to dictionary attacks on the password.
Thanks for responding. Nomen Nescio wrote:
One thing that is unclear in your protocol is whether s, which I think is the same as initialpass, is stored permanently on the server.
Oh, no, that's not what I meant. s is not the same as initialpass, and s is not stored anywhere. The server never knows what s is, and the client only uses it during an authentication and then forgets it.
If so, then when the server receives h(s.r_x), it can do two checks. The check you described is that the hash of this matches the value the client sent previously, h(h(s.r_x)). The other is that the server can construct s.r_x since it knows both of these values, and then compare h(s.r_x) with what the client sent.
This has two problems. First, it makes the sending of h(h(s.r_x)) unnecessary since the server can verify the client's response just using s. And second, s is a sensitive value which if stolen could be used at some later time to impersonate the user.
Right, that would be horribly wrong.
So I will assume that the server doesn't store s, in which case I don't see why it needs to see initialpass in the first place.
It isn't really needed; it's just for setting up an account. The alternative would be for the user to pick s and r_0 and give the sysadmin h(h(s.r_0)) right off the bat. I just thought this would be more convenient.
In that case the protocol basically says, each time you log on you provide a hash value for which you will provide the hash input next time you log on. The purpose of the r_x values is to keep the user from having to save state; he can compute h(h(s.r_y)) and then forget it, because next time he logs on the server will remind him of what r_y is.
Yes, that's the idea.
The main security problem I see is that an eavesdropper sees r_x and h(s.r_x), allowing him to do a dictionary attack on s. You could use a really slow hash function to slow this attack down, but it is a serious vulnerability.
Good point; that is a big flaw. A precomputed dictionary attack won't work, but if a user picks a weak password, guessing it would be feasible. I guess you could also do a dictionary attack against S/Key, but it would take longer since for each trial you would have to compute the, say, 50th hash.
Given that you are using client software to authenticate, I suggest pursuing SPEKE-style password-authenticated key exchange. There are a number of these systems (some patented) which feature immunity to dictionary attacks on the password.
Cool; thanks for the pointer. I hadn't heard of SPEKE before. Dictionary attack immunity is a really nice feature. Cheers, John Bethencourt
participants (2)
-
John Bethencourt -
Nomen Nescio