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:

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."

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

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.

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

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.

"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. Don't use salted hashes to store passwords. They are inadequate.

On Jun 9, 2011, at 1:39 PM, James Manico wrote:

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."

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?

"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.

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.

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.

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.

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.

Hello guys.  I need a slight help from you guys in my project in coding using C++. Im trying to figure out wads wrong with the code and im left with one error. Can you guys look at it for me please. The code is as per attached. Its a console application for C++.Date: Sun, 12 Jun 2011 04:45:16 +0100
From: jim@manico.net
To: thomas@matasano.com
CC: rmc_0306@hotmail.com; security-basics@securityfocus.com; itsecanalyst@gmail.com; websecurity@webappsec.org
Subject: Re: [WEB SECURITY] FW: Password Manager with Fingerprint Verification

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?

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.

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.

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.

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.

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@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@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@gmail.com

                                  To: rmc_0306@hotmail.com

                                  CC: security-basics@securityfocus.com; websecurity@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@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.
                                      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.
                                      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@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@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."