06
Jun 16

Password Re-user? Get Ready to Get Busy

In the wake of megabreaches at some of the Internet’s most-recognized destinations, don’t be surprised if you receive password reset requests from numerous companies that didn’t experience a breach: Some big name companies — including Facebook and Netflix — are in the habit of combing through huge data leak troves for credentials that match those of their customers and then forcing a password reset for those users.

Netflix sent out notices to customers who re-used their Netflix password at other sites that were hacked.

Netflix sent out notices to customers who re-used their Netflix password at other sites that were hacked. This notice was shared by a reader who had re-used his Netflix password at one of the breached companies.

Netflix.com, for example, sent out a notification late last week to users who made the mistake of re-using their Netflix password at Linkedin, Tumblr or MySpace. All of three of those breaches are years old, but the scope of the intrusions (more than a half billion usernames and passwords leaked in total) only became apparent recently when the credentials were posted online at various sites and services.

“We believe your Netflix account credentials may have been included in a recent release of email addresses and passwords from an older breach at another company,” the message from Neflix reads. “Just to be safe, we’ve reset your password as a precautionary measure.”

The missive goes on to urge recipients to visit Netflix.com and click the “forgot your email or password” link to reset their passwords.

Netflix is taking this step because it knows from experience that cybercriminals will be using the credentials leaked from Tumblr, MySpace and LinkedIn to see if they work on a variety of third-party sites (including Netflix).

As I wrote last year in the aftermath of the AshleyMadison breach that exposed tens of millions of user credentials, Netflix’s forensics team has been using a tool that the company released in 2014 called Scumblr, which scours high-profile sites for specific terms and data.

“Some Netflix members have received emails encouraging them to change their account passwords as a precautionary measure due to the recent disclosure of additional credentials from an older breach at another internet company,” Netflix said in a statement released to KrebsOnSecurity. “Note that we are always engaged in these types of proactive security measures (leveraging Scumblr in addition to other mechanisms and data sources), not just in the case of major security breaches such as this one.”

Facebook also has been known to mine data leaked in major external password breaches for any signs that users are re-using their passwords at the hacked entity. After at a breach discovered at Adobe in 2013 exposed tens of millions Adobe customer credentials, Facebook scoured the leaked Adobe password data for credential recycling among its users.

The last time I wrote about this preemptive security measure, many readers seem to have hastily and erroneously concluded that whichever company is doing the alerting doesn’t properly secure its users passwords if it can simply compare them in plain text to leaked passwords that have already been worked out.

What’s going on here is that Facebook, Netflix, or any other company who wants to can take a corpus of leaked passwords that have already been guessed or cracked can simply hash those passwords with whatever one-way hashing mechanism(s) they use internally. After that, it’s just a matter of finding any overlapping email addresses that use the same password.

Message that Facebook has used in the past to alert users who have re-used their Facebook passwords at other breached sites.

Message that Facebook has used in the past to alert users who have re-used their Facebook passwords at other breached sites.

Tags: , , , , ,

68 comments

  1. Thank you, once again, Brian, for explaining these stories in terms anyone can understand! I constantly preach to colleagues/friends/family about not re-using passwords, but I was a big offender long before my security career started.

  2. At least someone gets the security thing and acts in the best interest of the customer…

  3. @Brian Do you mean “Get ready to get busy”? “Get to Get Busy” doesn’t make any sense to me

  4. There goes the teachings of “don’t click on suspicious links in emails” argument I keep trying to drill into people’s heads.

    Instead of giving users something to click on, they should say log into your account and we will prompt you to change your password. No clicking on links that way!

    • Agreed. It should be written as “Click on the bookmark or favorite in your browser that you usually use to log in to ______ and then change your password”.

      Entities that include links in their emails for this purpose should be chastised.

  5. So, aren’t they inadvertently identifying their own bad practice? They shouldn’t be decrypting their users passwords.

    • These leaks were usually plain text passwords. So, all Netflix has to do is run the leaked passwords through the same hashing algorithm and compare the hashes. No need to decrypt data.

      • Joe .. thank you … you just answered my question about plain text versus hash value. When will we begin the universal finger print authentication with another identification factor

    • Mik, Netflix cannot decrypt your password (nor can anyone else), as passwords are not encrypted in the first place. They are hashed. Given a password, all they can do is run it through whatever hash method they use, to see if they get matches to the hashes in their own database.

      The hash returned at Netflix will amost certainly NOT be the same as the hash returned at LinkedIn, Tumblr, and others. That is because all of these places are (or should be) salting their passwords. That is, they should be adding characters to your password that they know about, but that you do not.

      Absent salting, a criminal with access to the files could directly compare hashes on multiple systems, and matching hashes would imply that the same password was used on those systems.

      But Netflix started with with the publicly revealed passwords.
      They hashed them using their method. Then they compared the hash to the stored hashes on their systems. Matching the hash to a Netflix user’s account (email address) means that that Netflix user used the same password at mulitple sites.

      So they are not using a bad practice. They are simply using the same method that authenticates their users at login.

    • No. @Brian even included two paragraphs at the bottom of his post to preempt your question, I’ll quote the last one:

      «What’s going on here is that Facebook, Netflix, or any other company who wants to can take a corpus of leaked passwords that have already been guessed or cracked can simply hash those passwords with whatever one-way hashing mechanism(s) they use internally. After that, it’s just a matter of finding any overlapping email addresses that use the same password.»

      Even if they salt their passwords, they could check the individual passwords directly. Since what they have as input is essentially {useraccount, password} and what you give them when you try to log in is {useraccount, password}, they are essentially pretending to log in, just as you (or an attacker with the leaked credentials) and seeing if the process lets them in. If the standard login sequence accepts the password, then they need to tell you to reset it.

      Note to @Brian: if passwords are salted, they can’t compare one password (hashed) against all user (hashed) passwords, because the of the salt, but since they have the username, they don’t need to, they can just use the right salt for the right username.

      https://en.wikipedia.org/wiki/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 versus a list of password hashes and against pre-computed rainbow table attacks.»

  6. While some users see this as a pain, it really is in the best interest of the account holders. So many people reuse passwords, if your using a password manager then it really doesn’t matter if you have to setup a new password. Now if only TeamViewer would share similar values they could quite rumors of hacks due to other companies and not their own.

  7. How do companies like Facebook and Netflix know if a password is being reused on their website(s)? Do they compare hashes? Does that mean they all use the same hashing algorithm? Is it weak security to do such?

    • No. They take the public pw (already hacked, decrypted) and run their hash algo (call it new hash), then compare it to their users hashed pws, as per brian’s explanation. There is no need to.decrypt anthing in that process as the hackers already did that part.

      That said, it does raise the problem of having a stolen raw pw file out there. Wait until the hackers decrypt it? Or do so first. conflicting issues there, so better public policy help (gov) would be useful.

      • No. Governments need to keep their nose where it doesn’t belong. The right thing to do is already clear. Some companies are doing it. Government oversight would only take more money from our pockets and do a worse job than the industry can do on its own.

        • You may be reading what is not there. My post neither suggest gov put their nose in, nor out. What is suggested is better public policy. This includes things like where the line is for decrypting another company’s data, as one example.

          If one takes a ‘no rules’ approach, then all hacking becomes legal, and you go down that road, so i suspect your post is an expression of your ideology and less on the issue raised, which was when does goggbling up, decrypting and taking action with data that is not yours become unacceptable. which actions are acceptable, which are not, IS public policy.

          I repeat, I think we need better public policy in this area, and yes more clear laws, rules, regulations of what is permissible and not should be put in place by government. I understand some folks do not like operating under rule of law, however that is the system we presently operate under.

          In any event, I regret my time is too valuable to ‘discuss’ your ideology further.

          Good luck.

      • Hi Lee; an interesting point, but I don’t believe we need gov’t: use the data immediately to protect users but don’t use it for any protected, unfair, or illegal business tactics, such as marketing, bid proposals, contract negotiation, etc.

    • For those needing a simplified explanation of what these companies are doing (and how it’s secure):

      Let’s say that the list of credentials leaked from LinkedIn included the following:
      email: joebob@yahoo.com
      password: correctHorseBatteryStaple

      Facebook, Netflix, even you (if you have a copy of the list) can see this in plain-text.

      Netflix takes Joe’s credentials and hashes them which produces: AB87C99E88F8D

      Netflix uses the word “potato” to salt all their password hashes, so it now looks like: 6544C9B976ADB9. They store this as joesLeakedHash.

      Then, they look at the password hash they have on file for joebob@yahoo.com and see that it’s 8B665A98B9E8B6 – completely different.

      Facebook, running their own checks for Joe, arrives at the same starting hash of AB87C99E88F8D, but they salt it against the word “jupiter” which gives an output of 7A877B8C6A6EE7. They compare this hash against the password hash they have on file, and it matches the same 7A877B8C6A6EE7 – uh, oh, Joe Bob re-used his LinkedIn password with Facebook.

  8. What a clever idea! Use account data from other sites to make your own site more secure. It’s nice to see the security community is only 4-5 years behind what criminals have been using to make accounts less secure. They figured out a long time ago that most users can’t be bothered having different secure passwords for all their accounts, so they make ONE very secure password (if we are very, very lucky) for ALL their accounts. Heck I do the same thing but not at any site I care about.

    Here is an idea: Sites should require that all passwords are unique, just as they do with user names. I know it might not be easy for sites like FaceBook to make sure ALL users have a unique password unlike anyone else’s, but it would certainly help. Using the email address as a login name is just asking for trouble.

    • On the surface requiring all users have unique passwords seems like a good idea. No more than one user at a site will have the weakest password of “password” or only 100 users will have the top 100 weakest passwords.

      But implementing this type of unique password should be impractical if a site is securely storing passwords. Passwords should be stored using a one-way hash and salted. A one-way hash means there is no way to de-crypt or un-hash the password. The only way to see if a password has been used by another user when using one-way hashing is to hash the requested new password and compare to all other users’ password hashes. When salting is used, each user is given a unique salt string added to their password before hashing. So when on-way hashing and salting is used, you have to hash each new requested password with each users’ salt string and compare to each users’ hashed password. The more users there are, the more salting and hashing would be required for each password change. Impracital .

      Even if it was practical, would there be enough benefit?

      I applaud the companies like Netflix or Facebook for taking this proactive approach. It is a good tool of many in the security toolbox.

      • We think of logins as a single password to a single hash.

        A system could create *two* hashes.

        One salted for authenticating a login, and one hashed totally differently with a consistent salt (or none) for use in an password uniqueness blacklist.

        When a user changes their password, they typically provide {username, oldpassword, newpassword, newpassword}, at that time, you could hash oldpassword twice, once to confirm the oldpassword matches the user, and once to find out which reserved password to unreserve.

        Such a process is technically possible, it’s just a horrible idea (as you rightly conclude).

        Websites are very very very afraid of “incompletion rates” (I don’t have a great citation for this handy, but you can find lots of articles about it, for simplicity, here’s one about surveys [1]).
        Anything that complicates the initial account creation process increases the likelihood that a user will abandon their efforts to create an account. That’s pretty much the worst thing possible. It’s why for a while sites didn’t bother verifying email addresses (some stupid sites including one mentioned in this article fall into this category). It’s why sites often didn’t have any complexity requirements. It’s why sites don’t want to require 2FA. It’s why lots of our security problems exist. “ease of use” is prioritized over everything else.

        You may not remember the “pick an account name” problem. AOL used to have it, when you wanted an AOL username, or an AIM username, you had to pick one that was unique. That process was immensely frustrating, because someone else was probably squatting on your preferred name, so you tried something else, and it too was taken. It often took 5+ tries to find a username that was available. People already hate password rotation policies (can’t use the last 3 passwords). Can you imagine having millions of passwords blocked?

        The right answer to this is for browsers and password managers to default to offering to create (and store) random passwords for users for each account they create. At that point, users can stop being forced to pick passwords (we suck at picking passwords).

        [1] http://fluidsurveys.com/university/difference-response-rate-completion-rate/

    • This is a very bad idea. But it has been done, and by so-called professionals. Someone I know once worked at a medical clinic, many years ago. This person chose a password which was a very uncommon foreign word that would be known and meaningful to a very small number of people. (Not a good password, but that’s a different issue.) An error was returned that the password was already in use. It so happened that only one other person in the clinic, a doctor, would have any connection or likely knowledge of this word. So this poor IT decision likely led to the compromise of a doctor’s password.

      • Thanks for sharing. I really appreciate this anecdote.

        I’m reminded of the WPS PIN vulnerability [1]:
        > Basically, 8 digits and 10 possibilities per digit (0-9) make it 10^8 seconds if we assume one key per second. Now that’ll be [3] years.
        > Now a pin has 8 digits, and only contains numbers…
        > The 8th digit is a checksum of first 7 digits. 10^7 possibilities…
        > The pin number for verification goes in two halves, so we can independently verify the first four and the last four digits. …
        > Basically, the first half would take 10^4 guess and the second would take 10^3.

        [1] http://www.kalitutorials.net/2014/04/hack-wpawpa2-wps-reaver-kali-linux.html

      • If I understand you correctly, they used the rejection of their password as confirmation that the second user already had that password. Although in larger user bases you dont know which user caused the rejection, one could create a dictionary of rejected passwords. On cracking, because they are unique, each success, would remove that password from the dictionary, making short work of even large user lists. To make matters worse, distributing attempts across many users renders time lockouts much less useful.

        Often we create new modes of failure when we try to be too cute…or as the english say, ‘too cute by half’.

        The other problem you highlight, is rare words(language), like many socially human related items, are clumpy, so in the aggregate it may be rare, but not gaussian distribution. It comes down to what is ‘random’ being equal to ‘not well understood’. Another posting suggesting online random pwd would also suffer from this limitation (the argument ‘how would they know…’has has very often ended with ‘oops’). Such approaches collapse when the ‘random’ nature of the process is better understood (eg. seed, salt become known).

        What all of this does is essentially leverage the security on the process that created the ‘random’. It may reduce the number of events for a period of time, but at the cost of larger events. What it does not do is reduce the size of the haystacks; it does not reduce scope of the consequence portion of risk. The FB onion, mentioned in an above post, does help, but at the cost of complexity.

        anyway, I completely agree with your post: unique passwords create other issues.

  9. I’m glad to see it being done by others. Our company (healthcare) has a intel operation that runs all the dumps we collect from ‘out there’ , see if we can tie them to employees , and then run them against our internal systems to see if the password they use ‘out there’ is the one they use ‘in here’. If so, they get a nice note and a forced change of internal password.
    We find them consistently….

  10. Berend de Boer

    I got an email from netflix. But I definitely was not reusing a password, so not sure why they logged me out.

    PS: when I signed up with Netflix I initially reused a password, as I was just trialling the service. But that password has since long been replaced.

  11. A suggestion to greatly increase your password security without greatly increasing inconvenience:

    1. Go to the Internet and call up a random password generator.

    2. Instruct it to use numerals, symbols, and both upper and lower case letters for passwords.

    3. Use your word processor to create a document, but encrypt it before you save it. Name the file something innocuous, like “Laundry list.doc” Use the strongest encryption available, and use at least a 15-character password from the password generator. This is the only password you must memorize. Don’t use it for anything else.

    4. Go to each bank, credit card and other high security website you use. Check for the maximum number of characters allowed in a user ID and password.

    5. Use the password generator to create maximum-length user IDs and passwords for each website. Never use an ID or password on more than one website.

    6. As you progress, record each ID and password in the word processor document. Be sure you’ve encrypted the document before you enter any information.

    7. Whenever you sign on to a website, you call up your password list, then enter the master password. Now you can define the proper user ID, copy it, then paste it to the website. Same with the password. You don’t ever have to memorize either or them.

    8. Back up the encrypted file every time it is changed.

    • 9. Print a couple copies of the master list, one to sit on your desk at home, one to carry around.

      10. Write your master password on a Post-It note.

      11. Never change passwords so you don’t waste paper printing the list again.

    • Thanks for that set of instructions Steve. Very good ideas.

    • Or use a good password manager like LastPass that will do this for you more conveniently and securely.

    • Personally, I’d recommend using a password generator from a password manager:
      * OS X’s KeyChain.app [1] — I miss this
      * Google Chrome [2] — although I’m not sure I’ve managed to get it to work
      * LastPass [3]
      * 1Password [4] — my help link is for Mac, but the feature should be available everywhere
      * KeePass [5]
      * Dashlane [6]
      * There are Firefox addons [7] — I’ve never used one, and wouldn’t use one without reading the source (it’s GPL3, so I would probably never use it, as it might impair my ability to work on a competitive product in the future)
      * Norton [8] — I’ve never used it, I’ve avoided norton products since the turn of the century…

      I would not recommend using a website to generate a password. — How can you trust the website not to do something with your password?

      When I have a working manager, I do. Otherwise, I manually generate random passwords using a local scripting language (perl, python, javascript).

      [1] http://www.iclarified.com/23680/how-to-use-os-xs-builtin-password-generator
      [2] http://www.thewindowsclub.com/chrome-password-generator
      [3] https://helpdesk.lastpass.com/generating-a-password/
      [4] https://support.1password.com/guides/mac/generate-a-strong-password.html
      [5] http://keepass.info/help/base/pwgenerator.html
      [6] https://www.dashlane.com/password-generator
      [7] https://addons.mozilla.org/en-US/firefox/addon/secure-password-generator/
      [8] https://identitysafe.norton.com/password-generator/

    • Why would you use this method vs using a password manager that does this? KeePass is open-source, free and offers (http://www.lessismoreorless.com/2015/12/02/you-only-need-to-remember-4-passwords/):

      – Does not require internet connection or any cloud service to store your information
      – Cross platform
      – Built in encryption (and tokens if you want it)
      – Automatic backup if you use it in concert with Dropbox
      – Suggests random passwords for you, and can even make them ‘pronounceable’ so they are easier to type
      – Gives you feedback on password strength
      – Allows simple copy and paste and even wipes the clipboard for you so your password isn’t sitting in memory indefinitely
      – The encryption mechanism is not tied to the OS/Filesystem

      What your suggesting is perfectly fine, but actually seems harder to use than KeePass to me. I will concede that the average user is quite familiar with word processors, but the average user is also not comfortable with file encryption.

    • “1. Go to the Internet and call up a random password generator.”

      Absolutely do not do this. Now some site you know nothing about has your password and IP address. While perhaps not directly exploitable, why take the risk? Plus, how do you know it is actually random?

      “2. Instruct it to use numerals, symbols, and both upper and lower case letters for passwords.”

      The goal is to maximize the entropy in the password. Using the full character set packs maximum entropy into the fewest characters. But the same result can be achieved with a longer password and smaller character set. In the rare case where the password needs to be actually typed, I find it faster and easier to enter a 30-character lower case and numeric password (or pass phrase) than a 15-character full character set password.

      “3. Use your word processor to create a document, but encrypt it before you save it.”

      Unless your word processor is specifically designed to manage cryptographic documents, the software is likely to leak your data to places you don’t know about but hackers can easily find, such as disk buffers, temp files, memory cache, etc. It’s a small risk, but an unnecessary one. Password management software is readily available and designed to avoid these issue. Don’t try to roll your own.

    • …or just use a good password manager. What you describe is basically what they do. I use Password Safe.

    • Ivan Arnaudov

      @Steve: respectfully, I think the advice you are giving out makes little sense.

      What you’re proposing does greatly increase inconvenience without real added benefits. Using a word processor to store passwords is plain silly in the day and age where you have reliable password generation and storage software tools that work either online and offline.

      Everything you suggest doing (use a random password generator, storing login credentials and encrypting the data) can be done automatically by tools like LastPass (online) or KeePass (offline) that are specifically designed to accommodate safe storage of sensitive data and have added benefits such as password history, 2-factor authentication and mobility, while offering much smaller chance of losing previously entered data due to accidents such as your cat jumping on your keyboard while you’ve left your password file open in your word processor and gone for a coffee or a smoke.

      If you’re really practicing what you’re preaching (storing your passwords in a .doc file) give KeePass a try and you will never look back.

  12. So for us oldtimers who can’t remember anything, do you have a recommendation for some app that really can keep our passwords straight without too much hassle.
    Thanks

  13. I guess we should now be worried about phishing campaigns, where the bad guys will pretend to be Netflix, Skype, Dropbox, … whatever.

  14. I’m a little confused because if there is a randomly generated salt to generate the hash of the password the hashes won’t match or have the same salt even if they are hashed the same way which most sites should be doing in 2016, using some kind of algorithm that not only hashes but salts the passwords or any other information that doesn’t need to be plaintext.

    I watched a talk about how facebook uses something they call the onion which is layers of different algorithms that they just add on to instead of resetting everyone’s password for each algorithm change they do, with this in mind I don’t think facebook simply converts them and matches hashes.

    Netflix on the other hand wouldn’t surprise me if they are still using some simple hashing algorithm like md5/sha1/sha256/sha512 with no salts.

    • So, there are two things to keep in mind:

      Good site takes your username+password+salt+hash algorithm and generates and stores a hash for your account.

      When you try to log into “Good site”, you give it your username and password, the site looks up the salt and hash algorithm, then it salts the password and hashes it. Finally it compares the output with the stored hash for your account. If they match, it concludes you might be you. It might decide to send you a 2FA challenge to prove that not only do you know your password but you have something that proves you’re you. Once it’s satisfied that you’re probably you, it gives you a token for its “session” which proves to it that you logged in at a certain point. For the duration of your session, your system returns that token to the server to prove you’ve logged in. (This is often stored as a cookie, but it could be anywhere.)

      When “Stupid site” stores a password, it has choices:
      1. it could skip the hashing (dumb)
      2. it could encrypt instead of hashing (dumb)
      3. it could skip salting (dumb)

      Let’s say that it just stores the password w/o salting, encrypting, or hashing. When (not if) their database is hacked, your username+password are now available.

      Anyone (you, hacker, goodsite), can try to log into “good site” with the password. Good site can do it directly (take username, lookup salt, lookup hash, salt password, apply hash, check output).

      Let’s say that the password is “encrypted”. First of all, encryption is reversible, hashing isn’t supposed to be. You don’t want to encrypt your password for this purpose, because inevitably, someone will find the decryption key. The general attack here is to take a bunch of common passwords (12345, hello, dadada) and try encrypting them with lots of possible encryption keys. You then compare these encrypted values against the values from the leak. When a set matches, you try to use that encryption key to decrypt the remainder of the set, if it works, you now have your key, and thus the plaintext to use above.

      Let’s say “dumb site” used a hash but didn’t salt. Well, you’re going to attack the dump in a similar manner, you basically try lots of hashes of lots of common passwords and see if there’s a match. The match identifies the hashing algorithm/constants, and once you have this, you can now run through a dictionary to look for words which when hashed w/ that algorithm result in matches — i.e. are the passwords.

      Now: you don’t have to do this work, there are special precompiled tables of these things, they’re called Rainbow tables [1].

      Anyway, you basically run things forward first to try to get a password which hashes to the dumped hash, and then taking that “recovered” password and hashing it against your database to see if it matches your user’s password hash.

      FWIW, hashes aren’t guaranteed to be unique. It’s possible to have 2 strings which both hash to the same value. Suppose that both “1235” and “help” hash to C#%!. If your user created an account with password “1235”, you don’t store “1235”, you store the hashed value (C#%!), if you in testing hash “help” and discover that it matches the hashed value (C#%!), it doesn’t matter to you that the user might have actually thought their password was “1235”, because if some attacker tries to use “help” as the password, your algorithm will let them, because the hash matches. — Obviously this isn’t a good hash algorithm, but the point is that you don’t actually care if the password the user thinks is the password when hashed matches the password, you care about whether leaked passwords that an attacker will try would work.

      [1] https://en.wikipedia.org/wiki/Rainbow_table

  15. What we need is something that is better than passwords, usable everywhere, and not dependent on a corporation (what if LastPass or some other password manager goes bankrupt?). (Pick any two…) Otherwise I’m carrying a USB key with a text file listing all my passwords. Or maybe a small notebook. Well, it lists a description of each password. Because there is no way I can remember all the passwords for the 20+ places I need to be able to log into, and the other places I want to be able to log into.

    • > what if LastPass or some other password manager goes bankrupt?

      Valid concern / good question.

      One reason I like LastPass is because everything (URL’s, user name, password, etc.) is stored locally. If LastPass goes belly-up, for me, it’s no more than an inconvenience.

    • PassSafe is a good, user friendly password manager that you can store on your USB.

    • LastPass and others have a mechanism to use their software even if they go poof. Sharing wouldn’t work of course but you can export your database locally and move them to a another solution.

    • One approach is to use multiple OAuth [1] providers. If each account service you visit allows multiple OAuth providers, then you could tie each account you create to them and move on w/ life.

      This of course means that your weakest link is the weakest of your OAuth providers, but practically, they’re almost certainly more secure than the passwords you would have picked otherwise. And even if you didn’t, the odds are that someone can chain a takeover of the one provider from the other (see @mat hack, covered here and elsewhere).

      *Please set up 2FA everywhere.

      [1] https://en.wikipedia.org/wiki/OAuth

    • Ivan Arnaudov

      @wiredog: even if LastPass (or other similar service) goes out of business, it is highly unlikely this will happen without the company giving their clients the chance to export their data. But still, there are things you could do to feel safer orр at least, save yourself time in such eventuality.

      For myself, I’ve solved the problem by using two services in tandem: LastPass is my day to day password manager but every couple of weeks I export everything from it and add it to a KeePass database. Unlike LastPass, KeePass is a standalone application that is yours to keep even if the developer pulls the plug, and all the data it keeps is always in your possession.

      Using a USB stick comes with its own set of problems: it is easy to lose or get stolen, and always remember flash memory will die on you without warning and file recovery may not be possible. Keeping your passwords file on several USB sticks to fight this requires you to keep them manually in sync which is risky on its own.

      The KeePass database I mentioned above is encrypted and presumably expensive to crack; many rich people and governments can do it but I believe it isn’t worth their time for plain folks like you and me. That is why I keep my KeePass file hidden in plain sight on my Dropbox where it gets synchronized among all my computers and I can access it whenever I want. If tomorrow LastPass vanishes, I will only have to recover the passwords I’ve changed or added since last exporting to KeePass which I find bearable (I have 600+ login credentials stored but that’s after 20+ years online…)

  16. Interesting arguments. But now you will have to carry around a book, with the current passwords? A page dedicated to each service you use, with flash paper so you can destroy yesterday’s 256 letter password. That has the same chance of being broken as the three or four letter signin you had? Right.

  17. @Sasa – My thoughts exactly. As always, guide users to manually log into the services to change passwords, and never ever click on the links in the emails.

  18. Requiring a password change via an email notification is 99% phishing. It has served me well to ignore any email that tells me to change my password. The only password change request that I’ll heed is post-login.

    Also, all the hash comparisons seem to rely on services not using strong password hashing and strong salting. Even weak passwords should be very hard to decrypt if all that is leaked is the hashed password. A well hashed password database breach should not be a big deal. It should take hackers a billion years to decrypt a well hashed password database.

    • “Requiring a password change via an email notification is 99% phishing. It has served me well to ignore any email that tells me to change my password. The only password change request that I’ll heed is post-login.”

      Uh, but then once someone has your password, they can then change the password, lock you out and change any recovery methods. You’d have no way to recover the account. And if you just ignore the emails and don’t change your password, then your leaked password is still going to be valid and someone may login at a later date.

      If it’s done this way then the password thief needs both your password to the site AND access to your email, which is going to be rare unless you stupidly used the same password for both.

      If you’re worried about phishing, type in the url just as the email recommends rather than clicking the link, and then change the password.

  19. @myrna walton: there are plenty of really good password managers out there that can help you “keep your passwords straight,” and can actually make your life easier, unlike home-grown solutions like Steve E suggested. 1Password, LastPass, KeePass, Dashlane, to name a few.

    @wiredog: if you worry about corporate ties of password managers, and worry about that company going bankrupt, maybe try an open-source one like KeePass, or Schneier’s “Password Safe”.

  20. I used to re-use multiple passwords quite a bit out of convenience just like anyone else. I stopped doing that when I found the Dashlane app. It made a world of difference in providing the security I wanted while still providing me convenience, plus it’s free.

  21. Thank you for the explanation. The messages from Netflix are annoying. As for having to change the password–WHY would anyone care if their Netflix account were compromised?

    I certainly don’t. I use my insecure password for Netflix because, well, there’s NOTHING anyone can do with my Netflix account.

    Get my banking info? Not unless Netflix has terrible security. Get my personal information for identity theft? No. Netflix doesn’t have anyone that’s not public.

    It’s funny. Netflix is the last company that needs to worry about security because it provides a commodity that can’t really be stolen or defrauded.

    • This is what I was going to ask. They can rate up movies/shows you don’t like and screw up your recommendations, I suppose. But other than that, what?

  22. renegadegrammarian

    reuse (noun)
    reuse (verb)
    reused
    reusing

    No hyphen in any of ’em.

    Unless you’re going by British rules: If in doubt, stick a hyphen in it.

  23. We are starting a similar practice at our company. We force password resets for usernames/passwords potentially leaked during somebody else’s breach. The problem is, the customers just go right back to using the same password! So now we’re trying to implement password reuse restrictions, but the business side is pushing back because they don’t want the customers to be “inconvenienced.”

  24. Theory: If you used the same password at all sites, but used a unique user name (or email address) at each site, then you are [relatively] impervious to the type of breach described in this article.

    True?

  25. Jeff Partridge

    What upsets me horribly is sites that restrict you to simple letters and numbers (no spaces)! These people are living in the stone age and I don’t do serious business with them (where possible).

  26. So I was informed Lifehacker/Gawker was compromised (last year?) and I wanted to just delete my account since I don’t use it anymore. Seems practical right? but nope, you can’t delete your own account.

    Even after changing the password, I hoped for an option to delete the account but nope, I can’t delete the account. Seems really idiotic to me.

    So I sent an e-mail to support and I still can’t delete the account (and they won’t delete it either … sigh).

    Guess I’ll just live with a red unlocked symbol when I read my e-mail in chrome. So much for the e-mail plug-in…. argghhh

    BTW great comments from the community