Forum OpenACS Q&A: Interesting article on web based password protection

http://securityfocus.com/infocus/1688

It has a list of do's and don'ts. I think OpenACS is doing fairly well, but there are a few schemes that we might eventually want to adopt, such as guarding against brute force attacks.

Of course, this will only be put in the toolkit when someone finds the time to do so. But it's good background knowledge. :)

Collapse
Posted by Don Baccus on
I find this interesting:
Consider this example: a hacker breaks into someone's computer and has full access to the victim's PC. The hacker sees that the user has an online banking account. So he logs in to the banking site, clicks on the "Forgot My Password" link and waits for an e-mail. As soon as the mail containing the password comes in, he deletes the mail and logs in to the site. The user never knows that the password was compromised.

The best way to deal with lost passwords is to reset the password and e-mail the user a secure link back to your Web site. In the e-mail you should clearly state that a password reset was initiated and from which IP address it was initiated. Once they click on the link and have connected back to your Web site, they can select a new password for their account.

Now if the hacker in paragraph one has broken into someone's computer and has full access to the victim's PC, why is the scheme proposed in paragraph two any more secure? The hacker will just chase the link, select a new password, then delete the e-mail. The victim will eventually try to log in and realize they can't, but by then the bank account is presumably empty.

I think it's also clear that if the hacker has full access to the victim's PC there's no security available anyway.

Jade, IIRC, someone demonstated a similar situation in the aD forums once. I do not remember the name but do remember that I asked him to send me the code that accomplished that. I'll check in my backup CDs when I'm back. Could you remind me to post here if I forget?
Don, you're right, effectively there is no difference between the two schemes. A more secure approach would be to go with the second scheme, but ask a security question, and only when answered correctly will it reset the password, or allow them to change it.

I don't believe that there is a one-size-fits-all security scheme for web sites/applications. For someone's personal site, they probably won't care too much if users on their site are compromised. Even small commercial sites or small organizations may not care. They just don't need to be secured like Fort Knox. So, for those who need it, they should be able to choose extra security measures, and for those who don't, they can live with a simple default.

So how about security system that is configurable by the admin? Let the admin decide if they will allow passwords to be emailed (and if they do, whether it emails the existing password or a new, randomly generated one), or if it will email a link to reset user's password (also need to decide whether or not to let the user know what email address it was sent to), and then what it does when they click that link (reset the password, ask a question, etc.). Heck, they could even go so far as to require the user to answer a question, and once answered, it sends an email with a link to the user's email address, which they must click on it order to get to a page to reset their password, and the page won't come up unless the request is from the same originating IP address as the first part of the process.

Personally, I like the way that OpenACS handles this problem already, but having a choice is nice.

Collapse
Posted by Don Baccus on
Well OpenACS allows a certain amount of customization, i.e. you can tell it to demand e-mail verification, some simple stuff like that which hopefully works :)

It would probably be nice to be able to set a minimum password length, require at least one non-alphanum character, etc as an *option* but as you point out, many websites don't contain the treasures of Fort Knox and people don't necessarily want the system to nag them about good passwords etc.

The brute-force attack (which is also a potential DOS attack) is something we've ignored even though we're not really ignorant of it.  It wouldn't be hard and not to difficult to add some configuration parameters allowing one to lock an account after N consecutive bad password attempts, or to lock an IP after N consecutive attempts to log in, etc.

For something as general as OpenACS, though, these all need to be configurable, not set in stone.

Collapse
Posted by Dave Hwang on
IIRC, someone demonstated a similar situation in the aD forums once. I do not remember the name but do remember that I asked him to send me the code that accomplished that.

I think that issue was related to the caching of session keys and using the "back" button after someone logged out of the site to get back in as that user, which has since been resolved with the login pages. At least, that's the issue that I can recall.

I happened to use some web sites that enforce some of the more cumbersome password protection schemes (password history, password expiration, minimum length + uppercase + non-alphanumeric). All I can say is that it gets really annoying, and just forces you to make your password vunerable in another way (e.g. password retreival/reset mechanism).

Personally, I've found that I'm always using the "forgot my password" link and getting a new temporary password for sites like that. Then when I log and try to set one, it says I've already used those 10 different passwords this year so can I please make up another one, which I'll promptly forget, so that I can avoid the security risk of writing it on a post-it on my monitor, and just use the "forgot my password" link the next time I need to log in again.

In practice, I think the best way to do it is the following, which I think is what we have in OpenACS:

  • If you forgot a password, you need to get answer a challenge question.
  • If you provide the correct answer, your new randomly-generated password will be sent to your email address.
  • After you log in, you can either keep your new, hard to remember, randomly generated password or you can change it back to something you are likely to remember.

The challenge question/answer is nice because it prevents a new password from being sent to a compromised email address. Another nice thing about the challenge answer is that usually, you can make it free-form into a standard (for you) pass-phrase, hard to crack but easy to for me to remember. Personally, I never provide the answer to the question that is asked (and whose answer could be easily-determined, such as mother's maiden name or favorite color).

One other thing that could be incorporated to cut down on brute-force attacks would be automatically diabling the account after the nth failure and asking them to send email to the admin for help. Also, password change should always ask for your current password, to prevent people from taking advantage of a compromised machine with the login cookie already set, which OpenACS already does as well.

Collapse
Posted by Lars Pind on
<blockquote>>
</blockquote>
Also, password change should always ask for your current password, to prevent people from taking advantage of a compromised machine with the login cookie already set, which OpenACS already does as well.
<<

Actually, if you're a site-wide admin, you can change yours (and others') passwords without being asked for the current password. I think that's a major flaw, since site-wide admins are the accounts you'd want to protect the most, not the least!

Of course, the reason is that you currently as site-wide admin is able to create new accounts and make others site-wide admins, so if you have access as site-wide admin, you can just create a new account for yourself and grant that site-wide privileges ...

I'm not sure what the right solution to this is.

/Lars

Collapse
Posted by Dave Hwang on
Site-wide admin is like getting administrator privileges on a windows box; so clearly, for security, we need to move more toward the unix way of doing things. Therefore, obviously, the Right Thing do to would be... ad_sudo?!?!
Collapse
Posted by Joel Aufrecht on
This is a classic security vs usability problem. (Note that many apparent security vs usability problems are false tradeoffs; it's very easy to make something less usable without gaining security.)

The problem with challenge/response is an astoundingly low success rate for "normal users." Users generally can't make heads or tails of the challenge-response process, for several reasons I won't go in to. I want to share the following semi-informed opinions:

For most public web sites, where getting broad participation is critical and neither data theft nor impersonation is critical, challenge-response isn't worth it. It provides a modicum of security and causes many possible users either to give up or to ultimately need human intervention to recover a password (again, a point at which many instead silently give up.).

Without rigorous ssl and a configuration making it impossible to submit a password in the clear, challenge/response is almost worthless because everything can just be sniffed.

The modal activity after a random password reset is, I would wager money, to use the new password once and then forget or lose it. Better to just re-send the original password in most cases.

So I guess I'm lobbying for two basic modes - minimal security, where you log in in the clear and can get your password back with a click, and real, where you log in over ssl, your proposed password is vetted against a dictionary, passwords expire, etc. One of these days I'll submit a patch for a new admin setting that cleanly disables challenge-response and hides every vestige of it.

Collapse
Posted by Samuel Klein on
<<<

Actually, if you're a site-wide admin, you can change yours (and others') passwords without being asked for the current password. I think that's a major flaw, since site-wide admins are the accounts you'd want to protect the most, not the least!

Of course, the reason is that you currently as site-wide admin is able to create new accounts and make others site-wide admins, so if you have access as site-wide admin, you can just create a new account for yourself and grant that site-wide privileges ...

<blockquote>>>
</blockquote>

The second paragraph is no excuse for the oversights of the first.  How much should one minute with an SWA account, without knowing the account password, allow someone compromise the system?  Should they be able to

  - create a new SWA account/passwd (which could be noted in reports as an unusual event)?
  - create a new SWA account which they could immediately log into and use [extending their time with such an account]?
  - alter their account password?
  - alter other SWA account passwords?
  - delete other accounts?  other SWA accounts?
  - alter the email address of their/other accounts, giving them access to those accounts after a password reset?
  ...

Any of the above actions could be somewhat restricted

  ++ by requiring SWA's to re-enter their password before carrying them out;
  ++ by sending a confirmation email to the SWA before such actions take effect;
  ++ by requiring direct file or db access (not allowing them from the web interface) for truly drastic measures
  ...

-Sam.

Our Project Portfolio Management site's customer's customer has a strong but not particularly clearly articulated security concerns.  Security is an interesting customer requirement because the levels of education on the subject are so variable.  A good white paper on what we have, how it compares to common web sites, how to use it, and why its good would probably be a smart marketing move.

Currently we have been asked to implement expiring passwords and there also seems to be interest in strong passwords.

Has anyone done this yet or planning to in the next month or so?  I'd be interested in putting together a coalition to work/fund these sorts of issues if there is interest.

Collapse
Posted by Lars Pind on
I'm touching on some of these things in our external authentication spec, and I'm hoping that we'll have funds to do them. Will find out about that shortly.

http://www.collaboraid.biz/developer/ext-auth-spec

Funding is welcome :)

/Lars

Checking for strong passwords sounds good, but I never understood the attraction of expiring passwords.

Maybe I'm missing something, but let's see, the user thought up a good, hard to break password, and carefully memorized it, so he never had to write it down anywhere and risk compromising security. Now what do you do? A few months later, you make him do it all again - you punish the user for his diligence.

IMO, that path leads right back to passwords on post-its and passwords like "foobar123". If you're lucky, the clever user will subvert your (hopefully simple-minded) password expiry scheme and simply alternate back and forth between two good secure passwords that he remembers.

Collapse
Posted by Dave Bauer on
Strong passwords might not be the best solution. One statistic I heard at a recent security conference said 50% of 5 character passwords are breakable using the default settings on a password cracking program. Moving to 8 character, only 80% are crackable. So if you have 1000 accounts, only 200 will be compromised instead of 500.

So usability is also definitely a factor in security.

The sessions was by Peter Tippett of Trusecure. He said that having 5 layers of security, each 80% effective was easier to implement and pretty much the same effectiveness at one layer that is 100% effective. We all know that 100% security is impossible, so the point is we need to address security at several different points, and also explain to the clients how the multiple levels of security interact.

I'd like to continue this thread because some e-lane users are showing concerns because it's too easy to reset an user password, although is not a big security flaw.

It's been suggested to change the code to email a URL token to change the password, instead of just reseting the password. This way the user would get a token in the email but won't get the password reset.

This is just what http://bugzilla.mozilla.org/ does.

What do you think about this issue?
Has anyone implemented this way of reseting the password?

Regarding passphrases necessary to reset/recover password.

They are thus equivalent to a password. So, if they do not have the same strength as a password they are the weal link.

They are truly only useful whtn the passwork reset/recovery is accomplished out-of-band, as when calling in to a *human* at one's bank, and further providing some other self-identifying information. Preferrably, such systems would require a visual identification as well.

As long as the word can be used to reset the password, the password is thus compromised.

I would not like to see any coding effort in that direction for the general OACS auth scheme. Such is the proper province of those as have on-line/in-person customer service reps.

Regarding quality of password.

I a system we have (whose redesign requirements brought us to OACS in the first place) that has authentication and privacy needs, we are currently assigning a random 8 digit password. We find that initially folks recoil at having to use such. When, in practice, they install the password once in their mailer, and once in their browser, they are happy. 1) They realize they are possessed of a hard to guess password, and 2) it is secured in their PC, and as long as their physicel security is OK, their on-line security with us will be as well.

That is really all that is needed in the vast majority of cases. I'm unaware of any place where a break in physical security wouldn't completely eliminate the need to perform any on-line hacking. I can imagine such. I know such must exist. I doubt OpenACS is considered for such places.

Cheers!