Supporting One-way Encryption of Passwords

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

Hi,

In Movable Type we have a problem in that we don't store user passwords 
in the clear, but only one-way encrypted using old-skool UNIX "crypt." 
(We do this because MT often runs in an untrusted, generic hosting 
environment). This means that in the Atom API, we can't verify the 
PasswordDigest if it was generated using the user's real password, and 
of course the client can't create the crypted version because it 
doesn't know the salt. As I understand it, this issue was brought up on 
the list at one point, and it was thought that the best solution would 
be simply to ask the user to enter the encrypted password instead.

User experience and security would be vastly better if we could allow 
the user to enter her familiar password. Since we're using a standard 
encryption method (crypt) which clients may be able to implement, and 
which other Atom servers might wish to use, I hope we can do better 
than ask the user to use the crypted password.

All we need is a way to deliver the salt to the client for use in 
crypt'ing. This might not be something every client would do, but 
clients and servers that supported this could offer a good combination 
of user experience and security.

I'm not sure what is the most spec-friendly way to do this, but I have 
a few suggestions:

  1) Simply add additional parameter to WWW-Authenticate header under 
WSSE UsernameToken profile (not sure if this is legal):

    WWW-Authenticate: WSSE profile="UsernameToken" salt="xx"

  2) Add new profile, UsernameTokenCrypt, with additional parameter 
salt="xx" (I favor this one):

    WWW-Authenticate: WSSE profile="UsernameToken+crypt" salt="xx"

(This is attractive because a server could provide the usual 
UsernameToken profile as a fallback option, if it was OK with that; 
then clients unable to do 'crypt' would have a fallback.)

  3) Add new header, X-WSSEUsernameTokenSalt:

    WWW-Authenticate: WSSE profile="UsernameToken"
    X-WSSEUsernameTokenSalt: xx

A server may want to use some other preprocessing step, such as MD5ing 
the password concatenated with a challenge. The above methods could 
extend easily to cover each such case, with an appropriate bit of spec 
language or an attached profile.

Any ideas about this? Anyone dislike it? If not, I can try to draft 
some specification text.

Thanks,
Ezra