AdultFriendFinder was hacked

https://www.ft.com/content/33503e4a-8f95-11e6-a72e-b428cb934...

  Chase's online banking login is case insensitive ...

e: There is a pretty good discussion of this here https://www.reddit.com/r/personalfinance/comments/2m81uj/tip...

It's also not unheard of for them to strip all non alphanumeric characters so P@ssw0rd2016! is normalized to pssw0rd2016

On the other hand, they are probably far more alert to detecting and stopping bruteforcing attempts.

It's a similar situation with certain 4-digit PINs for smartcards; that may seem trivial to bruteforce, but you only get 3-5 tries before the system considers you to be attacking it and permanently locks you out even if you try to enter the correct one afterwards.

Here's one idea: Let's say the user's password is P. The user enters some password P' with a typo. The authentication check is "does H(T_k(P')) == H(P)" for some set of transformations {T_1, T_2, ..., T_n}. Each transformation T_i hypothesizes that the user made a specific mistake. (e.g., T_1 is the caps lock is on so we need to flip the case of all the characters)

My name in Greek has a letter with a double accent. Perfectly valid of course. But many (Greek) sites will reply that this NOT a Greek letter :)

The uppercase being indifferent is a first for me but I've had those people tell me that performing copy paste into the password input somehow changed the authentication procedure. He again acted as if I was a complete idiot for suggesting that that made no sense.

Related, the "3d secure" credit card verification system asks for individual chars of a password (at least in the UK).

> "the hashed passwords seem to have been changed to all lowercase before storage"

This effectively makes your password case insensitive and probably reduces the % of support tickets (some people might not just click a reset password link and will insist they were typing it right, so they will open a ticket - all because they forgot capslock). It reduces operating costs at the expense of lower security and somebody must have considered it to be worth it.

Would you expand on this?

You should generate UUIDs, bucket by the first few chars, and use a database to map from UUID to human-readable name.

Some convenience trade offs? You're suggesting that people don't use any modern bank, don't use any hospital, don't interact with any state body at all. Should we go live in a cabin in the woods?

And I think it's right. None of the large OS are fit for purpose. And it's about time that regulators start protecting unsuspecting consumers from unscrupulous incompetent fly-by-night developpers like the ones behind this website.

But is it productive for us to declare everything unsafe and somewhat give up believing we can build and use safe platforms?

I think there's a balance somewhere. I (to give a rather crude example, apologies) would never take a nude photograph of my partner on a digital camera because it's an unacceptable risk. But I'll share fairly personal thoughts knowing that they may come back to embarass me one day.

I want to put the pressure on companies who make such bold claims about their "military grade encryption" to face bankruptcy and shame when it's proven they're full of lies and negligence; if we just assume everything can be attacked with an LFI, it seems we've stopped caring about trying.

Caveat: I still haven't had breakfast, I don't have my best thinking cap on right now, but that's my gut instinct.

I don't know how you would tell the difference in that case so I assume yes.

The way I implement this is I bought an entire domain for spam. I created a catchall account and when I sign up for services I can just punch in hackernews@spam.com for example. All of this filters into a single email account allowing me to retrieve all my password resets and account confirmations.

This will weird out some people over the phone:

"Yes, it's comcast@spam.com"

"Sir, to look up your account I need YOUR email address"

[0] https://www.fastmail.com/help/receive/addressing.html

Note that of course the password algorithms are typed, so this doesn't cause a problem in the corner case that a user's password is a sha1 hash of something else.

[0] - https://docs.djangoproject.com/en/dev/topics/auth/passwords/...

Let's assume you want to store a password. The first, obvious step, is to store it in plain text. This is obviously brain dead, but well, we live in the world we live in.

    $user_pw = $password;

    $user_pw = hash($password);

The next obvious step is to salt the password. Salting means that you add a random piece of information to what you hash, in order to disable the use of rainbow tables. Every password has to be cracked individually. The salt needs to be included in the stored form of the hash, because otherwise you can't calculate incoming authentication requests against it.

    $user_pw = concat($salt, ':', hash(concat($salt, password)));

The problem is that now, you have the salt always stored with the password. This means that if your database gets stolen/dumped, an attacker has all the information required to crack specific hashes.

In order to alleviate this, you can use a pepper, which is similar to a salt, except that it is global and unique to your application, and doesn't change all the time. It is a static piece of data that gets hashed as well, but isn't stored alongside the hashes in the database.

    $user_pw = concat($salt, ':', hash(concat($salt, $PEPPER, password)));

The passwords in the dataset will neatly divide into "trivial" and "intractable".

A single password with 80 bits of entropy (16 characters, random lowercase/numbers) will take more time to crack than 1,000,000,000 strong human-chosen passwords under 40 bits.

Most of the passwords will be so weak that it might not be worth doing the sorting and preprocessing needed for the parallel attack on multiple passwords with the same salt.

Once you're using just plain hashing you've already lost and instead of using ad-hoc salting schemes you should be using a proper PBKDF (PBKDF2, bcrypt, whatever)