
How To Safely Store A Password - shawndumas
http://codahale.com/how-to-safely-store-a-password
======
eneveu
Many developers need to read and understand this. It is far from mainstream
knowledge...

The other day, I saw the following post about password hashing in my RSS feed:
<http://isc.sans.org/diary.html?storyid=11110>

\- No mention of bcrypt (though the posts mentions key stretching using SHA1)

\- "When selecting an algorithm to hash passwords, it is important to select
carefully as it is difficult to change the algorithm later. You will have to
ask users to change their password if you do as you no longer know what
password they picked." --> seriously? you can update the password the next
time they log in...

\- _"You could also add a secret, in addition to the salt. If the secret is
not stored in the database, it would not be easily reachable via a SQL
injection exploit (yes, you can use them to read files, but it requires
sufficient privileges)."_ \--> security through obscurity, nice

\- "For the paranoid, you may want to do the hashing on the client side
(javascript) . This way, the server never receives the plain text password. We
do this here for the ISC website on our login form [2]." --> oh noes...

Note that the blog has ~15k subscribers according to Google Reader...

\---------

I also launched a debate on StackOverflow the other day. A self-proclaimed
"security expert" (he later edited his post to remove this part) was advising
against using bcrypt, arguing that it would facilitate DOS attacks against the
login page... He prefers security through obscurity, using a secret salt:

[http://security.stackexchange.com/questions/4781/do-any-
secu...](http://security.stackexchange.com/questions/4781/do-any-security-
experts-recommend-bcrypt-for-password-storage/4782#4782)

I thought it was a bad idea to leave this answer unchallenged, so I tried
arguing with him. I was met with arguments of authority such as "Wow you are
out of your element and could not be more misguided on this topic" or "you
disagree because you don't understand. Show me an exploit you have written,
then I'll pay attention to you.". Happily, some (more experienced) people got
in on the debate. I hope this will help developers make an informed choice, if
they stumble upon his answer...

(edit: list formatting)

~~~
Fargren
I know very little about security, but is there something wrong with using a
hash in the client side and then using bcrypt on the server so that you never
receive the plain text password?

~~~
Someone
If the client sends hash(password) to the server, hash(password), for all
intents and purposes, _is_ the password.

After all, an attacker does not need to recover the password from the hash,
all he has to do is capture the hash and replay it.

~~~
zepolen
I'm no crypto expert but wouldn't using a nonce allow this approach to work?

~~~
pavpanchekha
How would you check the nonce? All your server gets is a black box hash.

~~~
IgorPartola
Not a security expert here.

Doesn't <http://en.wikipedia.org/wiki/Digest_access_authentication> do this?
Also the server could store the nonce in a session.

------
tzs
I'd like to see sites offer the option of not using password-based
authentication. Instead I'd like to see public key based authentication as an
option.

Basically, the site would have a copy of my public key (say my GPG key or an
ssh key), and to authenticate I prove that I have access to the corresponding
private key.

~~~
JoachimSchipper
You've just described SSL with client certificates. Works perfectly well, is
extremely secure, and has an extremely bad GUI in pretty much every browser
ever. (It's somewhat difficult to use "on the road", but that's arguably a
security feature.)

~~~
ay
I ponder the quality of the GUI is a testament to the frequency of the
mechanism's use.

But the worse GUI is arguably better than no GUI at all:

<http://code.google.com/p/android/issues/detail?id=8196> and
[http://stackoverflow.com/questions/357491/iphone-client-
cert...](http://stackoverflow.com/questions/357491/iphone-client-certificate)

So, for the purposes of the growing mobile browser market (where having this
would be the biggest benefit IMO), this is not applicable.

Which is a bit unfortunate.

------
Khao
I have read this article and read the Wikipedia entry on bcrypt and I still
cannot understand something. In this article it states that : "As computers
get faster you can increase the work factor and the hash will get slower.".
How can you make the algorithm slower over time and still be able to validate
user passwords that were stored before you changed the speed? Could anyone
enlighten me on this?

~~~
chops
The easy way is to support the previous work factors and increase it next time
the user logs in (since you'll have the password in plaintext in memory).
Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude
slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good
to go for years, the only problem is the near 1-second processing time on
semi-current hardware.

~~~
podperson
It's a hash function and, at least over an insecure connection, you should not
be transferring the plaintext password from client to server so it's not
guaranteed that you will have the plaintext password.

Assuming you're using a secure connection and you're willing to send plaintext
passwords over it then yes, you could re-hash the password when a user logs
in.

~~~
tzs
In any kind of scheme where all the server stores is some kind of hash of the
password, how are you going to verify a password without sending the plaintext
password to the server, so the server can compute the hash and compare against
the stored hash?

~~~
reginaldo
You could do that with something called a Zero-knowledge password proof[1], of
which SRP[2] is an example. As far as I know, SRP is patented. It is extremely
clever, though.

[1] <http://en.wikipedia.org/wiki/Zero-knowledge_password_proof> [2]
<http://en.wikipedia.org/wiki/Secure_remote_password_protocol>

~~~
tptacek
To the best of my knowledge the SRP patents are not a big deal, and SRP is
used in a number of commercial products. The bigger problem with SRP is that
it's dangerous; it is difficult to screw bcrypt up, but it's very easy to
screw SRP up; if you have to implement it yourself, dollars/donuts you're
going to end up with an implementation that allows me to log in without a
password.

~~~
reginaldo
I agree. I should just clarify that I'm all for bcrypt, having used it and
recommended to friends/clients/employers. When I found out about SRP, I was
researching on ways to do exactly what tzs asked, i.e., verifying a password
without sending the plaintext (or plaintext-equivalent). In my case, the
client had a login form that couldn't be placed behind SSL (don't ask why). Do
you know of any solutions to this problem?

------
stephth
Looks like Rails 3.1 is using bcrypt:

[https://github.com/rails/rails/blob/master/activemodel/lib/a...](https://github.com/rails/rails/blob/master/activemodel/lib/active_model/secure_password.rb)

~~~
bdclimber14
So does Devise, one of the most popular authentication Ruby gems.

------
nonane
The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a
laptop.

How does a server authenticate users in high volume with bcrypt? ~0.25 secs
per auth request might warrant having a separate server just for
authentication.

~~~
tptacek
Several of the largest sites in the world have scaled bcrypt. There are longer
answers as to why this is not a big deal, but if it helps to kill the red
herring that bcrypt might not scale: Twitter uses it.

~~~
furyg3
I'm really interested into the longer answer!

I'm sold on bcrypt but like to hear scaling stories :)

~~~
moe
One possible, slightly longer, answer would be that "login" is a relatively
rare operation in the grand scheme of things.

Users (usually) need to login only once per session. And on sites that have
the little "Remember me"-tickbox a session may very well last for days or even
months.

------
firsttimeposter
People keep posting this here. But I think
<http://www.tarsnap.com/scrypt.html> should probably be considered the best
way to do this today. Google is even using it in ChromeOS.

~~~
Xk
It is true that scrypt is better than bcrypt, but the transition from
salt+SHA-1 to bcrypt is significatnly better than from bcrypt to scrypt, and
scrypt doesn't have nearly as nice of an interface as bcrypt does.

~~~
pjscott
The easy interface and wide availability of language bindings to bcrypt is a
big deal. The easier it is to use, the more likely people are to use it, and
the less likely they are to mess it up. Scrypt isn't quite there yet, and
bcrypt is still very good.

------
yogsototh
I am surprised nobody had already talked about scrypt yet. Here is an old
hackernews entry about it.

<http://news.ycombinator.com/item?id=601408>

I would have loved to use scrypt, but there is only a C implementation. I
would had loved to have at least a javascript one.

~~~
JoachimSchipper
Javascript? Have fun securing that one against timing attacks. Also, it's so
much slower than the C implementation (remember that crypto algorithms are
very carefully designed for 32- or 64-bit words or arbitrary-length integers;
Javascript's doubles are a _very_ poor match.)

~~~
SamReidHughes
Timing attacks are not a problem if you're using it to hash passwords. Also,
Javascript implementations don't use doubles for pure integer arithmetic.

~~~
JoachimSchipper
If I can observe your (SSL-encrypted) login session, I can time how long the
server takes to process your (presumably real) password. What makes you think
password hashes don't need to worry about this?

~~~
JonnieCache
Would you really be able to do timing attacks on a server from the client
side? I thought you needed a much greater accuracy of measurement, sub-
millisecond, than you would be able to achieve with network latency in the
mix.

~~~
VBprogrammer
Apparently it can be done.

<http://www.cs.cmu.edu/~dbrumley/pubs/openssltiming.pdf>

------
16s
It's good to raise awareness of this issue. When more devs began using bcrypt
or scrypt, offline password cracking will be much, much more difficult.

The only reason GPUs are cited as testing 600 million hashes a second is that
the underlying hashes came from a Microsoft Windows Active Directory where
they were simply MD4 encoded. That speed is not possible with bcrypt. Devs
need to understand this.

Edit: Yes, that's MD4 not MD5. Microsoft Windows NT hashes are simply Unicode
strings that are MD4'ed. This includes Windows 7 and Windows 2008 server.

~~~
yuhong
And note if you already have this hash you can use it to login directly anyway
as most Windows network protocols take this hash directly. The real important
thing IMO is NTLM challenge/responses based on the hash, which unfortunately
is not much better. In case of NTLMv1/MS-CHAP it is three 56-bit DES
operations on separate parts of the 128-bit hash (the third being only 2^16 so
it is easy to precompute, as shown by asleap). NTLMv2's HMAC-MD5 is fast too.

------
falcolas
Honest question. Why would someone who handles more than a couple-dozen login
attempts per second choose to use bcrypt? It would seem that the computational
overhead of supporting bcrypt at scale would not make a lot of financial
sense.

~~~
dpark
You can change the work factor to scale the amount of time it takes to do the
processing. Beyond that, there's a cost to security. If you actually need
security, you may need to pay for it. How much is it going to cost you to buy
an extra server vs the loss of business due to a serious security breach?

~~~
falcolas
In the court of public image, simply loosing the data in the first place will
cost you business, now matter how secure that data may be. The trust to secure
your data will be lost, regardless of whether you used bcrypt or sha or
plaintext.

If you consider the loss of business to be pretty much constant in the event
of a loss of control of the customer's data, what is the value of extra
server(s) (plus the cost of maintenance) for one of the least valuable pieces
of information a customer can give you?

As an example, look at Instapaper. How many people are more concerned that the
government has access to their sha1 encrypted passwords as opposed being
concerned that the government has free access to their reading history?

~~~
dpark
For sure there's going to be loss of confidence either way. You're probably
going to have a bigger loss if the security experts are pointing out that you
couldn't even get password storage right, though.

Obviously they It's up to you whether you care enough about your customers to
try to get security right. You gave a reasonable argument for why using bcrypt
instead of md5 makes little financial sense. However, that same argument
applies to plaintext vs hashed. Or hashed vs hashed with salt. In the end, you
need to decide how much you care about security, and also weigh how much
security you are morally obligated to provide.

~~~
falcolas
Plaintest vs. hash, or salted hash vs. salted hash do not incur the same
performance penalty.

And while I may feel morally obligated to provide great security, the people I
report to would not be as impressed with that in a cost-benefit analysis.

tl;dr It's a great idea, but a tough sell, particularly at scale.

~~~
dpark
My hashed/unhashed comparison was not a performance statement, but a trust
statement. If a breach will lose the same amount of confidence regardless of
password storage, why bother with even hashing?

I can't imagine how "good security - scalable enough for Twitter" can be a
hard sell. Your customers certainly won't by sympathetic if they learn that
you willfully chose weaker security to save a buck.

------
pbreit
Can someone help me understand what a password cracker does with a list of
salted/hashed passwords? How do they know they've figured out the right plain
text passwords without bouncing them against the authentication logic?

~~~
andrewcooke
i suspect you don't know that the salt is stored with the password [edit: when
using standard libraries like crypt and bcrypt - please don't invent your own
scheme]. so when someone steals the password list they get the salt too.

the salt is not "secret" - it is stored in plain text for each password. it
does not need to be secret to do its job (defend against rainbow tables).

~~~
roel_v
_Sometimes_ the salt is stored with the password. I sometimes see having a
hardcoded salt referred to as 'security by obscurity', but considering that
many attacks result in just a database dump, not giving attackers access to
(at least part of) the hash is a useful security layer.

------
giaskaylee
The real question should always be how you detect and handle these attacks.
Allowing someone to attack your service for 12 years and eating up your
resources in the meanwhile just sounds too passive a solution.

~~~
Xk
That's not the attack you worry about: instead, consider the case where
someone somehow obtains the database and can do an offline attack on it. Be it
a SQL injection or account compromise (or sheer negligence and publishing the
database), once that happens you'd better handle passwords reasonably well.

If the only attack situation you're worried about is a online guessing attack,
then there's no need to even hash passwords.

~~~
giaskaylee
Sounds to be the case, thanks for the tips.

------
tomjen3
What always annoys me with the discussion of passwords is that everybody here
focus on a technical solution that allows the user to continue to use insecure
passwords.

That isn't the problem. Reuse is. And the best way around that is to not let
the user select the password, just generate it server side. Technically this
is easier to get right than some complex password generation scheme and the
end result is properly better too.

~~~
Jach
Reuse is a problem, but weak passwords are the biggest problem. If you have a
strong password that never gets cracked/leaked/intercepted but you use it
everywhere you're still fine, but that's not recommended.

Generating server-side passwords is horrible as well since you're counting on
the user to write it down and/or let the browser's password manager save it.
What if the user wants to log in with a different machine/browser?

I think the best solution is to, first, forbid passwords under 10 characters.
8 is still relatively secure, but not really, 10 at least gives you a fighting
chance. Second, run your own dictionary attack (you can load
/usr/share/dict/words into a hashtable and check for membership in sub-second
times..in fact, here:

    
    
        import sys
        f = open('/usr/share/dict/words')
        words = {}
        for line in f:
          words[line.replace('\n','')] = None
        
        if sys.argv[1] in words:
          print 'You fail'
    

) and alert the user if their password sucks and to pick a new one. (You might
want to check for membership of their password with an 's' or a '1' or
something added on as well.) You might also want to do some sort of complexity
analysis as well that requires e.g. at least one uppercase, one lowercase, one
number.

The infrastructure problem is places like Banks saying "Enter a password
between 6 and 12 characters and only use alphanumeric characters!"

~~~
ihodes
Eight characters for a password seems plenty long to me, if you're truly using
a random password. You have [A-Za-z] = 52 chars, [0-9] = 10, [!@#$%^&
_()_-+=;':",. <>/?\|[]{}] = 30, for a total of 92 possibilities. Then you have
an 8 character password. Even if the attacker knows you're using 8 characters,
you've got ((92^8)_0.3)/60/60/60/24/365/100 = 271 centuries if it takes 0.01
seconds a try. And we're really talking over 8 thousand centuries if we're
having bcrypt take 0.3 seconds.

So the problem is that passwords tend not to be random. This greatly decreases
the problem-space. But b/scrypt solves the problem of length, within reason.

~~~
vog
I fully agree, but I'd focus more on the length than on the character set. It
is not a problem if the password contains only alphanum characters, as long as
those are random.

For instance, a plain alphanum password of length 9 is stronger than a
password of length 8 that allows for special characters. (because 62^9 > 94^8)

In other words, adding one character to your password is as good as choosing
from a bigger character set.

Okay, beginning at length 10, you'd need to add two characters, but that's
really all you need to do up to length 20. (which is an insane length for a
random password anyway)

~~~
Jach
C^x grows a lot faster than x^C, except for specific x's and C's you're almost
always much better off adding to the length. And 20's nuttin'. At the risk of
publishing more hastily written code for critiquing, here's a shell script
password generator I use sometimes. <https://gist.github.com/1058565>

------
mleonhard
Let's say I use bcrypt and want to increase the work factor every year. Is it
possible to determine the work factor of an existing hash, or will I need to
maintain this information alongside the hash? The java and python bcrypt APIs
don't have any function that returns the work factor.

Can I increase the work factor of an existing hash, or must I wait until the
user logs in and then use the plaintext password to generate a new hash?

Is there a bcrypt API that provides a hash comparison function that addresses
timing attacks? The py-bcrypt example code uses the '==' operator to compare
hash strings, leaking timing information:

    
    
        # Check that an unencrypted password matches one that has
        # previously been hashed
        if bcrypt.hashpw(password, hashed) == hashed:
                print "It matches"
        else:
                print "It does not match"
    

(from <http://www.mindrot.org/projects/py-bcrypt/>)

~~~
mleonhard
To answer my first question, the work factor can be extracted from the hash.
It is stored as a 2-digit decimal number in the fifth and sixth bytes of the
hash. See [http://code.google.com/p/py-
bcrypt/source/browse/bcrypt/bcry...](http://code.google.com/p/py-
bcrypt/source/browse/bcrypt/bcrypt.c#141)

------
peteretep
I recently put together a commentary + code on how to upgrade passwords hashed
insecurely in your DB without user intervention. This was in response to MtGox
talking about "slowly migrating users", which presumably means upgrading
passwords at the point of login:

<https://gist.github.com/1051238>

~~~
carbocation
If I'm not misunderstanding your purpose, why not just:

1) Take those md5 unsalted passwords and 2) bcrypt them

Then upgrade the users to non-pre-hashed bcrypt as they log in?

?

~~~
peteretep
Why do you think that isn't what this is doing, only with fault tolerance to
allow more than one scheme upgrade?

~~~
carbocation
Because the juicy bits got cut off due to the way github is displayed on my
phone. Sorry I couldn't see that portion!

------
bborud
In security the most important thing you can teach people is to be aware when
things are harder than they look so they'll take a bit of extra time educating
themselves and talking to other people.

Learning how to separate good from bad advice is a skill that needs to be
maintained. Also, in all software that is supposed to provide some form of
security, one has to be prepared for the eventuality that it probably contains
errors.

I used to read a lot of books on cryptography and the use of cryptography.
I've forgotten most of it by today, and to be quite frank: the more I know,
the less I want to write crypto software. There is something deeply
unsatisifying about work where you know that what will in all likelihood trip
you up is some trivial, stupid mistake.

It isn't hard because of the crypto itself. Sure, certain cryptographic
libraries can be extremely awkward to use (which in itself is a security
risk), but the problem usually comes from where you aren't looking for them.

I cringe a bit when people advertise software as being secure because it uses
this or that encryption scheme. I also cringe when people claim that they
"encrypt databases" and their systems are therefore secure -- because, for
most usage scenarios, I can't think of any really secure way of doing this.
Not without compromises anyway. And while I honestly know that I have just a
rudimentary grasp on cryptography, I know a lot more about it than most people
who make products that hinge upon correct application of crypto.

Just the other day I was trying to determine how many rounds I wanted to use
in bcrypt for storing passwords for a given system. I think I spent most of
the day pondering this question, writing benchmarks and reading up on what
other people said on the topic. A couple of days later a friend of mine
emailed me a code snippet that implemented the password hashing scheme of a
commercial product they use that makes shameless claims about being secure. (I
think he probably just looked at the hashed passwords and made a guess about
the method they had used. I don't think he had a look at the original source
code). If memory serves the product uses unsalted SHA1 hashing. In other
words, the vendor didn't even bother thinking about the problem.

What scares me a bit is that even I thought "well, if they claim to have well
thought-out password handling and they are in the business of selling security
systems, I suppose they have probably given this a lot of thought" the first
time I visited their website. After all, large companies give them millions.
Right?

I wonder what other things they are doing equally badly.

------
klon
Does anyone know how Djangos built-in password hashing fares?

~~~
brown9-2
Looks like the built in stuff uses either sha1, md5, or crypt:
<https://docs.djangoproject.com/en/dev/topics/auth/>

~~~
lamby
<http://code.playfire.com/django-bcrypt/> Backwords-compatible bcrypt support.

------
mildweed
Previous post: <http://news.ycombinator.com/item?id=1998819>

Similar discussion: [http://chargen.matasano.com/chargen/2007/9/7/enough-with-
the...](http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-
tables-what-you-need-to-know-about-s.html)

------
jorangreef
To see if I understand bcrypt correctly, would this pseudo code achieve a
similar adaptable computational cost?

    
    
      function(uniqueSalt128Bit, password, rounds) {
        var hash = SHA1(uniqueSalt128Bit + password);
        var length = Math.pow(2, rounds);
        while (length--) hash = SHA1(hash);
        return hash;
      }

~~~
nemeth
This is similar to SHA512 crypt:
[http://packages.python.org/passlib/lib/passlib.hash.sha512_c...](http://packages.python.org/passlib/lib/passlib.hash.sha512_crypt.html)

------
antihero
Or a stretched newer algorithm like Whirlpool. Or stretched SHA-256? What
advantages does bcrypt have over them?

~~~
owenmarshall
It's been around for years and remained solid. It's implemented in every
language under the sun. It can be tuned to be _plenty slow_ , even today.

That said, there's nothing wrong with choosing another password derivation
scheme. glibc's crypt() provides _three_ : PHK's MD5 scheme, and Ulrich
Drepper's stretched SHA-{256,512}. Just don't roll your own and you'll be
ahead of the majority of programmers.

------
fleitz
What properties of bcrypt make it better than SHA-512 with more iterations to
make the time taken to process it equivalent? Is there something about the
algorithm that makes it more difficult to speed up via GPU/hardware?

------
tzs
Why not PBKDF2?

~~~
tptacek
PBKDF2 is fine. bcrypt has better library support. I'd rather you used a
bcrypt library than try to roll your own PBKDF2.

~~~
cperciva
bcrypt is also slightly stronger than PBKDF2, since it requires a larger
circuit to compute.

The only reason you would want to use PBKDF2 is if (a) you already have a hash
and don't want to add blowfish to your code/circuit, or (b) you want to be
standards-compliant.

------
joejohnson
Now, how do I explain to my girlfriend that picking longer, more complex
passwords is a realistic security precaution and that I'm not just a paranoid
nerd?

------
ltamake
For PHP users, phpass is a really nice password library.
<http://www.openwall.com/phpass/>

~~~
SaltwaterC
Shameless plug for PHP devs: <https://github.com/SaltwaterC/PasswordHash2> \-
you may like this as well.

------
Revisor
What work factor do you recommend to make it reasonably fast and still
bruteforce-proof with the current HW?

------
Tichy
So I assume if you use bcrypt, you only verify the password once upon login,
and then store a cookie that verifies the user is logged in? That brings other
security risks.

But the alternative seems to be to make every request very slow, because it
would require bcrypting the password with every request.

~~~
brown9-2
If you were to re-authenticate the user on every request, how do you have the
client send the password to the server on every request without making the
user enter it every time?

~~~
Tichy
By storing it in a cookie - oh :-)

I suppose you could come up with some scheme where you create a new cookie
with every request, a kind of one-time cookie to prevent session hijacking.
Probably not worth it and not 100% reliable, though.

I guess just trusting in cookies is the only real option.

Or HTTP BasicAuth, it sends the password with every request I think
(unencrypted, I know). In either case in theory you need HTTPS.

~~~
jpeterson
Oh man, please tell me I'm misreading you, and you don't actually store your
users' usernames and passwords in a cookie.

~~~
Tichy
No of course not. I mean yes, you misread me.

------
SaltwaterC
<http://www.openwall.com/lists/announce/2011/06/21/1> \- some bcrypt
implementations out there are still broken if they used this code. You may
give the SHA-based scheme a chance.

------
d0vs
bcrypt is so flawed...

~~~
bradleyland
If you want to stand by that assertion, please provide some information to
back it up. You'd become very popular in this community (and the security
community at large) if you could provide a good basis for that statement.

Otherwise, you're just trolling, and I've committed a cardinal sin.

------
ck2
and/or stop using a single word and use sentences (phrase)

eight characters is easy - try cracking 50

~~~
pavel_lishin
Not too difficult if it's composed of dictionary words. Why not automatically
generate random strings to use? No pattern at all.

~~~
cfgvjkljhgfb
with cuda and the cloud it's quicker to try all possible passwords (starting
with aaaaaaa...) than to search a rainbow table of dictionary words so
":Hy6&z@z" is now no more secure than "password"

~~~
pavel_lishin
Rainbow tables don't apply to salted passwords.

~~~
ylem
But you can still do a brute force attack--that's part of why SHA1 has some
issues--you can beat it with brute force and enough GPUs.

------
praptak
You can add the configurable slowness factor to any secure hash. Just use
salts but leave out k bits from each when storing them. The more bits you
leave out, the more work it takes to verify a password as the verification
procedure needs to brute-force the missing k bits.

~~~
dchest
You can also write a new cipher, discover a new key derivation function, and
invent a new hash function. But that's not the point. Use bcrypt or scrypt.

~~~
praptak
Any analogy between using a standard technique with a standard hash and going
for DYI cryptography is a bit stretched.

~~~
dchest
Really? You just described a KDF, and advised people to use it without
providing any references to implementations. "Just leave out k bits of salt
and brute-force it" -- do you really expect non-cryptographers to be able to
correctly implement this algorithm? If you insist on using hashes, at least
you could tell people to use PBKDF2 to turn a standard hash into KDF.

------
evo_9
Another thread where seeing Karma would really help...

Maybe it should be optional?

~~~
SkyMarshal
If karma is needed to judge the quality of someone's post, then the karma
counts are probably inaccurate anyway. At best they'd be interspersed with
votes by people who just thought the answer sounded good without really
knowing how accurate and informed it is. At worst, the majority of the votes
would consist of that type.

HN is better without karma, just think of it as a place to find out about
concepts you might not have been aware, then drill down on it with some more
trusted source.

------
zubisu
the weaknews is actually storing the salt or code or key with the password.
using bcrypt helps a bit but doesnt truly solve the issue. i think thats
important to point out. sha1 with a salt u cant find beats bcrypt with a key u
know any day

~~~
Xk
No. Not at all.

If someone managed to break in to your website and get the password hashes,
chances are they also have your "secret" salt. There is _no_ reason to
separate the salt from the hash, and, in fact, there are no implementations
which do that.

However, if I can't convince you of that, then if you ever make a website that
takes passwords, please use bcrypt. You can do your super-special-salt-
separation-scheme, but just use bcrypt instead of SHA-1.

~~~
praptak
_"If someone managed to break in to your website and get the password hashes,
chances are they also have your "secret" salt."_

I believe the GP was referring to the scheme where you don't store the salts
at all (or only store some bits of each salt.) The verification needs to
brute-force the salt (or the missing bits) each time it verifies the password.

The missing bits are quite similar to the bcrypt workfactor - the more you
leave out the harder it is for both the attacker and the legitimate
verification to verify passwords.

~~~
brown9-2
Then how in the world does your code know what salt to use when the user
presents his or her password?

If it is derived in code from some other piece of user data then it is still
"known" if your DB leaks - you have to assume someone who stole your database
also stole your code.

~~~
roel_v
"you have to assume someone who stole your database also stole your code."

Maybe, but that doesn't mean that a separate salt, not in the database, will
prevent certain attacks, and as such is a viable option. Security is about
layering, not about 'xyz isn't 100% secure in 100% of the cases, forget about
it'.

~~~
owenmarshall
That's fair, but it doesn't change the insanely wrong statement that triggered
this comment chain:

"sha1 with a salt u cant find beats bcrypt with a key u know any day"

This is _fractally wrong_.

~~~
roel_v
OK then we agree there :)

