Forum OpenACS Development: Can question/secret answer be removed from password recovery?
1) User tries to log in
2) user fails
3) user is offered a link to recover password
4) Depending on admin settings, user may be shown secret question (which isn't secret, as the user hasn't authenticated yet) and asked for secret answer. Or, user may be asked for first and last name.
5) If available, secret answer is checked. If not, user name is compared to email. If match fails, process stops.
6) User is emailed existing password. Or, depending on admin settings, user may be emailed a newly generated password.
7) (If Q/A admin flag on but user doesn't have Q/A) User is asked for question and answer for "future reference"
There is a second path. Some pages have a link, "I forgot my password."
1) User clicks link
2) User is asked for email
3) Continue with step 4 on first path.
Depending on settings, the user is now emailed either their password, or a link to a page where they are not logged in but do have the power to reset their password.
Drawbacks to this approach:
The logical paths are pretty tangled, making it harder to modify or debug.
Using name as a fallback if Q/A is required but not available is unobvious and insecure
Most of this security is of limited use because the transaction isn't encrypted
The ability to trigger a password reset without fully authenticating is a Denial-of-service vector.
I propose that we remove most of this functionality in favor of:
1) There is an "I forgot my password" link on the failure page after a login
2) If clicked, this causes the password to be emailed to the email on file for that username
3) If the acs-subsite.EmailForgottenPasswordP variable is false, 1 doesn't appear and 2 is disabled.
I believe this is more usable, almost as functional, equally secure, and simpler to maintain and modify.
So that's one advantage to resetting the password in that fashion, but it has to be weighed against the disadvantages Joel brought up above. The denial of service implications probably never occurred to whoever implemented the current password resetting scheme...
I don't think it makes sense to say, "Most of this security is of limited use because the transaction isn't encrypted". Whether or not the web page is encrypted in transit with SSL is entirely separate from whether the user has logged in yet or not. Remember that depending how the admin as things set up, the login page where the user sends his password may itself not use SSL! All OpenACS pages asking for passwords or secret phrases should follow the same setting, either they all require SSL or none of them do. Of course, making sure there's only one such page may be the simplest way to do that. :)
Whether or not the login page uses SSL is presumably a security choice by the site owner. It should use SSL, yes, but if you're running a site with unimportant user data but lots and lots of users, maybe you'll want to economize on server hardware by not supporting SSL even for the login page. Bad idea IMNSHO, but note that Yahoo and even Ebay both default to non-SSL logins, so insecure login pages seem to be fairly industry standard, if it means saving a few bucks on hardware costs.
All that said, I don't personally have any problem with removing the secret answer/question business, sounds fine to me. I wonder about existing sites out there using OpenACS though, maybe some of them have a requirement for this? I guess if it's taken out for OpenACS 5.0 rather than 4.6.x, and is mentioned in the Change Log for 5.0, that should be good enough. If anyone really really wants to keep a secret question/answer feature they can always forward port it from 4.6, as long as they know about the change.
> the email on file for that username
How will you recover the user's password? With the current scheme, I believe the password is hashed using ns_sha1 and irrecoverable. Which is why the system needs to reset the password when the user forgets it.
The only reason I can think of to retain the "question/secret answer" protocol is that it prevents a malicious person from resetting (and emailing) a known user's password on, say, an hourly basis. I have never heard of such a case, but it would be annoying to say the least. Also, it might give users the warm fuzzies since it appears to have become a standard across many sites.
I vote to retain it.
So for anyone genuinely worried about DOS attacks via the "I forgot my password, please reset it and email it to me" page: The existing "question/answer" method sounds like a good solution to that problem. Any change that simply goes back to storing un-encrypted passwords in the database is probably a very bad idea.
Note that if someone can extract a plain text password from your database, you have pretty much lost it, haven't you? I'm not saying that it should be done, but it isn't the same thing as a /etc/passwd file where every local user can read the file.
I can never remember the answer to a question I choose. Capitalization matters as well. Bottom line is that this is a difficult problem with no obvious 'easy' solution.
So, storing the password unencrypted is preferable if combined with the option to resend the current password to the user. We could make this an optional switch (resend_password vs. create_new_password).
As always there is a catch though: Users are a lazy bunch. They usually use the same password for a couple of websites. Storing the password encrypted prevents the maintainers of the site to access your password and try it out on other sites. Furthermore, sending your current password over the net via email makes it possible to obtain your login for other sites for the occasional password searching filter.
Maybe it is better to characterize the hashing as a hurdle. In track events, hurdles are added, not to prevent the runner from crossing the finish line, but to make it harder. Any security measure that makes it harder is good, IMHO. Storing the password as a hash greatly reduces the number of possible ways an attacker could get into an account. Human engineering is the best example, just call the customer service department and convince someone to give you the password.
Remember people make exports and backups of their database, leave these lying around on various computers, and often probably don't consider the security of that backup nearly as important as the security of their live system. So, an attacker may not have access to the live system at all. If your passwords are stored in the clear, he may have just read all of them from an export of your 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 188.8.131.52 as
A1 = unq(username-value) ":" unq(realm-value) ":" passwdfor example
myusername:email@example.com:my passwordthe last paragraph of 184.108.40.206 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.
Just a few comments for consideration.
Firstly, there was a brief chat on IRC the other day about ways to reduce the possibility of a DoS attack (http://openacs.org/irc/log/2005-06-16 time window 20:50 until 21:17). There were some good suggestions - worth looking at.
Secondly, my bank uses a good system for entering passwords which is that it never asks for the whole password, just a selection of letters from it. This defeats packet sniffers (unless they wait for an awful lot of logins!), and ensures that the password remains secure(ish) even on unencrypted connections.
Thirdly, I'd like to refer you to my suggestion of an increasing timer delay after say 15 login attempts in quick succession. We could extend this to cover the re-issue password request such that if 're-issue my password' is requested more than say 20 times in say 10 seconds (or any other time considered appropriate), the system identifies this as a potential attack and introduces a timed delay to the page. I suggested that we could modify the developer support log sweep to include a multiple login detection check.
I would support any means of streamlining the process, but I would be wary of stripping stuff out without very careful discussion because there will probably be a 'Doh!' factor associated with doing that. "Oh yes! THAT'S why they did it like that!!!"
Personally I quite like the question and answer thing for re-issuing passwords (because it is convenient) but I do think that we should block the DoS vulberability that it could represent. I also think that we should preserve the behaviour where the email that goes out has a magic url that takes the user immediately to a login and forces them to change their password to one that has not just crossed the ether unencrypted!
I hope these comments are helpful.