[WEB SECURITY] Password Recovery

prateek mishra pmishra at principalidentity.com
Thu Jun 16 13:50:22 EDT 2005


I wonder if there are any good guidelines in this space. Has NIST or any other group issued a set of "best practices" for password management and recovery? 
 
I didn't find any specific documents at webappsec or owasp that spoke to this problem. The "Web Application Security Consortium: Threat Classification" just says the following:
 
[quote]
 A web site is considered to have Weak Password Recovery
Validation when an attacker is able to foil the recovery mechanism
being used. This happens when the information required to validate a
user’s identity for recovery is either easily guessed or can be
circumvented. Password recovery systems may be compromised
through the use of brute force attacks, inherent system weaknesses,
or easily guessed secret questions.
[\quote]
 
Some negative cases are also provided in the document but no positive guidelines for implementation. 
 
First, all non-trivial relationships could include additional regular communication of somewhat random information. For example, phone bills and bank statements could include a nonce at every billing cyle. Could this not be used instead of a "secret" in password recovery? In other words, instead of the "answer" the user is required to input this nonce and the billing document number/cycle when it was received.
 
There also needs to be some constraint on how the "new" password is communicated to the user. It should be only done so over a reasonably secure channel (e.g., landline or cell phone) for which there is some kind of public record. 
 
The proliferation of passwords is a separate issue; if users had a few robust authentication credentials, identity federation could be used to solve this problem. But users typically dont have a few robust authentication credentials (this discussion is partly about that :-), so its a little early to move in that direction...
 
- prateek mishra
 
CTO,
Principal identity

Al <gr at ziano.fsnet.co.uk> wrote:
> I recently wrote a security system that didn't use username/passwords at
> all
> for authentication. I relied entirely on allowing the user to provide
> their
> own memorable secret question, and their own memorable answer.

Isn't that a little bit risky? Do common users really know what makes a good
security question? I personally thing there is also a usability issue there.
First, it is easy to make typing mistakes when you input a long sentence,
and even easier when the characters that you type are ***ed. People would be
then inclined to start typing much more slowly, which in turn could help
shoulder surfing (maybe I am paranoid..). Also, remembering one long
sentence for getting access to one system is fine and quite easy. How about
when you have to access multiple systems every day, which most of us do. How
would you remember which "memorable" sentence you're supposed to use for
each system?

My guess is that people would start writing down those memorable sentences
on a list somewhere that they keep safe from prying eyes. But once you get
to that point, I believe you've lost the convenience. Unless you'd like to
go down the route of using just the one "sentence" for everything..

The argument for using memorable sentences IMHO is that they are in
principles much more difficult to guess/crack. However it still all depends
on how you use them, which I believe then only shifts the problem but does
not solve it. 

Ciao

Al

> -----Original Message-----
> From: dpw [mailto:dainw at fsr.com]
> Sent: 16 June 2005 16:32
> To: websecurity at webappsec.org
> Subject: RE: [WEB SECURITY] Password Recovery
> 
> Back to the original issue... IMHO, people have to carry around too many
> passwords which necessitates them adopting some sort of "throwaway"
> password, which leads to them forgetting the password two weeks later.
> 
> I recently wrote a security system that didn't use username/passwords at
> all
> for authentication. I relied entirely on allowing the user to provide
> their
> own memorable secret question, and their own memorable answer.
> 
> Why would I go against Bruce Schneier on this? Well, besides the fact that
> I
> intriniscally "don't know better", I felt that it is easier for a person
> to
> remember a lengthy "normal language" sentence than it is to remember a
> short
> "gobbledegook" password string.
> 
> I realized that the "throwaway" password string people normally use is not
> secure at all from a brute force standpoint, and even if a 10 word
> sentence
> is all "normal language", it's immeasurably harder to brute force. To beef
> up the system even further, I only allow them 3 tries to type in their
> answer before I lock them out by IP, session & cookie.
> 
> But I digress - the point is, my users are using incredibly long, easy to
> remember "passwords", happily, and they're not forgetting them. In fact, I
> hear a lot about how much they like the system, and wish other sites did
> this. Of course, when I read what Bruce had to say about this, I was a
> little dismayed.... and who wouldn't be?
> 
> Dain White
> Senior Developer - Webmaster
> First Step Internet, L.L.C.
> www.fsr.com | www.fsr.net
> 
> 
> 
> 
> -----Original Message-----
> From: Ofer Maor [mailto:ofer.hacktics at gmail.com]
> Sent: Wednesday, June 15, 2005 4:20 PM
> To: websecurity at webappsec.org
> Subject: RE: [WEB SECURITY] Password Recovery
> 
> 
> I have to say I agree with Bruce here.
> 
> The secret questions as a password recovery mean are pretty lame. With
> many
> of the questions being too trivial or have too trivial answers, I have had
> success many times while perfroming pentests in breaking into the
> application throuhg the password recover scheme.
> 
> With that said, we still need to see what we do about password recovery.
> Personally, I believe that in highly sensitive applications (such as
> online
> banking/insurance/etc.) - password recovery should be left for phone based
> customer support. For others, there are some reasonably more secure
> mechanisms, mainly such that rely both on a secret question, as well as
> email verification of the user.
> 
> Basically - a user wants to recover his password, the user is instructed
> to
> enter the username AND the email address. If the email address matches the
> username, and email is sent to the user, with a link to the secret
> question
> page. Only then, after the user has been verified once through the email,
> the user gets the chance to enter the answer to the secret question. Now,
> this is not a completely safe solution (emails can be sniffed, etc.), but
> I
> think it's a few degrees tougher to break than just working on the secret
> question and having your password reset.
> 
> Ofer.
> 
> 
> ---
> Ofer Maor
> CTO
> Hacktics (http://www.hacktics.com/)
> 
> 
> -----Original Message-----
> From: Dave King [mailto:davefd at davewking.com]
> Sent: Wednesday, June 15, 2005 23:31
> To: websecurity at webappsec.org
> Subject: [WEB SECURITY] Password Recovery
> 
> 
> Hi All-
> I was wondering what everyone's opinion is on good password recovery
> options for a web application. In OWASP's penetration testing document
> it says "Ensure that the user must respond to a secret answer or secret
> question or other predetermined information before passwords can be
> reset." However Bruce Schneier and others disagree, check out this blog
> post http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html
> . Basically he says these secret questions drastically lessen security
> because it's easier to guess the answer to the secret question than it
> is to guess the password. Does anyone have any opinion on this or have
> found another solution that works well?
> 
> Thanks,
> Dave King
> 
> 
> ---------------------------------------------------------------------
> The Web Security Mailing List http://www.webappsec.org/lists/websecurity/
> 
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/
> 
> 
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
> 
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/
> 
> 
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
> 
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/



---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20050616/cdd1899c/attachment.html>


More information about the websecurity mailing list