lhazlewood

HMAC authentication requires both the client and the server to have a shared secret (or more likely a derived key based on a shared secret). The secret cannot be saved as a one-way hash (as might be common for a password). So you couldn't use BCrypt or SCrypt to hash the shared (or derived) secret since the server would never be able to acquire the value to calculate the same digest.

You can still encrypt the secret, e.g. using AES 256 bit encryption with secure random Initialization Vectors and rolling keys. This too is not easily 'brute forceable', but is very fast to decrypt compared to a BCrypt comparison (key storage should also be in a separate location than the main data store).

I gathered as much. But in practice, how often do you see RFC 2617 Digest authc used in non-browser scenarios? (I'm genuinely curious. I haven't seen it used much at all outside of web browsers, so I'm curious what others may have come across).

Totally agree. The key here is that you're doing the work to implement the algorithms, not your customers. If they had to do it, they probably just wouldn't use it.

You shouldn't ever use username/password pairs for API authentication. If the user ever changed their password, then their API calls would immediately fail!

This is one of many benefits of using multiple (revokable) API Keys.

Stormpath's custom scheme is very similar to Amazon's.

But per the blog article, you'd only want to do this if you are willing to support client libraries/sdks that implement it as well. No one wants to spend the time to implement non-standard custom HMAC algorithms.

Depends on the UA (curl?)

There are many types of digest authentication - OAuth1.0a and Amazon's and Stormpath's custom schemes are examples. Browser-specific digest authentication wasn't covered however since the article was about REST APIs and most REST clients are not browsers.

A UUID is first and foremost a 128 bit number, irrespective of its text encoding.

Its 'canonical' form uses HEX-only encoding. A 'Url62' can be another encoding. 'Url62' wouldn't be a canonical encoding, but it's still a 128 bit UUID number.

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

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.

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.