51–60 of 62 posts
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?
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…
Poul-Henning Kamp is many things, but journalist? He is allowed to say stuff like "But we have yet to find out why nobody objected to them protecting 150+ million user passwords with 1970s methods." And this is Linkedin. They should know and do better. I actually imagine that their very gifted developers are running around wondering how they themselves didn't audit this.
You can only imagine how many times someone noticed that passwords weren't salted (by comparing stored passwords to a leaked set of hashes or raibow tables after another announcement from some company being hakced) and complained, and got brushed off.
2. Any advice on encrypting passwords? We store passwords for some 3rd party services for our users.
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…
Our backups management is pretty solid, with backups encrypted, and even DB systems using on-disk at-rest encryption via an ecryptfs tool.
You did raise the valid point of sensitivity of identity data among some of our clients. While the general case is that PII (personally identifying information) disclosures would largely be embarrassing but not harmful, there are cases in which harm, or even life-threatening risks could arise.
I'm leaning to your conclusion but I'm looking to be able to quantify that more robustly.
And as I noted in my original question: if we were getting pressure from our clients on this, the case would be far easier to make. Market rules.
A full second? Facebook has 900,000,000 active users. They would need over 10,000 CPUs running for 24 hours just to log them in.
..amortized over several weeks. People don't log in every day.
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 can see why people don't use bcrypt/PBKDF2: they don't know or it's not a priority. Your reason, however, doesn't strike me as a particularly good one: you could just write a quick password reset tool in PHP or even better write a quick shell script that splits out the password reset query. And I think LinkedIn really has no excuse.
It turns out that this is a bit complicated, as my colleagues readily pointed out to me. So for example you are basically saying "write a .PHP file and execute it locally," which is perfectly fine, as long as the problem comes from your boss or one of your testers -- it is risky when it occurs on a production server (because the script you're generating is insecure). On your production server you really do want to execute the action from within a MySQL prompt if it's possible, and so it's a sort of two-sided game of "I'm going to reset my password over here and then update their (salt, password) with the result of my local PHP queries," and that's a bit weird as a process.
The other tender point is that once you've made a choice, it's very hard to change it. So, "all of our existing passwords use the old system, we're not changing!" was a very strong argument and I did have to spend a bunch of time creating a fall-back for legacy passwords.
I would agree, however with this: in general there is a reasonable expectation of, "if we're doing this so much that it bogs us down, then the app is mature enough for a proper email-sending password-reset tool; and as long as it doesn't bog us down we'll do it the hard way." But convincing people to make the hard way even harder is a tricky proposal even on a good day. It's like telling people, "no, leave that code, I know it does 2^n operations but n is always small and it's not actually the part that slows down our system and it's more readable this way." The intangible -- security/readability -- is being negotiated for the tangible -- dev-ease/speed. I had trouble selling it to the other devs.
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?
Earlier quoted context omitted.
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…
Is the first case (judging normal passwords) factoring in that a password varies in length? I mean, stupid thought again: You need to test all one character passwords, all two character password, a hash is fixed in its length?
And I wouldn't want to find the original input, I'd want to get in. For that my totally fallible gut says that I'd need to create a 'word list' of hexadecimal character permutations of length x. Is this really an impossible task?
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.
Earlier quoted context omitted.
"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.
One is the perceived fear of looking incompetent in front of your users/clients. For which I feel the appropriate response is "we'll look a lot more competent if we mitigate the risks of such an event than if we don't, regardless of whether or not it happens".
But really, the big one is simply: can you justify the engineering/product cost of this change on the basis of a material business benefit to us and our clients?