Forum OpenACS Development: re: encrypting passwords in the database
Some authentication methods require the server to know the user's cleartext password, and only supporting hashed passwords in the DB prevents us from making parts of an OACS-based application available where we would like.
The most web-related example (and the one that's annoying me at the moment) is WebDAV using Digest HTTP authentication instead of Basic. RFC 2518 states that a WebDAV server *MUST* support Digest authentication unless the transport is encrypted, and Digest requires that the server know the cleartext password. I also seem to recall someone posting recently about authenticating IMAP clients against an OACS user list, which required them to know the unhashed password.
There are some very good reasons why you might want to store unencrypted passwords, and it seems reasonable to me that we should have the option of doing so (with a full understanding of the security implications, of course)... Only supporting hashed passwords locks OACS out of being extended in some interesting directions, and forces anyone who wants to go in those directions to implement their own "save a cleartext password somewhere" scheme...
That used to be the case with ACS 3, but no longer is - I don't believe
there has ever been a supported option for storing cleartext passwords
in any ACS 4 release. I guess there could still be some residual
support lying around, but I haven't seen it - ad_check_password and
ad_change_password from a 4.6.2 tree can certainly only deal with
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 126.96.36.199 as
A1 = unq(username-value) ":" unq(realm-value) ":" passwdfor example
myusername:email@example.com:my passwordthe last paragraph of 188.8.131.52 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.