Reusing passwords that can possibly never be cracked

Question

Reusing passwords pose as a terrible risk for users because in the event of a data breach, with the passwords not being stored securely enough, this means that, by default, all other services that they use this password for are also compromised. Typically with these breaches they store the password using only a hashing algorithm like SHA-1, or even still MD5 in some cases recently (which were never meant for storing passwords securely), making it easy for attackers to bruteforce passwords using just raw GPU hash power.

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, is there a risk in reusing this password for multiple websites if it can possibly never be cracked in their lifetime if a data breach occurred on one of the services they use?

Answer 1

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 password on Facebook and SomeBlackHatCommunity dot com). Also, there is always the good old shoulder surfing for stealing passwords. A password is like a key, and by using the same password you are actually giving the same key to different doors to different people. You can see it's never a good idea.

So you should never use the same password in different places, unless that password protects the same data or gives you the same privileges, so for example I believe you can use the same password to protect your backups.

Answer 2

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:

https://www.xkcd.com/936/

Because if there's not a relevant XKCD, there soon will be.

Reusing passwords pose as a terrible risk for users because in the event of a data breach,

Only if that password is protecting something that matters.

For general internet forum usage I have a nom de guerre with it's own email address, and four or five passwords for everything.

These passwords protect nothing. Even compromising the email account behind them gets you nothing but the ability to make my nom de guerre look dumber than he already looks.

with the passwords not being stored securely enough,

Password aren't stored. We'll come back to this.

this means that, by default, all other services that they use this password for are also compromised.

To be more precise that should be worded:

...this means that, by default, all other services using that email address and password should be considered compromised AND if the attacker knows your other email address, any that use that password should be considered...

Identity (for these purposes) are what you are (email address) plus what you know (password).

If I know you are "[email protected]" on somerandomforum.com and wellsfargo.com AND you use the same password for all three you're hosed.

But if you use "[email protected]" on webforums, and [email protected] for your "personal" use, and "[email protected]" for professional use, then it is extremely hard for an algorithmic attacker to sort them.

Typically with these breaches they store the password using only a hashing algorithm like SHA-1, or even still MD5 in some cases recently

I know you know this, and I'm being horribly pedantic, but generally we do not store passwords. If it's SHA-1, or MD5, or any other hash (including the poor, dead "crypt" or the newest unbrokenest one on the block) there is no provable reliable round trip from the hash to the password.

You CAN NOT and do not get from eaf4c33ae978d3f2852021214a061534 to "Fred is dead". You MIGHT be able to create two or more strings of indeterminate length to that same hash. What you can do is generate strings until they match. This is different, and it's a CRITICAL difference. And it's critical for this too.

(which were never meant for storing passwords securely), making it easy for attackers to bruteforce passwords using just raw GPU hash power.

What an utter waste of time and electricity that would be MUCH better spent ${WHATEVER}coin mining.

Either way, you don't reconstruct the hash, you keep throwing strings at the algorithm until you get a match

Precomputed rainbow tables are a LOT faster when through the five million email:name:password tuples you just extracted from BigWebSiteInc, and are going to get you a LOT more results a LOT faster.

And yeah, know GPUs can compute that s*t really fast., but lookups are WAY faster, and I'm going to want to break LOTS of passwords, not just yours.

If I want YOUR credentials I have other ways of getting them and if I want them bad enough...yeah, that's probably not a forum Stack Exchange wants to host. There's a lot of aspects to security and cryptography only protects some of them.

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

True story. A little over a decade ago I was in the reserves of the US Military, and they have (had?) a system where your military ID was part of your credentials for your network account. To log in to most of their computers you had to put your military ID in a smart card reader and put in your "pin number".

At one point I got a new ID card, which necessitated a new PIN. So I went to the pin entry place, and put a IIRC 10 digit number into the keyboard, then put it in again. It said my PIN matched and off I went.

I got back to my unit and tried to log in. Failure.

So back I went. A couple times. We were confused. Then I shortened the PIN and it worked.

There was a 8 or 9 character limit on the PIN (or whatever. It was $MY_NUM-2). The FIRST entry system was silently discarding the extra numbers. The second wasn't, leading to a mismatch. (Or the other way around)

ISTR there is some stuff in the SAMBA readme about early version of NT's password database storing the hash in 2 parts because old LANMAN (??) stuff only did 8 character passwords. Not sure how THAT worked.

Anyway some of the times the workflow from entry screen to password storage is going to have a limited number of characters, some aren't. And this can change as various websites change their software. Heck, it could be different on different parts of a federated system. You want to make sure you don't overflow their expectations.

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, is there a risk in reusing this password for multiple websites if it can possibly never be cracked in their lifetime if a data breach occurred on one of the services they use?

Honestly, for high security applications (e.g. protecting SSH keys etc.) I use the first couple stanzas from a couple of well remembered songs. At least one of them has an accidental misspelling that is permanently fixored in my brane.

The thing is that if I am looking at a ID:pw hash in a password store (file, database,whatever) I WANT the easiest to break that I can. I don't want the guy who's using some sort of strong key store and has a different password for every other site, I just want the low hanging fruit. Those are the ones most likely to reuse passwords.

So yeah, it makes your password more secure, modulo a couple things.

You don't get to pick the hash used on the far end, and as long as people are using "broken" hashes (md5, SHA-1 etc.) you can get more than one string to match the hash. And as long as one website you use continues to store passwords in a bad hash you're vulnerable.

This is why I was being pedantic. We don't store passwords, we store a hash of the password, and I don't need to recover YOUR password, I just have to find a string that generates the same hash.

It may be that your 100 Character string composed by the output of the finest whitened random number generator just happens to match the hash of "Fred is dead" and then you've lost.

That's on top of someone putting a camera where it can watch you type, running a MITM attack on your SSL session (which is about half the major corporations I've worked at over the last few years--they do it on their proxy server to do DLP), hacking the website to put some extra code in their login page, or any one of a dozen other hacks.

Or just putting a gun to your knee. Or more grisly methods.

Using throw away passwords for throw away data, multiple online "identities" and some sufficiently secure key storage for the important stuff is probably the best way to go. This is a sort of "defense in depth", and is fairly easy to do (heck, I can do it, it can't be that hard).

To address something @IMSoP brings up as a comment.

The actual stored hash is usually the password + a hash so it IS unlikely that your favorite insecure web forum and your bank will use the same hashing algorithm and salt. They might, but unlikely.

However, a secondary point is that for ANY site using an insecure hash--and that's a LOT of them (see Another True Story below) an attacker can retrieve a string that hashes to what is stored and then interact with that site as you.

This does wander afield of the "password reuse" issue, but does address the super-long password issue. It's like in ...um...other areas in life. A certain amount is good, more is better, but too much will cause problems.

As to the use of "insecure" hashes, businesses tend to worry most about lawsuits, and secondarily about publicity, and finally about really being secure. A friend of mine has a patent on a fairly secure storage mechanism that would significantly increase security for laptops and desktop (among other things). He has tried to get a couple large companies involved in this, and every one he's approached has indicated the same thing--that their current security meets both "common industry practices" and legal standards, so they are not interested in any expense beyond that. They are, in their opinion "lawsuit proof", and are much less concerned about publicity because of it.

This is why banks have decided that asking a stupid question is "three factor authentication", and other clearly questionable security practices.

This means that their hashing algorithms are what shipped with the OS when it was installed. Because that is the "common industry practice".

A 16 or 20 character password stored in a secure password tool is just as good as a 100 character password under these conditions.

To wrap it back around I am not as opposed to password reuse as some here--I have several home computers that I share the same password on (and a few that are different), but I never duplicate some of them (my personal, professional and work email accounts, bank passwords etc.). Just not worth the risk.

Answer 3

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 password is if an attacker can simply read it off a badly-designed server's password-change log.

Answer 4

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. Even companies that should know better have screwed up their password system recently: GitHub and Twitter have both internally logged or cached plaintext passwords.

There's also no advantage -- you'll never remember that password so you store it in a password manager. At that point you may as well use unique passwords (which are shorter in case you ever have to retype them).

Answer 5

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 may appear in password lists that are used to attack other websites. So the problem with password reuse is that security is set by the weakest function and if there is plaintext storage somewhere, the security has dropped to zero, even for actually secure passwords.

Answer 6

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 password achieves nothing.

Unfortunately a lot of websites store store passwords in plaintext and it's not always immediately obvious whether or not a website does this. So it is not safe to reuse a very strong password on the assumption that the hash will not be brute-forced, because it may still end up being stored (and breached) in plaintext.

Answer 7

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 assumes a lot of statements that most people will not be in control of:

their machine is not compromised in the sense that there is a keylogger installed or the like

Don't forget network security too, does your encrypted tunnel validate that it's not being MITMd? What about HTTPS issues, a compromised CA? Another HEARTBLEED style scenario where all the traffic to the site has been compromised because the certificate has been hacked out of it? Also if I wrote a keylogger now, unless there's a large number of infections you're not necessarily going to be able to detect it. Do you log in on other machines that others have used? Do you let other people use your machines? How about mobile devices? Are you updating your computer regularly? What if I watch you type in your password in a public place that has CCTV? Hardware keylogger? Evil maid attack?

..I think this is all a big assumption...

is there a risk in reusing this password for multiple websites if it can possibly never be cracked in their lifetime if a data breach occurred on one of the services they use?

Recently it was revealed while Twitter may store the passwords securely, their logging functionality was leaking it. You're also having to rule out some other implementation specific weakness in all of the site's implementation.

You hint at it in the preface about insecure sites, so I'll assume you're also assuming all the sites you will use this password you know also secure the password securely. For most sites I use online how will I know this? I won't and even if they say they hash passwords securely, there's no guarantees they do.

Use different passwords for different sites. Use a password manager, KeePass is pretty good :-).

Answer 8

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.

Answer 9

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, is there a risk in reusing this password for multiple websites if it can possibly never be cracked in their lifetime if a data breach occurred on one of the services they use?

There's a few problems with this. First and least, the passwords you're suggesting are way too long. There's about 2^6.6 printable ASCII characters. A 20 character uniform random password therefore is sufficient for 128-bit security, and a 39 characters are sufficient for 256 bits. Strong passphrases could conceivably get into the 100+ character territory, but their strength has little to do with the amount of symbols or letters.

The second and bigger problem is that you're putting unnecessary trust on site implementers. If none of the sites ever has a bug that allows an attacker to recover the password, then yes, it'd be safe to reuse the password. The problem is that's a huge "if." It's very easy even for a website that has designed a good password storage system to accidentally disclose your passwords. Consider this very recent Twitter incident (from earlier this month):

Today, Twitter issued an alert to users prompting them to change their passwords after the discovery that some users' passwords had been recorded in plain text in a log file accessible only by Twitter employees.

[...] But because of a coding bug, Agrawal explained, "passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again."

This is a very easy mistake for a programmer to make; you just throw in a log(LogLevel.DEBUG, "loginRecord = {}", loginRecord) line or similar into your program and somebody else inadvertently turns on debug logging in production. Now multiply this by thousands of programmers over thousands of days over dozens of websites, and the dice are very much against you. Don't reuse passwords. And use a password manager.

Answer 10

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; cat test-rand; echo amazon.com) | md5sum | sed 's/ .*$//' | xxd -r -p | base64

The above command line will always produce the password Tj02tXSPT+cQvN+79QqtjA== from the particular random file I created, but if I change amazon to google, it will produce oX9uOqM0/wUaNzUlTMUcfg== instead.

If I type the master password incorrectly, I get something completely different as output, but so long as I put it in correctly, I always get the same output for the same site, but different output for each different site. Now no one has the "key file" and the master password (a sort of two-factor authentication) needed to generate the site-specific passwords. If amazon is compromised, my google password is not. The passwords each contain 128 bits of randomness, which ought to be good enough for about anything.

Answer 11

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 other web attacks, shoulder surfing, and probably a dozen other ways to your password exist, and for many of them the complexity or length of the password makes no difference.

Answer 12

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.