Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

The Best Way To Protect Real Passwords: Create Fake Ones 152

jfruh writes: Many security-savvy users have a password manager that stores their randomly-generated passwords — but if that manager is cracked, the gig is up. Some security researchers are suggesting a technique to stop this: a password manager that offers up fake passwords when an attacker tries and fails to crack it, which makes the process of figuring out if you've broken in much more difficult.
This discussion has been archived. No new comments can be posted.

The Best Way To Protect Real Passwords: Create Fake Ones

Comments Filter:
  • Difficult? (Score:4, Interesting)

    by qpqp ( 1969898 ) on Tuesday May 12, 2015 @07:32AM (#49671731)
    This just adds an extra step to automate: take the password and try to login. It's not like people are manually trying passwords...
    • by Anonymous Coward on Tuesday May 12, 2015 @07:36AM (#49671755)

      No, this will solve the problem once and for all.

      • Re: (Score:3, Funny)

        by GameboyRMH ( 1153867 )

        Oh, the fools! If only they'd built it with 2 layers of password spoofing! When will they learn!?!?

    • Re:Difficult? (Score:5, Interesting)

      by Chrisq ( 894406 ) on Tuesday May 12, 2015 @07:41AM (#49671775)

      This just adds an extra step to automate: take the password and try to login. It's not like people are manually trying passwords...

      That actually makes things a lot more difficult. Many systems have password lockout, meaning that you would lose access before cracking the manager. Also even if one does not have lockout the delay of an internet call will slow down the attempt rate significantly

    • Have unlimited fake ones then. Any keys will unlock your vault, only the right key will reveal the correct passwords. Good luck trying to login with unlimited attempts.

      • by Bengie ( 1121981 )
        This is how I was understanding it. Make the algorithm such that you can't detect password failures, you just get a different result.
    • by Anonymous Coward

      I've always heard that SSH keys are better than passwords. So I use them even with websites that don't use SSH.

      Here's what I do:

      1) I generate a new keypair using ssh-keygen.
      2) I put the public key in my GitHub repo, because the public key is meant to be shared.
      3) I use the private key as the password when I sign up for a new account on a web site. I copy and paste it into the password input since it's too big for me to type in.
      4) When I have to log in to the web site I copy and paste the private key into th

      • by smaddox ( 928261 )

        Or you could use a single private key to cryptographically sign your username concatenated with the site's host name, resulting in a site-specific, secure password. No need to store hundreds of passwords, just the usernames (which could be duplicated) and a single private key.

        I'm sure there are password managers out there that do this.

        (Disclaimer: IANACryptographer --- there may be something braindead about this scheme)

    • Re:Difficult? (Score:4, Informative)

      by wvmarle ( 1070040 ) on Tuesday May 12, 2015 @09:39AM (#49672631)

      Testing password against local file: about 1 microsecond.

      Testing password by trying to login to Facebook, Slashdot, Yahoo, etc: about 1 second.

      So if anything it's going to cut down your password test rates from a million a second to one a second. That's already a great hurdle for password crackers. This even before any rate-limiting by those websites kicks in.

      • Why would an automated system need to attempt more than one login with the "password" from the manager? Its not like it has to worry about typos.
        • by E-Rock ( 84950 )

          Because this system would show the attacker an account and password for every manager password entered.

          With a normal password manager, the attacker is told if they're right or wrong. With something like this, when it tries Password! on the manager, it gets results, just they're wrong and it has to try to use one to find out. Then it tries Password1 on the manager, gets results, has to test, etc. So it has to add a verification step and not just attack the password manager. Of course, you're likely to lo

    • by Zeroko ( 880939 )

      If only the passwords (& not usernames or URLs or whatnot) are encrypted & no checksum or other verification is used, then entering the wrong master password could very well cause it to decrypt to completely useless but structurally valid passwords.

      Of course, care would need to be taken to ensure the result is always valid...probably have a "password format" field that indicates what format the password is allowed to have (at least 1 of each of these types of character, at least 8 characters & n

  • I have a pile of post-its. One contains the passwords. The other contain also all kinds of notes, as well as old passwords and shopping lists. Main difference with the proposed method in TFA is that hackers may still have access to the digital fake passwords, but will never get my post-its.

    Obviously, these can get stolen too. But only a trusted select few people have physical access to this, and even they don't know which post-it to take. And no hacker is going to physically break into my place to look for

    • Don't be too sure. I recently had a 5x8" notebook (the physical paper kind) stolen while I was at a customer site (accessible to the public). They didn't take my wallet, tablet, phones or tools, but the notebook and pencil vanished. It even had my name & phone number in the cover, but, nothing.

      While it didn't contain any passwords (ok, it contained one IP address/router admin password but I changed it as soon as I got back), it did contain notes from that night that I would have liked to have for wrappi

  • by Parker Lewis ( 999165 ) on Tuesday May 12, 2015 @07:40AM (#49671769)
    We need a password managers manager!
  • Ceci n'est pas un password.
  • Over think (Score:4, Informative)

    by DarkOx ( 621550 ) on Tuesday May 12, 2015 @07:52AM (#49671847) Journal

    Honestly this should be pretty simple. The default operating mode of a password manager should be generate a password from PRNG data.

    Store the value encrypted with AES a key derived from a master password extended via PBKDF-2 or similar should be used for the cipher.

    Next apply the necessary mixture bitwise rules applied bytewise to the 'clear text' to ensure the password will contain type-able characters and accommodate character restrictions. (Something like x = ((x % 126); x = x | 32 if x 32; for those of us using ascii and yes its not perfect and will produce some bias maybe a crypto expert could propose a better alternative ) Store which rules must be applied as well. That should not be an information leak as the attacker probably can research the target system and divine these requirements anyway.

    That will mean most of your passwords are nearly random goblody gook. (Important). No matter what master password is used a key can be derived, the decipher operations and the rules can be applied the result will appear to be a legal password, but it will be incorrect. In the event you have stored a specific less random value it should 'decipher' as well but appear highly random given that is how all your other password appear to be it will not be a strong indicator the wrong key has been chosen either.

    • Re:Over think (Score:5, Informative)

      by Kiwikwi ( 2734467 ) on Tuesday May 12, 2015 @08:42AM (#49672141)

      The NoCrack authors mention this briefly in their paper (PDF) [jbonneau.com]. They call the approach you describe "stateless password managers", and briefly describe some of the drawbacks of the approach:

      Chiasson et al. conducted a usability study of both PwdHash and Password Multiplier and found the majority of users could not successfully use them as intended to generate strong passwords. Another usability challenge is dealing with sites with a password policy banning the output of the password hash.

      But yeah, I'm not convinced the problems they highlight are intractable, nor that NoCrack solves them.

      • by Kjella ( 173770 )

        NoCrack seems extremely vulnerable to a crack since they create decoys on the fly. It should be fairly trivial to pick it apart and tell when you're getting a real password from the vault. As for the stateless password managers, they operate without any kind of wallet which is their problem. Also you can't change password for any reason, that's a problem too. If you have a wallet most the problems go away. I'm thinking as follows:

        The wallet stores a PRNG value to avoid various rainbow attacks. For each site

        • I do the same thing with sha256.

          echo -n "myseed+username+website" | sha256 | cut -c1-20

          echo -n "myseed+0100010001010011+slashdot.org" | sha256 | cut -c1-20

          I'm thinking about writing a base65 encode function for websites that require !@#$%^&*().

    • by asc99c ( 938635 )

      I'd guess the difficulty is that you want everything encrypted: that is, the password database will contain a list of website or server names, as well as the usernames and also the passwords. It's pretty difficult to distinguish between a valid and invalid password assuming they're generated randomly according to sets of rules. However, the rest of the data is likely to be human readable and full of standard dictionary words.

      So it's only easy to make the password database inscrutable upon attempted decryp

  • by aaaaaaargh! ( 1150173 ) on Tuesday May 12, 2015 @07:54AM (#49671859)

    As the maker of a password manager, I'm curious how this is supposed to work. The article is a bit sparse on information.

    Suppose I'm the attacker and after say, ten guesses the fake passwords are shown. So if I now save the passwords, will the original ones be overwritten? I guess not, since that would be rather inconvenient. So if not, will the fake passwords along with the master password and the original data be stored in the password database? Than the attacker can check the length of the original file after saving to determine whether he has obtained fake passwords. Or are they assuming some mysterious online password application where the user has no knowledge of where and how his passwords are stored? In that case, the application will be insecure anyway.

    I suppose the right way to make this work is by saving fake passwords (or the space for them) along with the real ones all the time but encrypt them separately with the fake master password after it has been created on the fly. Thinking about it, I might add this as an option to my program.

    • by hippo ( 107522 )

      If an attacker has your password file you should not be worried about saving the original passwords. Either your machine is stolen or your password database has been copied.

    • by gbjbaanb ( 229885 ) on Tuesday May 12, 2015 @08:22AM (#49672001)

      Possibly - but then the best way is just to let any password open the vault.

      You cannot crack a password DB if every attempt to open it succeeds. If your means of validating the password you used is to read a stored password, close the vault, reopen it and re-read the password to ensure its still the same.. then you've just added one heap of time to your cracking attack.

      Of course, a password vault could return the same set of fake passwords if you failed to supply the correct key (ie when you store a new password, the system generates a fake to store alongside it and returns the correct, or fake one depending on correct unlocking)

      No need to re-gen when the vault has been opened incorrectly, just return the bad passwords and let the attacker try to use them. What's even worse than having to re-open your vault to check the passwords are the same, is having to take one of those passwords and use it to attempt login to a 3rd party site to validate whether they were the correct passwords or not!!

      If you really want to be a bitch to attackers, you'll expose a few valid entries to honeypots (with passwords that work) so the attacker may think he's got the correct unlock :-)

      • by rsborg ( 111459 )

        Possibly - but then the best way is just to let any password open the vault.

        This is highly undesirable. Even knowing which services I find worthy enough to include in my vault is important. If the attacker knows my gmail, linkedin, or more niche account username, and doesn't see it in the vault, then they will get suspicious.

    • by Kiwikwi ( 2734467 ) on Tuesday May 12, 2015 @08:37AM (#49672095)

      What you're proposing sounds like Kamouflage (PDF link from TFA) [bojinov.org], with only 1 decoy password set (Kamouflage suggest 10,000); and suffers from the problem of generating plausible fake master passwords without revealing anything about the real master password, as mentioned by the authors of NoCrack.

      What the NoCrack authors try to achieve is a solution where every incorrect guess at the master password still provides a set of (incorrect but at least sometimes plausible) passwords. A bit like a one-time pad, which is the only provably secure encryption, because brute-forcing the key yields all the possible plain texts (both the correct and all the incorrect ones). Of course, the problem with the one-time pad is that the key length matches the plain text length, which would completely eliminate the benefit of a password manager. Additionally, as noted in TFA, authorized users might not like the idea that making a typo when entering the master password yields (seemingly) correct passwords. :-)

      I'm not convinced the NoCrack authors have actually succeeded, as they claim, but can nevertheless recommend the NoCrack paper (PDF) [jbonneau.com], since it discusses pros of cons of the approach and alternatives.

      • Count me amongst the skeptics.

        What the NoCrack authors try to achieve is a solution where every incorrect guess at the master password still provides a set of (incorrect but at least sometimes plausible) passwords.

        That's a bad design. If the attacker can access the password file, then he will usually also be able to save your fake passwords from within the password manager. Think about your wife trying to find out the password for your porn collection. So either she may (perhaps inadvertently) delete the original ones, which would be a disaster, or you need to have padding space in the original file so the attacker cannot detect that you have saved the additional files. And you cannot ha

  • by 140Mandak262Jamuna ( 970587 ) on Tuesday May 12, 2015 @07:59AM (#49671885) Journal
    I know of one small software company that used some home grown licensing method. The software will check out licenses for features at run time. Some features would appear to be legitimate, something that is going to be released soon. But those features were never sold, and if the license manager approves those features the product knows the license manager is probably cracked. It won't report any "ha! you are using a cracked license manager", it would quietly chug along for a while and crash randomly. The pirates who crack software would think they have cracked it and sell it as warez. The buyers will get some unreliable software, possibly reducing the "trust" on the warez hacker and sowing discord among the pirates and their customers.

    P.S: company eventually got sold to a bigger player and the home grown license manager was retired for industry standard "FlexLm". Soon after, ALL software using Flex were cracked and sold on the warez sites. Pirates could have easily cracked the license manager of that small company, but it is too small to be worth the effort.

    Moral of the story: Monoculture is bad, both for Irish potato farmers of the 18th century and license/password managers of the 21st century.

    • by kbg ( 241421 )

      Actually what will happens is that some users will use a cracked version as some sort of trial and then buy the real version if they are satisfied with the program. This is what I have sometimes done when the software doesn't have any trial versions available to test. But if you have quiet crashes, corruption or weirdness in your program the users will think that your program is just really crappy, stop using it and never buy it.

    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday May 12, 2015 @08:27AM (#49672037) Homepage Journal

      The buyers will get some unreliable software, possibly reducing the "trust" on the warez hacker and sowing discord among the pirates and their customers.

      Ah, naivete. Any time I feel like humans are smart, I just come here and read, and I'm cured. Guess what? The unreliable software was being used as a trial by potential future customers, who just decided it was a massive pile of shit and used a competitor's software. If they ever actually made money with the software, then they bought it. Their competitors thank them for their sophomoric DRM scheme which guaranteed that everyone thought their software was shit.

      Moral of the story: DRM is stupid, an people who think tricky DRM which shits on potential future customers is cool are also stupid.

      • That company was offering free trial with tech support and free training. Free university versions. Why would you pay real money to a hacker when you can legitimately get the same uncracked software with tech support? The company was small, user base was small some 2000 seats or so, but the price was not. It was selling the software at 50K$ a seat. Upgrades and support went at 15% of the list price, even if the first sale was discounted.
        • So you got the full, unlocked version? Not that it matters, because everything I said stands. Lots of people don't want to mess with all of that noise.

          • How many 50K$/ seat software is given away like you say? This software is not bought for personal use. Legitimate corporations and businesses with good reputation will go through *all* the hassles, sign non disclosure agreements, go through rigorous evaluation process. The only ones pirating these software are those who would/could never pay for legitimate licenses.

            I agree with you DRM for music/video does not work, and most people would pay for hassle free legal access and those who pirate would never bu

            • The only ones pirating these software are those who would/could never pay for legitimate licenses.

              No, you missed the point. If this software is so valuable, why? If it is for support, the "pirates" are not receiving support. If it is for the money-making potential of the software, if the unpaying users actually make money with it, they become far more likely to pay for it, not less. This is precisely what I was talking about to begin with. Adobe is shooting themselves in the foot by making Creative Suite subscription-based, because it just drives people to alternatives when it's harder to copy Adobe sof

      • Ah, naivete. Any time I feel like humans are smart, I just come here and read, and I'm cured.

        Just skimming through your post, I see that you've incorrectly assumed the following:
        1) That those illegal downloads represented lost sales. Haven't the RIAA and MPAA taught you anything about the faultiness of that logic?

        2) That the people torrenting the software were potential customers to begin with. When it comes to B2B software, which is what is being discussed here, there are established channels for procuring demos or trials of software. You don't torrent it unless you never had any plans to be a cus

        • That those illegal downloads represented lost sales.

          Too bad you can't read. That's not what I said at all.

          When it comes to B2B software, which is what is being discussed here, there are established channels for procuring demos or trials of software.

          Some people don't want to dick with your established channels, because they don't trust your salesdroids and don't want to talk to them. If you follow established channels, you usually get sales spam for the rest of your life.

          That a competitor even existed.

          Show otherwise, and I'll show you're wrong.

          If the recent examples of pirated games being crippled are anything to go by, people are finding them "hilarious", rather than being upset.

          They aren't, because we're talking about business software. You must have serious ADHD because you can't stay on topic for more than a couple of seconds.

          That pirates of B2B software complain about the quality of the software.

          They don't complain. They use someth

      • Ah, naivete. Any time I feel like humans are smart, I just come here and read, and I'm cured.

        Some humans did go to the Moon. I cling to that when I feel myself sinking in the Slough of Despond.

    • by tazan ( 652775 )
      Atari did that with the video game Tempest. Then someone forgot and made a change that caused the test to fail and legitimate customers got the "random" memory corruption. Then someone figured out you could use the corruption to get free games, so it was a happy ending after all.
    • by Zalbik ( 308903 )

      . The buyers will get some unreliable software, possibly reducing the "trust" on the warez hacker and sowing discord among the pirates and their customers.

      More likely, I would think this would reduce the trust of the software and original software developer. After all, the software appears to be working, other than the "bugs". Most users aren't sophisticated enough to think "maybe that shady warez site did something that affected the original software!", they'll just think the original software is crap

  • "There is, however, one large problem: What if a person mistypes a password? In that scenario, a fake vault is generated, and a user is locked out of his or her accounts."

    This is the weak point - It forces the user, or the system, to generate an additional artifact to inform the user (but hopefully not the attacker) that the password safe is correctly unlocked.

    "One possible fix is to create a hash of the master password that is linked to an image that is shown when the password is entered. The authorized user should recognize when the wrong image is displayed, but an attacker would not."

    I'd expect this one image to be shown only when the master password is entered. i.e. it is an unique indicator. Fake images will need to be generated for all other passwords, and if there are duplicates then they can be eliminated as false-positives. Strategies like this will always be the weak point. It's commenda

  • Am I the only one who thought to himself "Do I actually have anything to hide that would justify this much effort?"

    If somebody hacks my ebanking account, chances are the bank would be liable unless they could prove I have been negligent. And besides, this whole security thing becomes rather funny when you think that my bank is the only site which limits my password length to seven digits.

    This is like a company that puts up draconian password restrictions, does not trust just hypervisors but also switches, c

    • Re:Paranoia (Score:4, Insightful)

      by rhsanborn ( 773855 ) on Tuesday May 12, 2015 @08:53AM (#49672213)
      It's better to ask these questions now, before we do have things to hide, like ebanking info. It's been considered that chip-and-pin would eventually push the liability for lost funds onto the consumer on the assumption that the consumer was negligent in losing his PIN. Bitcoin is another example of a thing that if you lose it, it's gone. It's not mainstream now, but I have heard of the Canadian mint experimenting with encrypted digital copies of it's currency (to allow electronic transactions, but ostensibly to make sure the Canadian government is notified of transactions so they can take a tax cut). It's conceivable you would have little to no recourse in recovering these funds. It's better to have the tools before we need them.
    • Do you want to find out if the bank really is liable? How many hoops, lawyers, and time will it take to be resolved?
      • I seem to remember a case in Britain a few years ago: a man found that his bank account had been broken into and some money stolen. He reported this to the bank. The bank had him arrested on suspicion of fraud. They claimed their security was so good that no one could possibly have broken in; therefore, ipso facto, he must be lying. He must have withdrawn the money himself and was fraudulently attempting to get a reimbursement. He was eventually exonerated, but the experience is not one to be recommended. I
  • by Anonymous Coward

    this would be improved if the password manager provided a password that when used, an alert was issued and actions were taken

  • by Anonymous Coward

    This security mechanism is pointless. The only way that this would work is through obscurity. If you know the algorithm to check the data file itself in the same way the password manager does, you just offline attack the actual database. Once you reverse engineer the password vault software's behavior, you can go straight to the file instead of being a dumbass and typing things into the program itself.

    I can't think of a single attacker (other than maybe a teen's mom) that would repeatedly type passwords

    • +1
    • by asc99c ( 938635 )
      Which is the clever bit if your read the TFA:

      We take a significantly different approach. Instead of explicitly storing decoy vaults, we construct single ciphertext which, when decrypted with any wrong master password, yields a decoy vault that appears to have been sampled from the distribution of plaintext vaults (across the entire user population). This approach is inspired by the theory of honey encryption [23].

      Still not certain I understand how that works, but it certainly isn't an obvious or trivial approach to take.

  • The problem with giving out a fake password would be that the real user ends up locked out of sites or systems due to too many bad password attempts.

  • I use a password manager. It has a very strong a password on it. Is it really that hard for people to remember just one really strong password?
    • by ledow ( 319597 )

      When I was a child:
      My parents used to know the phone numbers of every family member off by heart.

      When I was a teenager:
      I could recite pi to hundreds of decimals places after creating a program that ran on an Amstrad PCW9256 to calculate it (I had to check the answer!), and I still can just from memory. I memorised an entire Shakespeare sonnet just because I needed to for a drama production. I still know it - word-for-word - to this day.

      Since then:
      I memorise and use dozens of passwords every year. I have

      • If you aren't famiiar with password managers they ease a lot of pain. You won't need to remember those insecure passwords for unimportant sites or even the secure password for your bank, just the one for the password manager. Lastpass.com will lead you to one of them.
        • by ledow ( 319597 )

          I do not trust any software with my password. Sorry. Certainly not EVERY password I have - some of my passwords literally only exist as a hashed and salted version, and in my brain.

          Nor would I trust a basic user downloading something that claims to hold all their passwords, or to know to only put their "master" password into that app, or to not forget their master password, or to install it on all the devices they have so that losing their phone / laptop doesn't lose all their passwords etc. It's a silly

          • by rokstar ( 865523 )
            I juggle around a half dozen or so strong passwords on a yearly basis in the same way you do. I also was wary of trusting my passwords with some sort of password manager, then I started using pass. If you trust gpg and can do a 600 line audit of a bash script (which is feasible for one person to do by themselves), you get a really nice and simple cli password manager. Oh an no cloud stuff, you can use git to make backups however to other machines or just tar up the password directory every now and again.
  • Deception (Score:4, Interesting)

    by Dan East ( 318230 ) on Tuesday May 12, 2015 @08:46AM (#49672179) Journal

    Deception is a valid form of security, similar to obfuscation. It should not be relied upon, but it is merely another layer. In the early 90s me and some buddies ran a multi-node BBS. One of the admins used the same password on another BBS, and someone was able to log into our system using his admin account. So to prevent that from ever happening again, I wrote a script that, for the three site admins, would also ask for their birthdate every time they logged in. If an incorrect date was entered a single time, the account would be locked. Thing is, it wasn't our birthdates that we had to enter, but just another very short password that we could enter really easily. So an attacker, if they got to that point again (obtained the password), would give it their best guess (or perhaps even research to find) the admin's birthdate. If any date was entered at all (containing two slashes or hyphens) the account was immediately locked, because the expected password was just a couple letters is all, and anyone entering an actual date was not an admin.

    • Comment removed based on user account deletion
      • by awing0 ( 545366 )

        So the car is like a fake car that drives you to the wrong building? Or does it do its best to kill you somehow?

    • So anyone could render your account inoperative by just knowing your login and entering wrong info ?
    • by sudon't ( 580652 )

      Right. These "security questions" web sites have you set up now, like "mother's maiden name", and such? I use some completely unrelated information. That way, if someone does the research, or an ex-lover wants in, they won't be able to use that information.
      But having your password manager compromised is a rare situation. If everyone used them, and used them properly, we would have no need of these two-step authentication schemes.

  • I assume this solution would be based around the app providing bogus passwords if you enter a bad master password. I suppose that would be something you could do for foiling the petty pickpocket or keystone cop. But surely any attacker that actually plans to succeed will use a cryptographic attack against the data store, not poke random keys on the UI.

    I have wondered before if security could be improved by storing an encrypted file inside another encrypted file, ideally with different schemes. But from

  • Have the password manager generate multiple passwords for each site. Associate each one with a randomly selected image. When the user wants to retrieve the password from the password manager, show all of the images and associated passwords. User will know which password is the correct one and which are equally-random gibberish. However, anybody cracking the database has a set of key-value pairs. The user would know which image is correct. An attacker not so much. The database doesn't know which one
  • I can't believe I don't see this anywhere in the comments yet, but this is the bigger issue at hand. https://xkcd.com/538/ [xkcd.com]
    • by Jeremi ( 14640 )

      Of course, the wrench technique only works if the attackers have physical access to your body. Most Internet hackers aren't going to be located physically near you (and hopefully most of them wouldn't have the stomach for that either).

  • There exist a number of entries in my password manager that wouldn't cause me concern if someone learned the password, mostly login-to-comment stuff, but also a few merchants that don't have any payment information stored. If a password manager is going to give out fake passwords, it might help to have a "keep it secure" check box for making a new database entry. Then, those passwords would be available and pass a test when login to the password vault program fails, and also, if I'm using the vault to look
  • This reminds me of a question I had about securing a linux server.

    We all know it's quite good practice to move the SSH connection from port 22 to some arbitrary high port. But of course if attacker finds nothing on port 22 he's just going to start port scanning until he gets it.

    Way better would be for port 22 to respond as a valid SSH server but to reject ALL username and password combinations EVEN THE CORRECT ONES.

    Only drawback I can see is when I forget I moved the SSH port and get confused when my passw

  • now: crack the master password with five million guesses per second on your cluster
    then: search the ten services with weakest security (as many guesses as you want), start to brute-force the generated passwords for random master-passwords until ones works with 10 services, which allow one (confirmed correct/incorrect) login in two seconds. And may inform you of the cracking attempt.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...