[WEB SECURITY] FW: Password Manager with Fingerprint Verification

Jim Manico jim at manico.net
Sat Jun 11 23:45:16 EDT 2011


> I don't understand what "static bcrypt" is.

No problem Thomas, I'm here to help. I was referring to using bcrypt
without setting a strong work factor or using bcrypt without increasing
the work factor over time. As hardware and cloud hash cracking
capabilities increase over time, the effectiveness of bcrypt's default
work factor decreases. So it's prudent to increase your work factor over
time.  Like your referenced article says, as of Feb 2011, for about
$300/hour, you could crack around 500,000,000,000 candidate passwords a
second. Where are we going to be in 10 years?

> The default work factor for bcrypt (in most libraries, this number is
"10") is so much more effective than any other password hashing strategy
that it is unnecessary to recommend an alternative.

I politely disagree. "Most Libraries" makes me nervous. You need to
increase the work factor over time to account for the rapid increase in
hardware and cloud capabilities. I also thinks it prudent to suggest an
explicit initial work factor (even if that number is 10 and is
frequently the default work factor), and that recommendation should
change over time. The article you referred to below failed to mention
either of these recommendations. Relying strictly on computability time
is a temporary solution at best.

> Dialing up the work factor imposes application costs. bcrypt with a
work factor of 12 is probably too slow for any popular web application.
Again: this cost/benefit tradeoff is the point of bcrypt, not a
liability. But it's also a reason why you don't bother telling people to
noodle around changing their cost factors.

The whole point of a good password storage strategy is to slow down the
process of verification. "work factor 10" processing time is dependent
on hardware. It might be great today, but may not be in 10 years.

> Every article about bcrypt makes a point of saying the work factor is
tunable. That is, after all, the point of bcrypt.

So, you are saying that we should not change the work factor, but it is
tunable? I'm confused at the point you are trying to make.

> "Secret salt" schemes are flawed, universally. If you are depending on
a bare cryptographic hash with a "salt" for your security, without a
vetted iterating/stretching construct, you are in fact introducing
vulnerabilities into your applications. We would tend to document any
such schemes as vulnerabilities in assessments; that's how clear this
issue is.

I'm sure we can all agree that per-user salting IS critical to avoid
users with the same passwords having the same hash. This is why bcrypt
salts under the hood and stores it with the hash by default. The issue
we are debating is the power of salt isolation. I prefer to store the
hash in the database but put the salt on the file system. For example,
suppose an inside attacker gets his paws on your database backup where
all your sensitive data is encrypted and the passwords are hashed  (but
the attacker does not have access to the live server file system).  The
solution with salt isolation would be stronger in this situation.

> Don't use salted hashes to store passwords. They are inadequate.

I agree. You need to use a salted hash AND iterate that hash thousands
of times. And you need to increase that hash iteration count over time.

So if you you are going to go the bcrypt route, make sure you have a
solid and well-vetted implementation[1]. You may also want to suggest a
work factor of 10 today and increase it by 1 every 10 years. You should
also rip the salt from the computed bcrypt hash and isolate it.

So if you are going to go the PBKDF2-like route, a minimum of 1000 hash
iterations is recommended in RSA PKCS5 standard (which is used under the
hood of PBKDF2).  I recommend 1000 sha-2 iterations as of y2k and double
that every 2 years[2].

For bonus points, re-hash the password each time the users logs in and
generate a new salt for either bcrypt or PBKDF2 schemes.

And if you are only depending on a password as a sole credential,
probably a bad idea. The era of passwords is dead! In a 2 factor authN
system, your password policy and your storage mechanism can be a lot
weaker without reducing risk. Time to move to 2-factor solutions like
those powerful and potent RSA tokens. *wink*

- Jim

[1] Nail in the coffin regarding using bcrypt for hashing (for some
shops) is that blowfish is banned by most business encryption standards
as well as FIPS-140.

[2]  I'm starting to think that the time horizon also needs to change
over time for setting a new hash iteration count for PBKDF2-like
schemes. Or even better, I'm experimenting with re-computing (and
increasing) the needed hash iteration count during run-time for the
brief moment in time that I have the password in memory during login and
can re-hash on the fly. This might add a few more lines of code to the
implementation but will slow down login attempts a little bit over time
- which is cool for security but is no-no for most shops. Depends on
your biz requirements and risk tolerance.

>
> On Jun 9, 2011, at 1:39 PM, James Manico wrote:
>
>> Using bcrypt in a static way is a poor idea. You must also increase
>> the work factor over time. The article below fails to recommend a
>> specific work factor nor does it suggest that the work factor needs
>> to increase over time.
>>
>> Bcrypt is a good solution for password storage, don't get me wrong,
>> but it's not the only solution.
>>
>> Salting can also lower dictionary attack risks in some situations if
>> you isolate the salt from the hash.
>>
>> Respectfully,
>> Jim Manico
>>
>> On Jun 9, 2011, at 19:31, Thomas Ptacek <thomas at matasano.com
>> <mailto:thomas at matasano.com>> wrote:
>>
>>> You're right; they can only use bcrypt if they're on Rails, Python,
>>> PHP, Perl, .NET, Java, C/C++, or Erlang.
>>>
>>> Iterating SHA256 correctly is a little trickier than just repeatedly
>>> rehashing (see: RFC2898 for PBKDF2), but does work.
>>>
>>> In working with and talking to over a hundred startup web
>>> developers, I've learned that when you leave password hashing open
>>> to implementation (for instance, by rolling your own "stretched"
>>> SHA256), you end up with people who use secret salts. It's better
>>> --- it's just better --- to use bcrypt. 
>>>
>>> On Jun 9, 2011, at 1:27 PM, James Manico wrote:
>>>
>>>> Not everyone had access to bcrypt. Iterating the hash thousands of
>>>> times mitigates the concern in the paper below. This hash iteration
>>>> count is basically the same thing as bcrypts work factor and just
>>>> like using bcrypt this work factor will need to be increased over time.
>>>>
>>>> Hash iteration count was recommended to be 1000 in the year 2000
>>>> and should be doubled every three years to be in line with bcrypts
>>>> work factor recommendations.
>>>>
>>>> Cheers from AppSecEU in Dublin.
>>>>
>>>> Jim Manico
>>>>
>>>> On Jun 9, 2011, at 17:12, Thomas Ptacek <thomas at matasano.com
>>>> <mailto:thomas at matasano.com>> wrote:
>>>>
>>>>> http://codahale.com/how-to-safely-store-a-password/
>>>>>
>>>>> Just read this article and do exactly what it says.
>>>>>
>>>>> On Jun 8, 2011, at 6:34 PM, Vikneswaran Kunasegaran wrote:
>>>>>
>>>>>> Hi Gautham..
>>>>>>  
>>>>>> So in your email below are you stating that without encryption,
>>>>>> salting and hashing alone would be secured and difficult to crack
>>>>>> by unauthorised people? I was just thinking too much on how to
>>>>>> make my databse secure maybe thats why I got into this. Sorry
>>>>>> though hehe. So, in your opinion, what would be your advise if I
>>>>>> wanted to salt this password for a 1000 times and then hash it as
>>>>>> this was a comment from another person who replied my email. Is
>>>>>> it okay or the suggestion you made is secured enough. Kindly
>>>>>> awaiting your reply on this. And thank you very much for replying
>>>>>> me Mr Gautham. Really appreciate it. 
>>>>>>  
>>>>>> Have a nice day. 
>>>>>>  
>>>>>> ------------------------------------------------------------------------
>>>>>> Date: Tue, 7 Jun 2011 16:15:30 -0700
>>>>>> Subject: Re: Password Manager with Fingerprint Verification
>>>>>> From: itsecanalyst at gmail.com <mailto:itsecanalyst at gmail.com>
>>>>>> To: rmc_0306 at hotmail.com <mailto:rmc_0306 at hotmail.com>
>>>>>> CC: security-basics at securityfocus.com
>>>>>> <mailto:security-basics at securityfocus.com>; websecurity at webappsec.org
>>>>>> <mailto:websecurity at webappsec.org>
>>>>>>
>>>>>> I am still trying to get my understanding clear here. why would
>>>>>> you want to (salted+hash) and then encrypt it. Is just getting a
>>>>>> hash not enough, you can do salted+sha256 and you should be good.
>>>>>>
>>>>>> if you want a clear text password, then you might want to encrypt
>>>>>> it, however it all depends what is the final use of these
>>>>>> credentials. There are more controls that you would need to get
>>>>>> in place if you want to encrypt-decrypt and then key management
>>>>>> is a big issue that you need to think.
>>>>>>
>>>>>> G
>>>>>>
>>>>>> On Tue, May 31, 2011 at 6:01 PM, <rmc_0306 at hotmail.com
>>>>>> <mailto:rmc_0306 at hotmail.com>> wrote:
>>>>>>
>>>>>>     Hello Friends.
>>>>>>
>>>>>>     Im a final year student for COmputer Security / Forensic. Im
>>>>>>     planning to do a project which requires me to do encryption
>>>>>>     and decryption. My possible choice of language would
>>>>>>     be VB.Net <http://VB.Net/>. I was wondering if wad is running
>>>>>>     in my mind can be executed. Well, I would make a application
>>>>>>     where a part of it wil be promting the guest to register and
>>>>>>     I wanted to store the password in the database. I did some
>>>>>>     research and came across Salting and Hashing. I was wondering
>>>>>>     if is it possible to get the password which the user enters,
>>>>>>     salt it, hash it and encrypt it before I store in the
>>>>>>     database. If so, what is the best secured strong encryption
>>>>>>     can I use in VB.net <http://VB.net/>. Because through out the
>>>>>>     research I have done, i have sen RInjdael as the most fav
>>>>>>     encryption algo which alot of programmers using. JUst a
>>>>>>     though on this. Kindly advise me. Thank you for your generous
>>>>>>     help and for reading query.
>>>>>>
>>>>>>     ------------------------------------------------------------------------
>>>>>>     Securing Apache Web Server with thawte Digital Certificate
>>>>>>     In this guide we examine the importance of Apache-SSL and who
>>>>>>     needs an SSL certificate.  We look at how SSL works, how it
>>>>>>     benefits your company and how your customers can tell if a
>>>>>>     site is secure. You will find out how to test, purchase,
>>>>>>     install and use a thawte Digital Certificate on your Apache
>>>>>>     web server. Throughout, best practices for set-up are
>>>>>>     highlighted to help you ensure efficient ongoing management
>>>>>>     of your encryption keys and digital certificates.
>>>>>>
>>>>>>     http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
>>>>>>     ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> The Web Security Mailing List
>>>>>>
>>>>>> WebSecurity RSS Feed
>>>>>> http://www.webappsec.org/rss/websecurity.rss
>>>>>>
>>>>>> Join WASC on
>>>>>> LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>>>>>
>>>>>> WASC on Twitter
>>>>>> http://twitter.com/wascupdates
>>>>>>
>>>>>> websecurity at lists.webappsec.org
>>>>>> <mailto:websecurity at lists.webappsec.org>
>>>>>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>>>>>
>>>>>
>>>>> ---
>>>>> Thomas Ptacek // matasano security // founder, product manager
>>>>> reach me direct: 888-677-0666 x7805
>>>>>
>>>>> "The truth will set you free. But not until it is finished with you."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> The Web Security Mailing List
>>>>>
>>>>> WebSecurity RSS Feed
>>>>> http://www.webappsec.org/rss/websecurity.rss
>>>>>
>>>>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>>>>
>>>>> WASC on Twitter
>>>>> http://twitter.com/wascupdates
>>>>>
>>>>> websecurity at lists.webappsec.org
>>>>> <mailto:websecurity at lists.webappsec.org>
>>>>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>>>
>>>
>>> ---
>>> Thomas Ptacek // matasano security // founder, product manager
>>> reach me direct: 888-677-0666 x7805
>>>
>>> "The truth will set you free. But not until it is finished with you."
>>>
>>>
>>>
>>>
>
>
> ---
> Thomas Ptacek // matasano security // founder, product manager
> reach me direct: 888-677-0666 x7805
>
> "The truth will set you free. But not until it is finished with you."
>
>
>
>

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


More information about the websecurity mailing list