1
$\begingroup$

How does having the same password in different services make it less secure? How does having the same password as someone else make it less secure? Very basic question that I've always wondered about; I've been reminded by GitHub recently seen this message,

The password you provided has been reported as compromised due to re-use of that password on another service by you or someone else.

and,

Generate a unique password for GitHub. If you use your GitHub password elsewhere and that service is compromised, then attackers or other malicious actors could use that information to access your GitHub account.

Theoretically, how would that work? Shouldn't a different salt render it almost useless to any attacker?

different salt values will create completely different hashed values, even when the plaintext passwords are exactly the same [Wikipedia]

$\endgroup$
  • 1
    $\begingroup$ I don't understand your understanding of salt. If Facebook uses salt to store password hash does that force you to change how you type the password? No? Then how would salt make your password that is known to an attacker unusable? $\endgroup$ – slebetman Oct 20 '18 at 14:31
  • $\begingroup$ @slebetman so one's attacker has to know something about the password. $\endgroup$ – Neil Edelman Oct 20 '18 at 22:02
  • 1
    $\begingroup$ Not something about the password. One's attacker has to know the actual password. If Github complains that your password was reused it means that there is a list out there somewhere being torrented that contains the password you are using. There is a risk (Github cannot be sure) that the account that was cracked was your account from another site so if someone knows you he could just use that password. Github cannot tell if you simply use a similar password as someone else from Github because the salt would cause the exact same password to have different hashes. $\endgroup$ – slebetman Oct 21 '18 at 0:55
6
$\begingroup$

Salt is usually stored along with the hashed password. When an attacker knows that your password is "abc123" in "pqr.com", he can try your username and password "abc123" in site "efg.com". Now "efg.com", would retrieve the stored hash against your username and extract the salt from it. Then the extracted salt is used to calculate the hash of the entered password and then matched with the stored hash.

The purpose of salt is to ensure that just by looking at two hashed passwords, the attacker can't tell whether they are same or not.

Salt is not a secret. The only requirement is, it has to be unique within a given DB. Its existence is just for preventing the attacker to prepare a pre-computed lookup table with passwords and their hashes to do a dictionary attack. But if the password itself is known to the attacker, salt cannot save the user.

$\endgroup$
  • $\begingroup$ So the attacker would have to have some knowledge of the password from the elsewhere, or be relegated to a brute-force attack like everyone else. $\endgroup$ – Neil Edelman Oct 20 '18 at 21:33
  • 1
    $\begingroup$ Yes..that's the point Github makes in your case. That's why every user is supposed to have a different password for each different website so that even if one site's security gets compromised, the other wwbsite accounts remain secure $\endgroup$ – Saptarshi Basu Oct 21 '18 at 5:07
3
$\begingroup$

If the password has been known to be compromised then certainly the password won't be all too unique. It is probable that an adversary will try and use that password when trying to compromise accounts by simply testing that password for each user.

"If a service is compromised" does not need to mean that the data at rest - i.e. the storage device holding the database - is stolen. It may be that the server is compromised and that the attacker will intercept any password typed into the service by the user. As the server generates the code that asks for the password, an attacker should then always be able to retrieve your password, before a password hash with the salt is applied to it.

$\endgroup$
  • $\begingroup$ That makes sense. The more anyone uses that password, the more likely it is that someone will intercept it, especially, I assume, on incorrectly configured https, ssh, or plain text transmission. $\endgroup$ – Neil Edelman Oct 20 '18 at 21:42
0
$\begingroup$

When a site stores your encrypted password, it also saves the salt which is used to encrypt your password. However, since this salt is also known to the attacker he can use it to crack your password. If, for example, he does this with a leaked database of site 123.com and he is able to crack your password back to plain text, the attacker can then use that password to try to login on other sites like github or any other service.

$\endgroup$
  • $\begingroup$ Figuring out the plaintext password from a salt and an encrypted password -- wouldn't that be a computationally intractable problem? $\endgroup$ – Neil Edelman Oct 20 '18 at 21:17
  • 1
    $\begingroup$ Yes, it will cost more computing power, but not that much that salting can be considered a brute force protection. Most of the time, this salt is simply appended to the end of your password and then that total string gets hashed. So yes, your computer will have to hash a few more bytes and it will take a little longer, but it's not much more difficult to crack than a non-salted password. $\endgroup$ – Z3r0byte Oct 21 '18 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.