
Password Security The Right Way  - chunsaker
http://www.stormpath.com/blog/password-security-right-way
======
tptacek
No.

<http://codahale.com/how-to-safely-store-a-password/>

It's really not more complicated than this. You can use scrypt instead of
bcrypt if that makes you happy. The secret crypto keys in separate storage
locations stuff is silly. Get the basics right.

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

------
jgrahamc
I would be very skeptical about dealing with this company...

Level 2 ask for a CSPNG to be used to generate the salt. Why? Given that the
salt is assumed to be a piece of public knowledge when attacking a system like
this there's no need for it to be output from a CSPNG as there's no concern
about a random number generator weakness as an attack vector.

Level 3 it's not clear if bcrypt/scrypt are used or just some SHA iterations.
There's a difference between the two.

Levels 4 and 5 don't seem to provide much additional security over getting the
hashing right. Also, there's an awful lot of 'we do secret stuff' that worries
me.

And specifically the claim in part 5 that all the stores would have to be
compromised seems erroneous to me. Suppose I compromise one store and I have
part of the hash, I can still run a password cracker and compare with part of
the hash I have. Sure, there's some error there but I can then take the
guessed password and try it to see if I got it right.

~~~
lhazlewood
Great questions.

With regard to CSPNG, this SO post answer is good:
[http://stackoverflow.com/questions/536584/non-random-salt-
fo...](http://stackoverflow.com/questions/536584/non-random-salt-for-password-
hashes)

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.

------
tzs
Can we someday move away from password on the server, at least as an option?
Give me the option of setting up my account with a public key instead of a
password, and logging in by demonstrating that I have access to the
corresponding private key.

One might object that this would mean I could only access my account from
computers and devices where I keep a copy of my private key. True--but I'm
ALREADY in that position for most sites, because I use long random passwords
that I manage with a password manager running on my computers and devices.

~~~
stan_rogers
You mean for web apps? Lotus Notes has done that since forever. The Notes
password is just the seed of a decryption key for your user ID file; getting
the password correct decrypts the keys, both private and secret (used for
shared symmetrically-encrypted document fields); the actual server login is
PKI. (The Domino web password for HTML apps, when enabled, is a standard
hashed-values type, though.)

------
sixothree
The hey girl crap needs to end. Now.

------
strictfp
While compromized passwords are one problem, leaking your data is bad in so
many other ways as well. Yet almost all focus lies in obfuscating passwords to
prevent extraction in the case of a breach. We don't talk as much about
securing addresses and SSNs and other sensitive data.

Well guess what, if the attacker has access to your system he can just install
a password logger and all your obfuscation would be in vain.

All extra security is added value, sure, but focus on other areas wouldn't
hurt.

~~~
chunsaker
Totally Agree! I wanted to keep the scope for this narrow so it didn't turn
into a total beast. The guys over at Cloud Passage have some great content on
server security (<http://blog.cloudpassage.com/>) that I think is really well
informed, and we're going to do a followup on backend security.

------
codegeek
This article definitely seems like an overkill. If you are using bcrypt or
scrypt properly, what else is needed other than common sense of course.

------
asalazar
Something the article didn't cover but should is the upkeep over time of
whatever algorithm you use. We can argue about todays algorithms. But what do
we do when those algorithm are superseded? Or when the minimum complexity
factor needs to go up. If you're an app dev or devops, will you know when that
happens and how will you update?

------
cookingrobot
Also realize that you don't have to build every component of your website
yourself - and unless security is the focus of your business, dealing with
storing passwords might not be the best use of your time.

We built dailycred.com to handle exactly these sorts of issues for you.

------
peterwwillis
Every time I read "military-grade" on one of their pages, my head twitches.
Since your whole product hinges on HTTPS, you might want to tweak a couple
things:

1\. Disable TLS compression. (it's currently on)

2\. Disable CBC-based ciphersuites. (they're currently enabled, or higher
priority than RC4)

3\. Get more than one IP address to host your site, preferably distributed to
a different part of the world. It seems you've got two separate amazon IPs,
one for www.stormpath.com and one for stormpath.com; i'm not sure if those are
anycast addresses but I doubt it. I _really_ hope they're not in the US
East/Virginia zone, since it goes down about once a year (which makes your
100% availability guarantee for enterprise customers impossible)

4\. Your main cert has SANs for stormpath.com, www.stormpath.com,
api.stormpath.com, ci.stormpath.com, repository.stormpath.com. I know that
makes it easier to manage, but when one of these hosts gets compromised and
its private key stolen, the whole kit and caboodle is compromised.

5\. Implement DNSSEC and IPv6. Your public sector clients will get a kick out
of it.

~~~
tptacek
You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will
do approximately zero for your security, too.

~~~
peterwwillis
True, you can just give RC4 higher priority. Implementing DNSSEC/IPv6 is just
meant to give managers who are obsessed with "military-grade" anything a hard-
on.

------
bruceboughton
Too offensive;didn't read

