77

You don't need to bruteforce a hash to steal a password. A website might be compromised by an attacker so that they can read the passwords directly from the login form, in plain text. Or the website owner might be doing this, they could always do it if they wanted to, it's up to you whether you trust the owner or not (you wouldn't want to use the same ...


70

TL;DR: I don't need to recover YOUR password, I just have to find a string that generates the same hash, and as you don't control the hash the website developer uses until they all use a secure one, it doesn't help as much as it costs. And if I'm after you I keep hacking websites you use until I find a weak one. Or I use another method. Relevant XKCD: ...


70

Credential stuffing - use a bunch of usernames and passwords which are known to be associated with them to try and access multiple sites Password spraying - use a list of usernames and some common passwords (which aren't known to have been used by someone with the usernames being sent) to try and gain access to a single site The key difference is whether ...


25

Credential Stuffing - is a type of attack that relies on users reusing the same password and username combination across different applications, where at least one application is compromised. For example: say StackExchange was compromised and my account and password where leaked. Then an attacker could search other social media sites for users with the name ...


19

Typically a website will use a weak hashing function for storing passwords, but are you willing to say that none of the websites you use will store the password using encryption, or worse, in plaintext? By re-using a password, your security is only as strong as that of the weakest of the sites you use it on. It doesn't matter how long or complicated your ...


12

You assume a perfect system with in the case that their machine is not compromised in the sense that there is a keylogger installed or the like, and all their browsing sessions are done through an encrypted tunnel, or at least I assume you do -- that encrypted tunnel had better be good. But you have no control over the server that holds your password. ...


8

You can find different solutions for password hashing on websites: Memory-hard functions like Argon2 or Scrypt, custom hardware vulnerable, but at least salted functions like PBKDF2, simple hash functions without salt and work factor and - unfortunately not so rare - also storage or transmission of plaintext passwords. Once a password is compromised, it ...


8

There is a risk in reusing passwords even if your password is very strong. If a website that stores passwords in plaintext is breached then your strong password will be available to attackers with no need to brute-force any hashes. In other words, if you use your very strong password on a website that stores passwords in plaintext, the strength of your ...


7

I think everyone has made it clear, I am just giving in the field practical examples. credential stuffing This kind of attack is started through acquired leaked account credentials from an exposed source (e.g. exposed by bad website, hacking, etc). Haved I been pwned has a huge db of exposed accounts for a researcher to download. To initiate the attack,...


6

TL;DR: Password cracking isn't the only security consideration with password re-use. Sharing a password with multiple sites means if there are any issues with the other sites/your computer/your network apart from crackable passwords you're still at risk. Some great answers here already but just to add a few more considerations and a summary. Your question ...


4

You're assuming that none of the sites they visit are hostile. If I register on a site and give them my email address and use the same password for this site as I do for my email address then they can log into my email. Something Mark Zuckerberg actually confesses he did when starting up the facebook.


4

If a person was to create a properly random password of sufficient length (e.g. 100+) of very sufficient entropy which is mixed with many types of symbols, numbers and letters; in the case that their machine is not compromised in the sense that there is a keylogger installed or the like, and all their browsing sessions are done through an encrypted tunnel, ...


3

Password re-use is always a risk evaluation. In practical terms, password re-use is a fact and the question is where to use which set. However, the real answer to your question is that there are many ways to compromise a password and brute-forcing is actually the least likely one. Sniffers, keyloggers, MitM, compromised servers, various forms of XSS and ...


3

Modify the original idea A modification of your idea could be pretty secure, though. Let's say you generate 64 random bytes of data, then save it to a file. You then choose a "Master Password" that you never tell anyone, and then use that password, the saved file, and the name of the site to generate a site-specific password: (echo super-secret-password; ...


2

There are many ways a password can be compromised. Using uncrackable passwords, at best, does nothing to mitigate the risk of compromise by other means. In reality, it makes other weaknesses worse.


2

The purposes of those accounts are different, and so is the data protected by those passwords. If only one password gets stolen, the attacker will be able to access both the services / data / accounts / etc. So to reduce the impact of a possible attack or at least to slow down the attacker, those passwords should be different. Even if the threat model makes ...


1

With github, the site is the same, so password reuse is not much problem. With offline reuse for encryption, there is also not much of a problem. The greatest threat of password reuse is for example, that if you use the same password for facebook and github, facebook has your github password and vice versa. It is even worse with smaller disreputable ...


1

When it comes to usernames, its generally better to keep them same. The good with that, is that it eases account termination when a user no longer should have access. If all users have different usernames for different systems, then it would be heck of a job to find out which accounts that belong to a user that is leaving employment, and theres high risk ...


1

It depends on the situation really. If you use radius authentication and it's connecting back to you AD infrastructure and your using it within say your routing and switching environment to gain access to the CLI then it's OK. However this only because radius is a aaa service. If you use the same user and password to create domain administrator level changes ...


Only top voted, non community-wiki answers of a minimum length are eligible