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

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.

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.

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.

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?!?!

<<<

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.

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

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.

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!