[WEB SECURITY] Password Recovery

Mike Shema mshema at ntobjectives.com
Thu Jun 16 17:39:18 EDT 2005


Password recovery, brute force, and sniffing are different challenges  
and need different (probably overlapping) "best practices". The  
WASC:TC recommendation on password recovery speaks to brute force and  
circumvention of the recovery technique, but it doesn't address  
sniffing (that's in another section).

Just because password recovery uses e-mail doesn't mean the mechanism  
is inherently insecure. Consider two scenarios:
  - The application e-mails the plaintext password. This means the  
application doesn't store hashed passwords. I would feel more  
comfortable if the application stored the hash of my password so that  
at least _some_ effort would be required to brute force it if the DB  
table were compromised. I would count that as a system weakness  
without even thinking about sniffing yet.
  - The application e-mails a random, one-time password or a "reset"  
URL that prompts the user to immediately update the password after  
authentication. The original password is not exposed. This is better,  
and a follow-up e-mail that indicates a password change occurred  
would be a good closure. If an attacker used a sniffed reset to  
update the victim's password, the victim would at least be notified  
that the account's password has changed. Of course, you have to send  
the notification e-mail before the attacker changes the e-mail  
address on file ;)

Both of these scenarios are vulnerable to sniffing, but then so would  
actual use of the original web application (except perhaps the SSL  
portions). The reliance on e-mail simply means the application is  
using a channel whose security it cannot control. This is a risk- 
acceptance problem for the application owner.

The circumvention issue is when an e-mail password recovery mechanism  
does something like permit the user to choose the recipient's e-mail  
address. This would be a terrible system weakness. It should probably  
not even divulge the recipient, but respond with an "e-mail address  
on file" message.

A mechanism not based on e-mail, like a question/answer pair, needs  
the same anti-brute force measures as the login prompt and should  
follow those best practices. Passwords, pass-phrases, and secret  
questions are designed to be resistant to brute force guessing  
attacks. They are equally susceptible to sniffing or replay attacks.  
As Mark Burnett's article points out, secret questions may even be  
the most susceptible to brute force. It may be easier for the  
attacker to reset the victim's password rather than guess the  
original one.

-Mike



On Jun 16, 2005, at 10:58 AM, Jeremiah Grossman wrote:

>
> On Thursday, June 16, 2005, at 10:50  AM, prateek mishra wrote:
>
>
>> 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?
>>
>
> "Best Practices", none that I have seen or read, but it would be  
> great if there were. Especially if it was geared specifically for  
> web application security.
>
>
>>  I didn't find any specific documents at webappsec or owasp that  
>> spoke to this problem.
>>
>
> Mark Burnett wrote the following column for OWASP
> Using Secret Questions
> http://www.owasp.org/columns/mburnett/questions.html
>
>
>
> Jeremiah-
>
> ---------------------------------------------------------------------
> 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/



More information about the websecurity mailing list