

Md5crypt is no longer strong enough - phkamp
http://phk.freebsd.dk/sagas/md5crypt_eol.html

======
ddlatham
_Please notice that there is _no_ advantage in everybody in the world using
the exact same algorithm, quite the contrary in fact._

If your password database is leaked, there are 2 categories of attacks that
you need to be concerned with:

1\. Brute force

2\. A weakness in your implementation

He's right that brute force attacks will require potentially more work if you
have a custom scheme as the attacker will have to work out the details of the
scheme before using brute force (category 1).

However, many cryptographic compromises are actually due to bugs or weaknesses
in the implementation (category 2); i.e. on paper your custom combination of
schemes is fine, but you made a bug in implementing it or forgot to handle
some case correctly.

How can you have confidence that your scheme is safe from category 2 attacks?
Use a scheme that has already been widely reviewed and attacked. If no one has
been able to find a vulnerability in it thus far, there's a good chance that
your attacker won't either.

So there _is_ an advantage to using the same scheme that many others use. Use
something hard, like scrypt, bcrypt, or PBKDF2, but also find an
implementation of it that is likely to have been well used, reviewed, and
hopefully attacked.

~~~
ovi256
I think what he's suggesting is composing secure hash functions with some
simple customisable steps, like xor, negation, so that the final result is as
secure as scrypt, bcrypt, what have you, but also customized, so that standard
tools won't work, and the attacker would have to do some custom legwork to
attack your application. This, done correctly, would increase the cost of
attacking to the point of making drive-by, mass-trolling attacks uneconomical,
as they're based on pointing an exploit tool at a list of adresses.

It will not deter targeted attacks (spearfishing) by competent attackers, but
again, not much would.

~~~
chc
The idea that my customizations would make it appreciably more secure
(especially vs. just slightly increasing the work factor) seems questionable
to me. On the other hand, it's very plausible that my customizations could
accidentally make it _less_ secure. Way smarter folks than me have messed up
algorithms they actually put a lot of thought into — I'm not going to go
blithely turning knobs in good algorithms and hope their positions weren't
important.

Incidentally, what kind of drive-by attack are you thinking? Like, you have
your password database sitting out in the open and there are bots crawling the
web trying mechanically to crack it? Because that doesn't sound like a common
case, but I'm not sure what else you could mean.

~~~
aethr
[deleted]

This comment was factually incorrect and only served to cloud the issue. The
link given in one of the responses provides more than enough information for a
developer to understand the options available for password storage.

Apologies for the noise.

~~~
shadowfiend
bcrypt in and of itself already uses multiple runs to make it expensive in
terms of CPU time to reproduce a given password. Moreover, salts are precisely
designed to help against rainbow table attacks by making it infeasible to
create rainbow tables including the large number of salts that you tag onto
the end of a given password. bcrypt includes a salt as part of its core.

So no, if your scheme is “simply” bcrypt(password), it will not take so short
a time for someone to extract passwords from rainbow tables, because they
won't be able to have rainbow tables. Proper rainbow tables would need to both
account for the salt and the number of encoding runs your bcrypt function has
(which, incidentally, is also a configurable value).

Some information on how bcrypt, scrypt and friends apply salting and
stretching to resist attacks was in yesterday's post at
<http://throwingfire.com/storing-passwords-securely/> . It's worth a read.

~~~
aethr
Yes, you're completely right. I was actually trying to illustrate the
"tweakable knobs" concept in bcrypt in my nested example but I can see that my
explanation was not helpful, and served to confuse the issue.

Thank you for clarifying!

------
gibybo
>All major internet sites, anybody with more than 50.000 passwords, should
design or configure a unique algorithm for their site

He probably means to use some combination of well known/tested algorithms
rather than inventing your own crypto, but I think his wording is ambiguous
enough to be dangerous. While there is some benefit to using a unique
algorithm for your site, it's almost certainly more risky than using a secure
algorithm (i.e. bcrypt/scrypt/etc) even if every other site was using it too.

~~~
16s
One, often over-looked reason, that website designers chose simple MD5 or SHA1
hashing (and why many still do) is for portability. Years ago this was more of
an issue than it is today. They may wish to change web frameworks, programming
languages, service providers, etc. and when doing so they want a simple, easy
way to use the hashes they have.

Also, many big service providers still use MD5 or SHA1. I saw a company
migrate to Google Mail from an old legacy mail system and part of that was
integrating some authentication services too. This was several years ago, but
at that time, Google accepted hashes in two formats only... MD5 or SHA1.

~~~
mike-cardwell
It's pretty easy to migrate users from one hashing algorithm to another when
they next log in:

    
    
      if( user has an old style hash ){
        if( password verifies against old style hash ){
          add a new style hash
          delete the old style hash
          log them in
        }
      } else {
        if( password verifies against new style hash ){
           log them in
        }
      }

~~~
StavrosK
Eh, why not just bcrypt the SHA1/MD5 hashes? Your auth check will just become
bcrypt(SHA1(pass)) rather than bcrypt(pass). You can convert all passwords
right away and I don't see any significant downside to it.

~~~
pwaring
Will there not be a time lapse whilst you run bcrypt on all the existing
hashes to update your users table? Given that bcrypt is intentionally 'slow',
this might be a problem for applications with large numbers of users (albeit a
one-off cost).

I agree that for small sites, changing the auth check and updating all the
existing rows (and deleting/overwriting the old hashes) is probably the best
solution though.

~~~
StavrosK
> Will there not be a time lapse whilst you run bcrypt on all the existing
> hashes to update your users table?

No, just SHA1 the password and check, and then bcrypt(SHA1) and check, until
the encryption process finishes. Or just check the length, or store the hash
type along with the hash, a la Django. These problems are trivial, really.

------
phkamp
I've been offline for some hours, and just wish to add a few concluding
thoughts here:

No, I'm obviously not proposing that people do something stupid with crypto,
we've had enough of that in recent days already.

But I am trying to provoke one or more card-carrying cryptographers to
realize, that while password protection may be a problem we have good and
strong theoretical solution for, those solutions will not protect any
passwords until somebody turn them into Open Source code we can use.

I only wrote md5crypt because nobody else had done so, and nobody else wanted
to do so at the time, and FreeBSD needed an ITAR exportable password
scrambler.

If more cryptographers wrote more code under liberal Open Source licenses,
instead of bitchy complaints against the people who do write code, then the
world might gradually become a better place

I have been dreading this announcement for a couple of years, knowing full
well that the majority of the world can't tell MD5 from md5crypt.

It is a credit to hackernews that you could, much appreciated.

------
dchest
Ah, the good old "secret algorithm" thing.

If you really want a "custom algorithm", the better advice would be to use a
known algorithm with a secret key.

For example,

[https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage)

Why? See <http://en.wikipedia.org/wiki/Kerckhoffs_principle>

In most case, you don't need this, though. Can you prove that your
construction is secure? How many hashing algorithms are there? Remember that
big O thing. Just increasing the workfactor for scrypt will be much better
than using a combination of 5 or so hash functions.

~~~
konstruktor
There is no mention in the article of secret algorithms.

~~~
dchest
"Unique algorithm ... in order to make development of highly optimized
password brute-force technologies a "per-site" exercise for attackers" for
KDF/password hashing is similar in principle to secret algorithm for ciphers:
consider that the attacker already has an optimized brute-force technology for
your combination of primitives (for ciphers: consider that the attacker knows
your algorithm); replace this unique algorithm with the work factor/secret key
to have fewer moving parts.

~~~
drewcrawford
I think a clearer way to express the author's position is to consider the case
where a feasible attack is discovered on (say) SHA1. If you consider the
probability of an attack on SHA1 and blowfish to be of independent
probability, then the author's scheme allows you to "hedge your bets", as in
theory your algorithm is as strong as its strongest component, even if the
strengths of its components change in the future due to new discoveries.

This line of reasoning assumes A) that the probabilities of attacks on the
algorithms are independent, and B) that the algorithms in use do not
substantially reduce their input entropy, both of which are potential attacks.

It does _NOT_, however, assume that the scheme be kept secret.

------
al_james
Here's a (potentially stupid) idea:

The app provides a fixed 'secret key' that defines (somehow) a sequence of
hashing and scrambling functions to apply to the password. So, for example,
the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3
iterations of md5 hash followed by rotate hash 5 places to the left followed
by 2 iterations of bcypt etc..'.

So, in effect, each app (with a different secret key) will have a different
hashing process, but with the advantages that its repeatable and cross
platform (reference implementations could be available in the major
languages).

Of course, if your secret key is hacked you are in trouble, but at that point
the hacker can probably get your source code for whatever hash system you use,
and anyway, the combined hashing process is probably slow enough to prevent
brute force attack.

Any thoughts?

Edit: Probably better to just use bcrypt with a larger work factor.

~~~
cheald
Why is this any more secure than keeping a salt in your code?

bcrypt(password + hardcoded application salt + db-stored user salt) is far
less complex and arguably just as secure, since your argument is predicated on
"assume the source code is safe". bcrypt is tunable to be as slow as you want,
even to account for hardware progress.

~~~
al_james
>bcrypt is tunable to be as slow as you want, even to account for hardware
progress.

I did not know that. Can you expand on this point?

~~~
cheald
Part of the bcrypt process includes a "work factor", which is, crudely, "how
many times do I run this?" What you can do is tune your work factor so that it
takes a reasonably long time to hash a password (say, 0.05 sec on your
webserver = 20 passwords/sec), which won't necessarily heavily impact the
performance of your website, but which would be a significant impediment to
anyone trying to brute-force those passwords.

As hardware improves, you just implement a system wherein when the user
submits login information, you verify their password with your old work
factor, and if it passes, re-hash with your new (slower) work factor and store
the updated hash. This allows you to effectively use a progressively slower
algorithm over the lifetime of your application to compensate for Moore's Law.

You obviously don't want to pick a work factor that's too high for your web
server hardware, since that opens you up to DOS attacks, but a reasonable work
factor can easily mitigate the weaknesses of MD5 and SHA1 - notably, that they
can be computed by the hundreds of millions of second on the right harware.

~~~
al_james
Ok, got it. Thanks. Yes, much better. I was under the impression bcrypt was
also a fixed cost operation.

If anyone else is wondering how to implement bcrypt with a cost parameter in
PHP, see <http://php.net/manual/en/function.crypt.php> under CRYPT_BLOWFISH.

~~~
estel
It's probably prudent for most developers to instead use phpass [0] rather
than attempt to roll their own implementation.

[0] <http://www.openwall.com/phpass/>

------
koide
Excellent idea, a hash scheme per site. A multi language framework to help you
build your own scheme, one which can be validated by many cryptography-
knowledgeable eyes, would improve the chances of this actually happening some
day.

It's a pity that seemingly trivial changes on an crypto algorithm can totally
obliterate its security.

------
ars
BTW COTS means Commercial off-the-shelf. (I've always known that abbreviation
as just OTS, and was trying to figure out if the C stood for "Custom".)

~~~
acheron
I've never seen just OTS, but then I work in an area where it is necessary to
distinguish COTS from GOTS ("government..."). If you have no reason to
encounter government software, then I suppose there's no reason to specify
that you mean commercial.

------
phkamp
Yes, of course. I have clarified the text now on this point.

~~~
ars
What is this a reply to?

~~~
gibybo
He was replying to <http://news.ycombinator.com/item?id=4078418>

------
stcredzero
For server-side, how about password DB implemented as hardened information
appliances? This would make the acquisition of the password database harder.
White-box techniques could be used to hide a modified salting technique,
making cracking much more labor intensive. Such a service could be offered by
cloud and virtual server providers, perhaps for a small additional fee. (Which
would still be almost all profit.)

------
KhalidAbuhakmeh
It's very telling that hardware is outpacing our own cryptographic techniques.
I remember reading an article that stated that all passwords will someday be
crackable due the advances in Quantum computing.

By that time we'll all know that your password is "I Love Care Bears 123" :P

~~~
cheald
Hardware is not outpacing our cryptographic techniques. Go spin up an AWS GPU
cluster to break an AES-256-encrypted file and let me know what the bill runs
you.

md5crypt is a "poor man's" crypto system, simply because it's built on MD5,
which is intended to verify data integrity more than it is designed to hide
information. We've known that md5 was broken since 2004, so at this point,
anyone actually using MD5-based systems for password hiding really has no
excuse.

Quantum computing is a whole 'nother ballgame, and while it does offer the
promise of making current encryption schemes more or less obsolete, it's an
entirely different ballgame than "chain together a few Radeon cards and crack
a DB full of MD5 hashes".

------
5549900
The way forward for nontechnical users seems clear: avoid giving websites
sensitive information and letting them store it for you. How long before
Facebook is hacked?

Keep sensitive information on your own storage media, not on some website's
servers connected to the internet.

------
snow_mac
How about this for security MD5(SaltFromDB + Password +
ApplicationConstantSalt)? How would that be affected by something like this?
Given the user you'd their salt, their paassword but not the application salt.
Still really insecure?

------
al_james
Just found this if any PHP developers wants an easy to use bcrypt password
library. <https://gist.github.com/1053158>

------
jonaphin
Not exactly an expert on cryptography, but how different is the description of
the "next" crypto-algorithm provided by Kemp different from what bcrypt can do
today?

------
reitzensteinm
That this is upvoted to #1, in 2012, on a site called Hacker News, is probably
more notable than the article itself.

~~~
16s
Inertia. The fact that it works and has been tested extensively in production
means more to many managers than security does.

(pause for collective gasp from the nerds)

Until it becomes a crime of some sort to use these simple, well-tested hashes
to store passwords and the world police begin locking-up CIOs because of it,
then don't expect anything to change.

~~~
reitzensteinm
You're responding to an argument I never made. I'm not surprised MD5 is used
in the wild, nor confused about the reasons why. And hell, it's a step up from
plain text, which is probably even more common.

I'm just surprised to read about its deficiencies on Hacker News _as if it
were news_.

------
hodgesmr
Um. Haven't we known not to use MD5 for years now?

~~~
phkamp
MD5 is not vulnerable as used in md5crypt.

------
yashchandra
In my very first internship/job, I implemented user management in ASP and
Access database in backend. I chose MD5 for password hashing and I was so
proud of myself. Of course this was about 10 years ago. :)

