how about a car sales analogy instead?

Its like GM opening up a dealership to compete with a franchisee down the street. This is prohibited by law.

If the target audience of your browser is a half step or less from computer illiterate, you need to take steps to protect them from themselves. This means that the others will have to find another toy to play with because google has decided that the more literate crowd is not as valuable as customers or feels that they will just adapt, complain and move along because they have little other choice.

I am sorry, but you should be arrested for what you have posted. And don't try to hide behind the first ammendment - your post isn't speech its an act of incitement of the public like yelling fire in a theater. You are engaging the public to fight the government and should be brought to justice.

hmm... I was going to post the above as is, but now I'm afraid someone will believe me... or worse yet believe the statement... Thank you /. preview for allowing me to put in this disclaimer - I do not believe in or stand by the above comments.

Where are the mod points when needed...

I must say that I have resisted new input devices for a long time - the mouse, touch screens, track pads.... virtual keyboards and found that each had its place, but none of them really took the place of the keyboard for data entry. I still prefer a full sized keyboard to type and a mini keyboard on a handheld device. They speed cannot be matched. Having a hybrid data-entry model with predictive text options, isn't a bad thing. The loss of a great technology such as a physical keyboard is - at least until virtual keyboards have a 3D with tactile element... more like holodeck than hologram.

I agree that there is no excuse not to use bcrypt.

You can do basically attempt all 8 character passwords in a few minutes per user on modern hardware (the salt adds 0 computation complexity, but as you say, it forces you to actually have to do the calculation instead of doing a lookup).

Also, the whole point is that key derivation is slow. Of course the "secret from which keys are derived" is available (it is necessarily so; it's stored, along with the cost factor, as part of bcrypt's output, for example). But the fact that you have to through 2^N iterations, where N is usually >= 10, throws a meaningful speedbump in front of high-speed cracking. Now instead of brute forcing any given 7-character alphanumeric case-sensitive passwords in ~half an hour, it'll take you > 20 days on average.

This is completely orthogonal to the fact that salted hashed passwords have never been an appropriate means to store a password. http://codahale.com/how-to-safely-store-a-password/

The key derivation functions can be literally several orders of magnitude harder to brute force. And their difficulty can be chosen with simple parameters, with sane defaults. There is really no comparison between a singly salted hashed password and bcrypt/scrypt.

Check out table 1 in this paper to get a sense: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.tarsnap.com%2Fscrypt%2Fscrypt.pdf

Assuming the cracker has access to the salt and a GPU, the only thing keeping users safe now is the entropy inherent in the passwords they chose.

It doesn't have to be like that. Instead of plugging in Good Salted Hashed Password Library, you can plug in Bcrypt Library or Scrypt Library *and protect even the users who chose bad passwords*.

The size of the salt is relevant only insofar as you want to be sure that each user has their own unique salt. The salt is stored in plaintext (or, I suppose, it could be encrypted, but then the decryption key must then be stored in an accessible place). The point is that the crackers must be assumed to have recovered the salts.

So now those salts protect you against pre-computed hashes. The cracker has to attempt each password individually. But most people use one of the few thousand most common passwords. And inexpensive modern hardware lets you attempt billions of SHA hashes per second. So... Salted and hashed does very little for you at this point.

Instead of salting and hashing, use a key derivation function (e.g., bcrypt, scrypt).

And yet, with no extra effort on Living Social's part -- simply by choosing a bcrypt library instead of a custom hash/salt scheme -- even a user with a weak password would be protected.

So, sure, I might agree with you, but that doesn't absolve Living Social.

Why is it "fortunate" that the passwords were hashed and salted? Unless they've used key derivation functions (e.g., bcrypt, scrypt) and are actually under-selling their sophistication, this seems Very Bad for their customers.

Point taken.

IANAL but I don't think you are allowed to blackmail someone into signing a NDA. If they believed that a crime was committed, they are obliged to report it. By saying they will let you sign the agreement to get out of it, they are blackmailing you. If you discover that someone committed murder and state you will not report it if they do X - you have now committed a crime of your own.

Not the best source for legal advice, but http://www.ehow.com/info_8335199_legal-obligations-report-crime.html seems to cover this topic.

Or don't hide the audio recorder. Put it on the table and turn it on, ask them to repeat what they say.