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

31–40 of 62 posts

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

#31

Post by dchest »

phkamp wrote: post #12
Argorak wrote: post #8

Earlier quoted context omitted.

> So suppose you are developing an agile product, someone loses access to their account and asks for a new password, you type `head -c 9 /dev/urandom | base64`....`UPDATE users` I don't think I ever want to be _that_ agile. My agile projects usually have a set of application functions exposed as scripts immediately. And yes, proper password change is one of them. (besides, how about just using `pwgen 16` and not some…

... and since you are not danish, you don't realize that base64 emits the danish word "badeanstalts" and therefore fall to even the most trivial dictionary attack.

9 random bytes encoded to 12 base64 bytes is still 2^72 bits of random data. You'll be hit by a meteorite much sooner than you randomly generate "badeanstalts".

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

#32

Post by sparre »

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? (I assume that there must be some, since I haven't ever heard of anybody handling passwords this way.)

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

#33

Post by Daniel_Newby »

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-style password encryption, such leaks are a nuisance and embarrassment.

If you do not have password encryption, the leak recipient can easily impersonate any and all users. They can control your system, create false communication, cause industrial equipment to destroy itself, send harassing messages, conduct financial fraud, and so forth.

The cost to use password encryption is a little engineering labor, the return on investment is a substantial reduction in risk.

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

#34

Post by Jebus »

tomerv wrote: post #28
darklajid wrote: post #25

Earlier quoted context omitted.

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

Lol who cares. Linkedin doesn't even use SSL. But yes, for other sites it is a good idea.

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

#35

Post by nitrogen »

tomerv wrote: post #28
darklajid wrote: post #25

Earlier quoted context omitted.

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

Not quite; attackers aren't restricted to using a web interface, so they just send the partial hash directly to the remote site. As far as an MD5 brute force attack is concerned, "very difficult" is exactly as hard as a user-entered password. Keep in mind the purpose of hashing is to mitigate the damage caused by database leaks. Granted, an initial client side hash adds one more step the attacker must take to gain a password that's usable on other sites, but that doesn't protect the original site, unless implemented correctly will be crackable with effectively zero effort, and is unlikely to be implemented correctly.

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

#36

Post by Jebus »

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…

It doesn't have to be 1 second. Just use something that was designed to store passwords, so it at least it isn't blazing fast, and it gives semantic security, like bcrypt does (you don't even need to think about salts). Also, having a configurable amount of rounds gives some degree of security through obscurity, so the attacker also needs access to the code, or lose time figuring the correct amount of rounds. I think most attackers would just desist.

Sha-X, md5, etc, where designed to be fast. You don't want slow checksums.

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

#37

Post by mkup »

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…

Why don't you write small program in C and call it as external process from your PHP code to perform resource-intensive computations? Database should have nothing to do at all with user password hashes.

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

#38

Post by mikeash »

gizzlon wrote: post #10
davidjohnstone wrote: post #9

Would it be possible to come up with a simple little icon that can be put on sign-up pages to indicate that the service is using PBKDF2 or bcrypt of the like? Then, it would need to become popular enough for users to start to recognise it and look out for it when signing up. Even if most users don't have any idea what it's about, plenty of the more technically inclined users would, and they tend to be the early adopt…

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…

I think you could implement verification of the implementation by allowing a user to retrieve their own password hash. Most would have no idea what to do with it, but a few people who know what's what could use that to verify that they're using the algorithm.

This does not detract from the rest of what you said, of course, and I agree that this wouldn't really be useful.

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

#39

Post by darklajid »

tomerv wrote: post #28
darklajid wrote: post #25

Earlier quoted context omitted.

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 (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: Poul-Henning Kamp: LinkedIn Password Leak? Salt Their Hide

#40

Post by jcromartie »

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…

You can integrate common passwords into your password choice UI.

These guys did a nice example: http://howsecureismypassword.net/

Lists are available from various sources. Here's a good page http://www.skullsecurity.org/wiki/index.php/Passwords

Post reply on HN