[x500standard] Re: New draft on password policy
- From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Thu, 24 Sep 2009 09:18:41 -0400
So many Davids! But the premise in Chadwick's original message was:
> the attached document contains an analysis of the alternative ways of
handling
> passwords, both storing them in the DSA and transferring them between
DUA and
> DSA in the bind and compare operations.
>
> Our analysis reveals that an optimal choice is the one proposed back
in 1990 ...
This entire discussion seems like it should have taken place in 1990.
It's 2009 now; just use PKI-based client-authenticated TLS for both user
authentication and session protection and be done with it. The problem
with "unless SSL is used" is that regardless of how strong the
authentication method is (challenge-response PKI, time-based OTP, SASL
SCRAM, ...), if there is no session protection, then the adversary can
just hijack the connection after authentication and do whatever he wants
to the DSA. As with http://riosec.com/files/gate-bypass.jpg, there's
little point in putting strong authentication on an unprotected channel.
But given that we're pretending to live in 1990, users don't have
asymmetric private keys and thus are stuck with passwords, and SSL isn't
used, so let's try to make weak bypassable authentication a smidge less
weak. Salted hashing is one way to prevent the DSA administrator from
becoming an adversary against other weak systems, such as the user's
gmail account.
Kemp
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Wilson
Actually, this is a solved problem. You use something based on an
asymmetric (public/private) key pair. The server holds (or obtains) the
public key and the client has the private key. That's what strong
authentication is about.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
