Re: public key password authentication

Kristian Gjøsteen writes:
Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx> wrote:
Are there useful and efficient password auth methods where the server
admin, possessing a user's server-side secret and a log of his auth
sessions, will not learn how to authenticate as the user?

Sure, that's what identification protocols are all about. Usually,
things like zero knowledge make an appearance.

OK, that was a good google term. Thanks.

In particular, are there methods that do not use a lot of server CPU
time compared to a hash-based challenge/response method like DIGEST-MD5?

I think most zero-knowledge stuff is based on number theoretic
constructions, and tend to require significant computational resources.

Sorry, I don't know what I was thinking when I wrote that. I know
PK-like stuff is expensive. Not "avoid this in high-performance
servers"-kind of expensive, I guess.

You can never prevent the server from doing an exhaustive search for
the user's secret (the server must have a yes-no oracle for this
secret in order to do identification).

Well, true enough. I should have said, beyond that, and dictionary
attacks.

If you just want to prevent him from easily impersonating the user
towards other servers,

No, I mean the server itself - e.g. if the server's security is not
trusted. And I figure that if even the server admin can't find how to
authenticate to the server itself short of with a brute-force attack,
then it's as secure as it can get without things like a hardware black
box.

you can compute the server's secret as hash(server name || user's
secret).

And then with a number of auth methods, either the user must send a
cleartext password (hopefully in a secure channel:-) or the hash
functions as a cleartext password for that particular auth mechanism.

Though actually I did find a draft for a hash-based method where that is
not true: SCRAM (draft-newman-auth-scram-04.txt) - neither the server
secret nor observing an auth session will tell you how to authenticate,
but the combination will. Basically it stores a salt and two hashes of
(salt, password). The server needs 1st hash XOR the client-provided
proof as an argument to compute a hash which should match the 2nd hash.

--
Regards,
Hallvard
.

Relevant Pages