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

41–50 of 62 posts

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

#41

Post by tptacek »

dchest wrote: post #29
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

... in a theoretical sense; it is comically unlikely to be a real-world concern.

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

#42

Post by jcromartie »

sparre wrote: post #32

Is there a reason that one doesn't use a public-key encryption function with a unique, random public key per password to store the scrambled passwords? One would then store the public key and the encrypted password as md5crypt stores the salt and the hashed password. This is of course not run-time configurable to increase the computational complexity of the password scrambling, but besides that, what are the problems…

Does this imply the client doing the encryption? I.e. the client creates a key pair and sends the public key to the server?

It sounds good but the challenge, as always, is the infrastructure. I think it would be great if I had a single personal private key from which I could issue chained keys for each domain where I have an account. But imagine managing this across desktops, browsers, phones, game systems, etc. ...

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

#43

Post by Robin_Message »

darklajid wrote: post #39
tomerv wrote: post #28

Earlier quoted context omitted.

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 (si…

I might totally be wrong, but for me the consequence of that approach are: 1. The attacker doesn't need the text the user entered anymore, just the precomputed hash 2. Probably the length and alphabet is fixed now, which might obfuscate/protect 'password' or 'test', but reduces the value of a strong password. Granted, this last part is a gut feeling.

Re the gut feeling – this is only a problem if the password has significantly more entropy than the hash. So, worst case MD5 (128 bits), this is potentially bad for people with printable ASCII (97 chars) longer than 19 characters.

But it's still not a real problem since 128 bits of entropy is unguessable in the lifetime of the universe (checking 2^64 hashes a second, which is obscenely many – perhaps every processor on the planet dedicated to the task would be enough – covers 5% of the search space in 34 billion years.)

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

#44

Post by eli »

ragmondo wrote: post #22

Why can't I be allowed to choose the authentication method I use to access MY data (and be responsible for the consequences if mis-used). Is my data in linkedin really my data after all?

It wasn't the method of authentication that was the problem, it was that the stored credentials were inadequately protected against brute force attacks.

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

#46

Post by sparre »

jcromartie wrote: post #42
sparre wrote: post #32

Is there a reason that one doesn't use a public-key encryption function with a unique, random public key per password to store the scrambled passwords? One would then store the public key and the encrypted password as md5crypt stores the salt and the hashed password. This is of course not run-time configurable to increase the computational complexity of the password scrambling, but besides that, what are the problems…

Does this imply the client doing the encryption? I.e. the client creates a key pair and sends the public key to the server? It sounds good but the challenge, as always, is the infrastructure. I think it would be great if I had a single personal private key from which I could issue chained keys for each domain where I have an account. But imagine managing this across desktops, browsers, phones, game systems, etc. ...

My intent was that the server should still be responsible for scrambling the password as usual. - My question is only about changing the algorithm server-side.

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

#47

Post by romaniv »

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?

Looking at downvotes on the parent post. I am bothered by the fact that participants of similar security discussion so easily downvote or lash out against any questions or ideas that diverge from their favorite mainstream. Seems like a common trend even outside of HN.

It's a perfectly valid post. No one says "use this, this is awesome and secure". If you think the idea is bad, then answer with an explanation. The -1 is simply not useful here. (Neither are one-liners that boil down to -1.)

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

#48

Post by Estragon »

Daniel_Newby wrote: post #33
dredmorbius wrote: post #19

I had a long discussion with a my colleague Commander Adams today about improving password management policies for Krell Power Systems client logins. This is a change that would have to be added to the current project backlog, specified and designed, developed, and implemented. Selling this means making a compelling case that salting and changing our hashes would actually solve a problem for us and our clients. My se…

"What does salting and bcrypting buy in way of protection?" Information leaks are common: a backup tape gets FedExed to the wrong address, file sharing gets accidentally turned on, a Russian hacker finds a security hole in your machine while scanning millions of machines, some idiot puts the password database on a laptop and loses it. These sorts of problems are constantly making the headlines. If you have bcrypt-sty…

The trouble with defense in depth is that you have to admit your existing defenses may be inadequate. I can see how that could be politically difficult in a large organization.

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

#49

Post by recursive »

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.

The space of the output of the hash as at most as big as the space of the input.
Post reply on HN