[lhazlewood]

BCrypt (level 3) is getting the basics right. Levels 4 and 5 are techniques beyond the basics used to minimize potential brute force attacks, which _are_ an issue, depending on the attack target (read the Verizon report referenced by another post on this page).

Don't think for a second that certain government agencies can't brute force a BCrypt-based password hash, especially given they will know the cost factor and salt. If the hash is encrypted, and then chunked, if an attacker doesn't have the constituent encrypted chunks and/or the encryption key _for a valid time frame_, the possibility of a brute force attack with modern computing power is almost impossible.

While you may not care about such concerns, some of Stormpath's government agency customers do, and so we provide these additional safety measures. That an average website can benefit from them is icing on the cake.

[tptacek]

You feel that you're protecting password hashes from government sponsored attackers, and yet you're iterating SHA2 as your password hash?

[lhazlewood]

Depends on the customer - if it is a government agency and SHA2 is mandated for their own passwords (per NIST standards), we comply (with a huge number of iterations based on CPU/GPU target specs). Additionally, we automatically increase iterations over time as CPU/GPU targets change - something a customer never needs to worry about (which is nice). Otherwise BCrypt or SCrypt is used for most customers.

It seems like some of the finer points of your concerns aren't being covered in this thread (e.g. # of iterations, if sufficiently high, will probably address your GPU concerns). Unfortunately for me, I can't read Hacker News all day and must move on, but if you'd like, definitely give us a call at Stormpath and we'd be quite happy to geek out and talk through the all of the details. (And I apologize if any of this came across as negative - no coffee today I guess).

[amalcon]

if an attacker doesn't have the constituent encrypted chunks and/or the encryption key _for a valid time frame_

This reads an awful lot like "If the attacker has not actually compromised the gateway." After all, the gateway needs to either be able to encrypt the password or decrypt the hash to do its job. That means the gateway needs either the key, or access to an oracle that has the key. Either way, you're compromised.

The data sharding has some merit, if only because it's more difficult to simultaneously steal systems from multiple datacenters. I suppose at some level that becomes a concern, but that's roughly the level where you start hiring people with guns to protect your computers.

[chimeracoder]

> Don't think for a second that certain government agencies can't brute force a BCrypt-based password hash, especially given they will know the cost factor and salt.

I have no doubt that government agencies have much more powerful intelligence than people realize. But knowing the salt has no connection to their ability to brute-force; it only affects their ability to use rainbow tables.

(All it does is prevent them from matching up passwords by their hashed values, so for example, if one password is cracked, it protects everyone else who is using the same password.)

But it doesn't provide any protection against brute forcing. Nothing can, short of making the hash function slower (or the password domain larger).