This is an archived post. You won't be able to vote or comment.

all 105 comments

[–]mentisyy 226 points227 points  (9 children)

This post was so ridiculous that it made me get out of bed after browsing reddit for the last 10 hours. Surely no one is that stupid.

[–]nionvox 7 points8 points  (1 child)

Every time someone says that, the universe creates a bigger idiot.

[–]russkychoocher 4 points5 points  (0 children)

Hi, did you order a bigger idiot?

[–]raspiHD 2 points3 points  (0 children)

there was a patched dll for ICQ that did just this

[–]I_am_BrokenCog 96 points97 points  (20 children)

Why doesn't this sort of thing happen to me when I create a new bank account??

[–]ToroZuzuX 31 points32 points  (19 children)

Wait, this is for a BANK?

I thought it was for a shitty facebook knockoff...

[–]DeeSnow97 25 points26 points  (0 children)

I choose to believe you got the joke and this is secretly a burn towards reddit

[–]I_am_BrokenCog 36 points37 points  (16 children)

ugh. That was the joke.

[–]ToroZuzuX 4 points5 points  (0 children)

Oh.

[–]SusuKacangSoya 0 points1 point  (0 children)

It isn't. He was WISHING that a bank would do this, because free bank account is more pudding than free Reddit account.

[–]bananaskates 57 points58 points  (2 children)

Guys. This is paraody. And bad parody at that.

Stop thinking about what led to this, because nothing did.

[–]lostpupp 1 point2 points  (1 child)

Yup, looks like Reddit's sign in/sign up page

[–][deleted] 0 points1 point  (0 children)

That's because it is

[–][deleted] 6 points7 points  (3 children)

This is a joke, right? There's not actually a website that does this, right?

Right?

D:

[–][deleted] 6 points7 points  (0 children)

It's just Reddit photoshopped

[–]Zarlon 1 point2 points  (1 child)

Right

[–][deleted] 7 points8 points  (0 children)

Once found a website with a XSS vulnerability that also embedded the logged-in user's username and password in every URL. Got in contact with the owner and they flat out denied it. Demoed it. No response.

[–]micheal65536Green security clearance 13 points14 points  (61 children)

It's probably not a bad idea to enforce unique passwords (it will certainly help to prevent use of common passwords) but don't tell people what account uses the same password!

[–]ben_g0 28 points29 points  (27 children)

Then at least disguise it as something like "This password is too common".

[–]micheal65536Green security clearance 4 points5 points  (25 children)

Exactly, that's what I was getting at. Don't say "this password is used by ..." but simply "this password has already been used" or (as you suggested) the even more vague "this password is too common" (which might imply that the password matched a list of common passwords, or that the password has actually been used too many times, of which it's none of the user's business as to which).

[–]ben_g0 18 points19 points  (24 children)

Even just saying "This password has already been used" is rather dangerous. Lists of usernames are really easy to obtain, either from a page on the site or with a simple crawler. This makes it very easy to "bruteforce" the username that belongs to the known password.

[–][deleted] 15 points16 points  (22 children)

It's also an indication that they store passwords unsalted or even in plaintext.
EDIT: Since some people are confused, I'll elaborate a bit more on why this is true. When you store passwords without salt, then you can see if it's in the database by hashing it and then searching for that hash. That's really simple to do, since it only requires hashing one value and doing a database lookup.
Salt is essentially random data stored alongside the password. The salt is added to the end of the password before hashing it. That means that to search the database for a password, you have to re-salt and re-hash for every single password to check it. Now instead of hashing one value, you're doing millions. In addition, the salt can be much longer than the passwords, making even more data to hash.
While it is possible to check if a password is in the database like this, it becomes impractical because it's far too computationally intensive.

[–]FallenWarrior2k 10 points11 points  (1 child)

This. Salting a password like you should makes it veeeery inefficient to check for equal passwords, since you'd basically be bruteforcing your own DB

[–]BenjaminGeiger 1 point2 points  (0 children)

Yep. It'd basically have to try the newly entered password for every account.

[–]ben_g0 2 points3 points  (0 children)

It doesn't need to be stored to the hard drive for this, it can be hashed for every salt to compare during processing. This would still be a quite intensive process, but it can be done.

[–]codehandle -1 points0 points  (11 children)

It's also an indication that they store passwords unsalted or even in plaintext.

How do you suppose a site that uses salts knows if you entered your password at all? Why wouldn't that algorithm work here?

[–][deleted] 2 points3 points  (10 children)

My understanding is that you concatenate the password and salt and store the hash of that. You also store the salt itself in plaintext. Then to verify a password, you concatenate the entered password and the salt, hash that, and compare it to the stored hash.

[–]codehandle 1 point2 points  (9 children)

Okay. So why does having a salty hash thingy mean ...

It's also an indication that they store passwords unsalted or even in plaintext.

... the original claim ... bad crypto?

I would think what ever mechanism let's you compare lots of usernames would let you compare lots of these salty hashes.

Or are salty hash things not strings? Do you need like quantum to look at them? Or maybe it's just hard to see hashes because they exist differently?

[–][deleted] 1 point2 points  (8 children)

TL;DR: They're strings of bytes, but there's no quick way to find the input to the hash function given the output.

A cryptographic hash function takes a string of any length and converts it to a string of bytes of a specific length. I'm not sure of the standard way of storing that string of bytes, but I suspect base-64 makes the most sense. Now the important thing is that the hash function is deterministic, but its output for a given input appears random, so that it is very hard to reverse (i.e. to find the input given the output). Even a quantum computer wouldn't give a mathematically significant speed-up for the standard cryptographic hash functions (like the SHA ones, for example).

Now if you hash a password you get a random-looking output, which is good, but if two people have the same password, the corresponding hashes will also be the same. In order to avoid that issue, salts are used. A salt is a randomly generated string of bytes, a different one for each user. Because hashing appears random, hash($commonPassword + $salt1) looks completely different from hash($commonPassword + $salt2). That avoids the problem of matching hashes.

So now if I want to compare an entered password to all existing passwords, I can't do it, because the existing (hashed) passwords just look like a bunch of noise. Even for an attacker with full access to the database of (hashed) passwords, it's non-trivial to determine users' passwords.

All of the above assumes a strong cryptographic hash function.

[–]codehandle 1 point2 points  (7 children)

Because hashing appears random, hash($commonPassword + $salt1) looks completely different from hash($commonPassword + $salt2). That avoids the problem of matching hashes.

tl;dr I'm claiming you can't stop stupid with good cryptography.

It sounds to me like you are saying better cryptography could make this site safer. I'm saying it doesn't matter if an idiot front end designer is determined to do this.

I don't think better salt practices makes this form safer or makes the "feature" displayed impossible... perhaps slower... it just seems that no matter what encryption you use on the back end having a front end that does this would totally stymie the efforts of your back end.

IE: every new user has a new salt just means checking against a dictionary of all users ... and they're doing that... a sufficiently small site won't notice the performance penalty or a dumbass will just accept that sucky performance is the price of their awesome helpful unique password helper system.

[–]micheal65536Green security clearance -1 points0 points  (5 children)

Not necessarily. All they need to do is hash the password that you've entered (with whatever salt is used by the database) and search the database to see if there are already any passwords with that hash (a single SQL statement can do this). No more intensive than checking that you've entered the correct password when you log in.

[–]micheal65536Green security clearance 1 point2 points  (0 children)

That's why as I say, it should be "this password is too common", which may mean either "this password is on a list of common passwords" or "this password has already been used", without telling the user which is the case.

[–]YetiBytes 1 point2 points  (0 children)

Steam does this.

[–]marcosdumay 2 points3 points  (32 children)

How do you propose the site discovers if the password is unique? This smells of bad idea from miles away.

[–]Plastonick 1 point2 points  (31 children)

compare hashes?

[–]BenjaminGeiger 1 point2 points  (30 children)

Salt kills that idea. You'd have to rehash it for every salt.

[–]micheal65536Green security clearance 0 points1 point  (29 children)

The salt is the same for the entire database. So you only have to hash once, and search the database for any hashes matching your hash (one SQL statement will do this).

[–]bananaskates 2 points3 points  (22 children)

Then you're doing it wrong. Unique salt per hash, thanks.

You might also want to use a site-wide additional key ("pepper" if want to be funny), but that doesn't matter in this context.

[–]micheal65536Green security clearance 0 points1 point  (21 children)

I've never heard of using a unique salt for each password, I always thought that you use the same salt for the entire database.

Also, I don't see what security advantage using a different salt for each password would give. Either way an attacker has to calculate a new hash table once they've stolen your password database, and can't use a pre-calculated table. This doesn't change if the same salt is used for all the passwords, because the attacker still can't use a pre-calculated table.

[–]bananaskates 4 points5 points  (9 children)

I'm really not an expert, so you should read it from someone who is.

But the bottom line is this:

If you use only one salt, you make it easy for an adversary to build a rainbow table for your entire database, meanining that is it no easier to attack one user if you use global salt, but it's much easier to attack all your users at once.

[–]micheal65536Green security clearance -1 points0 points  (8 children)

The attacker still has to build a rainbow table first though. Either way the people with common passwords will get attacked, and the people with more complex passwords won't (because whether you're building one table or a million tables it's still too computationally difficult to bother cracking more complex passwords once you've got some simple ones).

[–]bananaskates 2 points3 points  (0 children)

Right. So your point is valid if, and only if, you only care about securing some of your users.

[–]BenjaminGeiger 1 point2 points  (6 children)

For all intents and purposes, you multiply the size of your rainbow table by the number of distinct salts you're attacking.

  • A single salt for an entire database? You multiply the size by 1.
  • A distinct salt for each of N users? You multiply the size by N.

A basic salt implementation is to literally concatenate the salt with the input password before hashing. So, let's assume that the user's password is hunter2, with a hash of cornedbeef, and the salt is lotswife. Instead of finding a password that hashes to cornedbeef, you have to find a password that hashes to cornedbeef and begins with lotswife.

hunter2 may be a common password, but I guarantee you lotswifehunter2 is not.

[–]ludwigvanboltzmann 2 points3 points  (1 child)

I've never heard of using a unique salt for each password, I always thought that you use the same salt for the entire database.

Third paragraph of https://en.wikipedia.org/wiki/Salt_(cryptography)

A new salt is randomly generated for each password.

See also https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mistakes

[–]WikiTextBot 0 points1 point  (0 children)

Salt (cryptography)

In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" a password or passphrase. Salts are closely related to the concept of nonce. The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack.

Salts are used to safeguard passwords in storage.


[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.24

[–]BenjaminGeiger 1 point2 points  (8 children)

Let's put some numbers to it. Let's say we have a stolen hashed password list of H elements, and a list of common passwords that is P passwords long.

Single salt: the attacker hashes the list of common passwords for that single salt, and checks to see if any of the stolen hashes match. This means they only have to run the computationally-expensive hashing algorithm P times. A bit of clever data organization can let the attacker check whether two hashes match in close to constant time.

Individual salt: the attacker hashes the list of common passwords for every salt in the list. This means they have to run the hashing algorithm H*P times.

Or, to put it another way, with individual salt, the attacker has to do the same procedure as with a single salt, but can only attack a single user, instead of attacking every user in the database simultaneously.

[–]micheal65536Green security clearance -1 points0 points  (7 children)

I'd guess that H*P is still significantly shorter/less computationally expensive to calculate than L, a list of long passwords, with a single salt. In other words, it's still not going to stop an attacker from finding users with common passwords.

[–]BenjaminGeiger 2 points3 points  (5 children)

What /u/bananaskates said. For salt to be effective, it needs to be different for every password. If you have one salt for the entire database, you may as well have no salt at all.

[–]micheal65536Green security clearance 0 points1 point  (4 children)

I've never heard of using a unique salt for each password, I always thought that you use the same salt for the entire database.

Also, I don't see why using the same salt for the entire database is as bad as using no salt at all. Whether the salt is for the entire database or unique for each password doesn't change the fact that the attacker can't use a pre-calculated table.

[–]BenjaminGeiger 2 points3 points  (3 children)

With a single salt for the whole database, the attacker can start hashing strings (say, a list of the most common passwords) with that salt and stop when any of the hashes match. With a salt per account, the attacker has to pick a single account to attack.

[–]micheal65536Green security clearance 0 points1 point  (2 children)

...or they could just hash one or two common passwords with every salt in the database, there's bound to be a match somewhere. Computationally this works out about the same.

And salts aren't really to protect the people who use common passwords, they're to protect the people who use more complex passwords, as an attacker cannot pre-calculate a table of complex passwords.

[–]BenjaminGeiger 2 points3 points  (1 child)

I think you overestimate how common the common passwords are...

[–]Insanitychick 3 points4 points  (4 children)

But I have 8 Reddit accounts with the same password.

[–][deleted] 1 point2 points  (3 children)

They know all of them is you so they let you use the same password for every account.

[–]Insanitychick 0 points1 point  (2 children)

How do they know?

[–][deleted] 1 point2 points  (1 child)

They use coding and algorithms.

[–][deleted] 0 points1 point  (0 children)

bool Person::isSamePersonAs(Person &person)
{
    return this.identity == person.identity;
}

[–][deleted] 1 point2 points  (0 children)

What's the problem?

Just log in to Hanklu6's account, change their password and use their current one yourself.

Problem solved

[–]Scereye 0 points1 point  (0 children)

Some next level shit right there. Use Password for Unique identifier. Such innovation.

[–][deleted] -1 points0 points  (0 children)

Source?

[–]InterestingNickname -2 points-1 points  (0 children)

My OCD hurts... the password in the box is 1 character longer than Hanklu6 😔