Forum OpenACS Development: Re: re: encrypting passwords in the database
Can you elaborate on when you need unencrypted passwords?
Are you trying to be a WebDAV client or a WebDAV server?
RFC 2617 says "Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified."
I don't understand.
Can you please elaborate on what you're trying to do and how you need cleartext password?
WebDAV server, with plugable backend providers (filesystem backend up and running, CR backend in progress, personal project so it's moving slowly).
re the section of RFC 2617 you've quoted, A1 is defined in the simplest (non-session authentication) case in 184.108.40.206 as
A1 = unq(username-value) ":" unq(realm-value) ":" passwdfor example
myusername:firstname.lastname@example.org:my passwordthe last paragraph of 220.127.116.11 says that this allows the webserver to retrieve H(A1) from some other authentication source - although the webserver process (AOLServer in our case) need never see the cleartext password, somebody on the server side needs to know it. So if you need to do Digest, but you don't want to trust your webserver to stay uncompromised, you could set up a (more trusted) auth server that the webserver contacts, saying "I have a request from bob in somerealm", the auth server looks up bob's password, calculates MD5("bob:somerealm:bobspassword") and passes the result back to the webserver.
Additionally, sect. 3.1.3 states
An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document.so I wouldn't assume many clients implement H as being anything other than MD5.
While we could overcome this particular problem by defining a single authentication realm and storing the Digest-specific H(A1) value as the OACS password, this value is unsalted (which removes some of the security of using hashed passwords) and doesn't enable any of the other cases where a server side cleartext password is nescessary.
The other case I personally have come up against is an application that was primarily built on OACS but also provided LAN users with Samba-accessible shares - to keep the samba passwords in sync with OACS required patching ad_change_password, whereas I believe if PG contained passwords in clear we could have authenticated directly against it (although we never explored this avenue in depth).
Then there's the bloke who was wanting to authenticate IMAP clients against an OACS user list a month or so back, who was eventually recommended to patch ad_change_password to save out the passwords so he could plug them into his IMAP software (sorry, can't find the thread).
We are touching authentication for 5.0 these days, so it is not unlikely that we could help you out here. But it's definitely not certain, either.