Live data from Hacker News

Md5crypt is no longer strong enough

phk.freebsd.dk

21–30 of 144 posts

Re: Md5crypt is no longer strong enough

#21
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#...

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.

Re: Md5crypt is no longer strong enough

#22
post #8

Earlier quoted context omitted.

Also, if that's what should be encouraged, someone might as well put together a simple framework for automating it. Basically, you hard code a list of salts and a list of hash function names (which could also be automatically generated by a tool), and it gives you a new hash function which is the composition of those other functions. There's no reason for everyone to try to do it by hand and risk messing it up in som…

Such a toolkit would probably be a good idea. Tie a card-carrying cryptographer to a chair until he delivers it ?

>Tie a card-carrying cryptographer to a chair until he delivers it ?

Alternatively, implement it very, very simply and put it on github, and ask card-carrying cryptographers to vet it. That one is harder on the ego though.

Re: Md5crypt is no longer strong enough

#23
post #21

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#... 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?…

There is no mention in the article of secret algorithms.

Re: Md5crypt is no longer strong enough

#25
post #21

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#... 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?…

There is no mention in the article of secret algorithms.

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

Re: Md5crypt is no longer strong enough

#26
post #13

Earlier quoted context omitted.

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…

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 } }

You mean you're sending unhashed passwords from the client?

Re: Md5crypt is no longer strong enough

#27
post #19

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

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.

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.

Re: Md5crypt is no longer strong enough

#28
post #26

Earlier quoted context omitted.

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 } }

You mean you're sending unhashed passwords from the client?

Yes. That is the standard behaviour that nearly all sites use, and is perfectly fine.

Re: Md5crypt is no longer strong enough

#29
post #26

Earlier quoted context omitted.

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 } }

You mean you're sending unhashed passwords from the client?

How many web login forms (as an example) are doing client side hashing? The only ones I know are of the recent 'test your password in the linkedin leak' variety.

How do you degrade for NoScript users?

And where's the harm in that anyway (assuming TLS)?

Re: Md5crypt is no longer strong enough

#30
post #17

Earlier quoted context omitted.

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 } }

But if you have code to run the old style hash you don't need the new one. (Although it's useful to upgrade the work factor.) The issue is you don't always have the ability to do the old style, that's why people prefer a hash that they can be assured will be found everywhere.

[deleted]
Post reply on HN