title: Passwords storage, hash() with sha-512 or crypt() with blowfish (bcrypt)?
body: <p>This is my current password hashing procedure in PHP/SQL projects...</p>
  
  <ul>
  <li>Take 512bits of per-user salt from /dev/urandom, stored in the user's DB record in addition to the final hash</li>
  <li>Take 512bits of "pepper" from /dev/urandom which is stored in the file system. This is a
  constant per-application and is the same for each user</li>
  <li>Then <code>hash('sha512', $password.$salt.$pepper, TRUE)</code></li>
  </ul>
  
  <p>The hash and salt are stored in binary in the DB, mainly out of habit. I don't think it makes any difference in terms of security. If anything it's slightly less convenient for SQL backups and makes the PHP code <em>appear</em> marginally more complex.</p>
  
  <p>Is <code>hash()</code> with SHA-256 or SHA-512 generally considered to have been superceeded by bcrypt these days?<br>
  I believe SHA-2 (256/512) is still considered cryptographically secure and I'm probably overdoing the entropy bits. It's far more likely that it would be a flaw in my code that would lead to problems than an attacker reverse-engineering a SHA-2 hash from a DB dump.</p>
  
  <p>But should I update my methodology going forward to use <code>crypt()</code> with CRYPT_BLOWFISH instead (I believe this is referred to as bcrypt, with blowfish technically being a cipher rather than hashing algorithm)?<br>
  Even just as future best practice?</p>
  
  <p>I'm not particularly concerned about the computational expense of the algorithms (within reason). This would only ever be a factor when creating accounts, changing passwords or on login when you hash then compare. Those activities make up a small percentage of page views. I guess in a way the slower the better, if it makes a server work harder to generate then it will make an attacker's work slower to brute force.</p>
  
  <p>Cheers, B</p>