[Owasp-leaders] Another take on Passwords

Marco M. Morana marco.m.morana at gmail.com
Sat Jan 24 08:27:07 EST 2009

Another take on PasswordsIn the case of financial web applications, the best shared secret questions are the ones that require specific shared knowledge between the user and the authenticator such as shared knowledge of events (e.g. the last time you make a payment) or specific knowledge of data (e.g. the exact amount of customer's monthly mortgage payment).
To improve entropy of the shared secret, you can prompt the user to answer different shared secrets by randomly choosing them from a previously set of pre-registered answer/questions.

OWASP Chapter Lead

Writing Secure Software Blogger


  ----- Original Message ----- 
  From: McGovern, James F (HTSC, IT) 
  To: owasp-leaders at lists.owasp.org 
  Sent: Friday, January 23, 2009 4:37 PM
  Subject: Re: [Owasp-leaders] Another take on Passwords

  Yes, Sarah Palin used easy questions as that is how Republican's think. Seriously, I think folks need guidance on how to ask proper questions. For example, asking what is your birthdate is a bad question where asking a user to choose a date that is memorable to them may be better. We need to talk more about entropy in this regard as well. For example, if you were to ask every Architect I work with, the name of the architect who is most painful, my name would dominate the reset tables :-)

  Other guidance may center around just semantic issues for example, did I type: New York City, NYC, Manhattan, etc

  From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Jim Manico
  Sent: Friday, January 23, 2009 4:00 AM
  To: owasp-leaders at lists.owasp.org; owasp-leaders at lists.owasp.org
  Subject: Re: [Owasp-leaders] Another take on Passwords

  > Should OWASP have some "project" that is a UI component that will allow a user to tell the strength of chosen password (I think Yahoo does something similar but could be better)

  Sounds cool. Most JavaScript libraries have a component of this nature available to some degree, but it would be cool for OWASP to verify the policy they use, as well as build our own. We can't really just build one JS comonent and have that work for everyone - the JavaScript component world is fractured into JQuery, Google's lib, MS's lib, Yahoo's lib, and others. Perhaps we could just offer a little OWASP JavaScript function that does a simple configurable password policy check?!
  >  I would argue that weak passwords is less of a problem that weak password reset routines. 

  I agree, but only in the case where the application is using some kind of account lockout policy in order to stop brute force attacks. Weak passwords are very easy to brute force. And brute forcing is easy. :)

  > Think about how easy it was for some Yahoo's to jack Sarah Palin's email. There is no sound guidance on developing reset mechanisms of any credibility. FYI. This is what I am noodling today as part of my day job

  Now, the Palin hack only happened becuase of 2 factors

  (1) She used easy questions and

  (2) She did not have her account attached to a secondary email address 

  If either of these things were not true, I suspect her account would never had been compromised. Plus, she was using a webmail account to do official state business? That's stupid (and possibly illegal).

  But I do agree with your conjecture that password administration features can be critial show-stopping problems! 

  > Why are we still using passwords to protect web applications. How come the OWASP crowd isn't backing federated identity, Cardspace, etc?

  These solutions are so expensive to roll out! The complexity and cost of client-side key management is not something small business websites can afford. Especially if you are consumer facing. But I agree we should be pushing it in the enterprise space. Heck, paypal offers a keyfob.....

  Yea, you are right, James. The era of the password is really over. OWASP really should be pushing multi-factor auth.

- Manico************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.


  OWASP-Leaders mailing list
  OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20090124/56dbdbaf/attachment.html 

More information about the OWASP-Leaders mailing list