[lhazlewood]

Great questions.

With regard to CSPNG, this SO post answer is good: http://stackoverflow.com/questions/536584/non-random-salt-fo...

As for bcrypt/scrypt vs iterations, there is a difference, but it's minor. Bcrypt is not demonstrably any more secure than SHA-512 for example - the difference is in computation time (the Blowfish key schedule is _slow_ by nature). With enough iterations (1 million? 10 million? It depends on your CPU/GPU architecture targets), the same effect of slowing down the attacker is achieved. Increasing the number of iterations (and using the output as the next input) is similar to increasing the BCrypt cost factor. You just have to know your target threshold and pick a number accordingly.

Your summary of Level 5 is not quite right - Level 5 is about storing separate chunks of ciphertext - not chunks of the hash's MCF text (MCF = Modular Crypt Format). You can't even start to brute force a hash if you can't decrypt the ciphertext to begin with.

Finally, Stormpath doesn't do anything 'secret' and we go through diligence on these matters with our larger customers. We're happy to divulge all of our techniques (e.g. how we use multi-factor authentication, how we secure firewalls, etc). That information is just outside the scope of a password-related blog article.

[tptacek]

That Stack Overflow post doesn't refute John Graham-Cumming's point, which is that the cryptographic strength of a salt doesn't change the security of a secure password system. The salt is there to randomize the hashes; it doesn't resist active attacks. People that obsess on the security of their salt values misunderstand the design of secure hash systems.

Bcrypt is demonstrably more secure than SHA-512. You can look to the Openwall GPU password cracking project for illustration of how. It is easier to speed up SHA2 on a GPU than it is to speed up bcrypt. Scrypt is markedly different from SHA2; it's designed specifically to be difficult to optimize with GPUs (a property bcrypt has only accidentally at present).

Moreover: the best practice for using SHA2 as a password hash is to use PBKDF2, which is not simply iterating SHA2 (you can learn more about PBKDF2 on Wikipedia). Iterated SHA2 is a fine answer for existing applications that need the simplest possible path to something better than a salted hash, but it's not a good answer for new designs.

Your responses to both these points appear to be materially wrong.

[jgrahamc]

"Your summary of Level 5 is not quite right - Level 5 is about storing separate chunks of ciphertext"

Ah, I see. So you generate hash H and using some private key K you calculate C(H,K) where C is some cryptographic algorithm and then you split C(H,K) into parts and spread them around.

So my scenario is complicated by the necessity to compromise K in addition to one of the places where bits of the C(H,K) is stored.

I still feel that the real security of this system relies on the difficulty of computing H.