idea for OTP system, comments desired
Nomen Nescio
nobody at dizum.com
Wed May 21 14:40:04 PDT 2003
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.
More information about the cypherpunks-legacy
mailing list