Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

queue.acm.org

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#21

Post by chris_j »

SagelyGuru wrote: post #16

It is all very well suggesting running the hash millions of times but sites with many users might not want such performance hit. This kind of escalating competition based purely on computing power indicates to me that the very concept of passwords has probably had its day and we should seriously think of better alternatives. Passwords are no fun to remember and to keep secure for the users either. Anyone with a reaso…

In order to reduce the computational overhead on the server, perhaps one option is to run (at least part of) the hash on the client (eg in Javascript). Does anyone have any idea of how that would perform and if it would be feasible?

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#23

Post by rlpb »

davidjohnstone wrote: post #15
gizzlon wrote: post #10

Earlier quoted context omitted.

This is a bad idea, and here's why: Honestly, I see it as almost self-evident that user would never ever learn this. But more importantly, what would stop anyone from putting up these icons? Who would check that they actually implemented it? Even if that was solved, people would just implement this one thing because it looked good. But there are plenty of other ways to ruin your password security, so you couldn't rea…

Yes, most users wouldn't understand what this is. However, if some did, and they expected it to be there, that might be enough. You're quite right that there'd be nothing stopping people from using this dishonestly, except their consciences and the fact they may have some explaining to do if a dump of MD5s of their passwords was released. That may or may not be enough. In any case, I'm sure that this industry can do…

The problem is that the people who don't use a KDF don't know any better. Aren't these the same sort of people who will implement the same logo as other sites use without understanding what it means?

> except their consciences

I would add ignorance to that list.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#24

Post by tosh »

ludwigvan wrote: post #17

In last.fm's defense, they argued that there were some hardware devices (radios) that had last.fm clients, so they couldn't update their password system. I have a question though, how would a strong password that takes around 1 second to hash affect the scalability of these systems; would it impact the login times of users a lot? Imagine thousands of people trying to login at once. Might it be the reason linkedin did…

They still could've STORED them in a different way in the backend (e.g. use the md5 hash as 'password' and then use pbkdf2) then the leak would not have been as much of a problem as it was.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#25

Post by darklajid »

chris_j wrote: post #21
SagelyGuru wrote: post #16

It is all very well suggesting running the hash millions of times but sites with many users might not want such performance hit. This kind of escalating competition based purely on computing power indicates to me that the very concept of passwords has probably had its day and we should seriously think of better alternatives. Passwords are no fun to remember and to keep secure for the users either. Anyone with a reaso…

In order to reduce the computational overhead on the server, perhaps one option is to run (at least part of) the hash on the client (eg in Javascript). Does anyone have any idea of how that would perform and if it would be feasible?

In that case you just change the password. It's now whatever the client (pre)computes, the user input is just used to derive the 'real password'.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#26

Post by capsule_toy »

mquander wrote: post #5
drostie wrote: post #2

Dear tech journalists, please stop saying stuff like "But we have yet to find out why nobody objected to them protecting 150+ million user passwords with 1970s methods." We do know why people use SHA1(unsalted password), and it's because the dev stack still doesn't support something like SHA-256 or better yet bcrypt/PBKDF2 at all levels. So, right, I was a web developer pushing my PHP-based company to have a more rob…

I just googled "PBKDF2 PHP" and the first page was full of free implementations. But maybe it's cheating, since I know what "PBKDF2" is. I tried to simulate what a totally ignorant person would do, and googled "PHP password." The second result was the PHP manual page on passwords, where it explains in eleven different languages, using simple words, exactly what the deal is with password hashing, and refers people to…

LinkedIn was launched, in what, 2003? If you googled the general advice back then, it was pretty much just use MD5 or, if you were really cutting edge, SHA1. Salting wasn't common at all. Salting eventually started becoming common and now you're silly if you don't use bcrypt.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#27

Post by rfergie »

yuvadam wrote: post #14
jules wrote: post #11

One thing that I always wondered about this approach: for (i = 0; i Aren't we weakening the hash function? Presumably the hash function is not one-to-one, so if you iterate this for many iterations there is a danger that you could end up with a function that has a much higher probability of collisions?

Why would you assume that? Persumably there should be no real reason why HASH(8_char_password) = 160_bit_hash should be less strong than HASH(160_bit_hash). Not only that, but most hashing algorithms already do several iterations before returning the hash.

I think the concern is that the hash function may converge.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#28

Post by tomerv »

darklajid wrote: post #25
chris_j wrote: post #21

Earlier quoted context omitted.

In order to reduce the computational overhead on the server, perhaps one option is to run (at least part of) the hash on the client (eg in Javascript). Does anyone have any idea of how that would perform and if it would be feasible?

In that case you just change the password. It's now whatever the client (pre)computes, the user input is just used to derive the 'real password'.

That's not entirely correct. The scheme that chris_j proposed can help prevent weak passwords from being cracked, since now an attacker needs to do one of two things to crack passwords: 1. Try lots of weak password - hash each one and compare to the list. This is slow, because the hash is slow. 2. Try breaking passwords with the partial hash - in this case the attacker either needs to try very difficult passwords (since these are passwords after a partial hash - what you called the 'real password'), or get the partial hashes from the users, which requires more effort.

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#29

Post by dchest »

jules wrote: post #11

One thing that I always wondered about this approach: for (i = 0; i Aren't we weakening the hash function? Presumably the hash function is not one-to-one, so if you iterate this for many iterations there is a danger that you could end up with a function that has a much higher probability of collisions?

There can be entropy loss.

1. http://crypto.stackexchange.com/questions/135/why-does-pbkdf...

2. http://news.ycombinator.com/item?id=2005929

Re: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#30

Post by phkamp »

capsule_toy wrote: post #26
mquander wrote: post #5

Earlier quoted context omitted.

I just googled "PBKDF2 PHP" and the first page was full of free implementations. But maybe it's cheating, since I know what "PBKDF2" is. I tried to simulate what a totally ignorant person would do, and googled "PHP password." The second result was the PHP manual page on passwords, where it explains in eleven different languages, using simple words, exactly what the deal is with password hashing, and refers people to…

LinkedIn was launched, in what, 2003? If you googled the general advice back then, it was pretty much just use MD5 or, if you were really cutting edge, SHA1. Salting wasn't common at all. Salting eventually started becoming common and now you're silly if you don't use bcrypt.

This is more a reflection on where you got your advise in 2003, than what was considered best-practice.

Salting became best-practice in the 1980ies, but the "lost generation" of dot-com wizards never bothered reading "all that old stuff", so they are doomed to repeat the mistakes.

Post reply on HN