scrypt+(20 characters for a master password)=impregnable?

debiantriage's Avatar

debiantriage

06 Sep, 2017 05:34 PM

What I take away from the answer to this question is

  • Forget about the master key ever being brute forced.
  • Brute forcing the master password is very challenging in time and cost terms.

Suppose mpw was used thusly to obtain a 20 character password:

mpw -u debiantriage -t max  masterpasswordnovice

The password's only purpose is to act as the master password to generate all other passwords.

Does this give a substantial increase in security? Even if it does, is it making a basically simple process a tag too complex? Would a user be just as well off with Bananacolouredrubberducky?

Regards,

Brian.

  1. Support Staff 1 Posted by Maarten Billemo... on 07 Sep, 2017 12:14 AM

    Maarten Billemont's Avatar

    It's certainly true that the larger your master password is, the more secure your passwords will be, but if you're suggesting using the output of mpw as a master password, a few considerations:

    1. Your master password should be a password that is both memorable and easily typeable so that you can manually and independently enter it into any master password client whenever you want to look up your passwords.
    2. If your master password is the output of mpw, it is really still a product of another master password, which will not be an mpw output password. All you're really doing is duplicating scrypt here and in the process, complicating your passwords access and making it harder to get them if you don't have access to your custom mpw+mpw script.
  2. Maarten Billemont closed this discussion on 07 Sep, 2017 12:14 AM.

  3. debiantriage re-opened this discussion on 07 Sep, 2017 04:40 PM

  4. 2 Posted by debiantriage on 07 Sep, 2017 04:40 PM

    debiantriage's Avatar

    I've decided to stop worrying about a compromise of a provider's database which gives an attacker access to hashed passwords, partly because how the database is stored and how my password is processed is outside my control and not my responsibility. I have also decided the scheme I outlined is indeed needlessly complicated and doesn't gain anyone very much.

    It is more comfortable to recall a single strong master password and do a single copy and paste rather than jump through other hoops. The website name can be written down or got from the browser. The full name can be in ~/.bashrc. I'll forgo the rocket science and second guessing.

    Cheers,

    Brian.

  5. Support Staff 3 Posted by Maarten Billemo... on 07 Sep, 2017 04:45 PM

    Maarten Billemont's Avatar

    Certainly there's little that can be done to protect yourself against security flaws in a website's infrastructure.

    The best we can do is:
    1. Ensure that when we give out a password to a website, that password is essentially independent of everything else. ie. you can't derive any access additional access or information from this password (which essentially means, don't reuse passwords for different sites). MP does this well.
    2. Ensure that the passwords we give out to a website are as high in entropy as feasible, and are cryptographically random, so that they are not guessable and if the website leaks hashes, reversing those hashes is hard. MP does this, and if you want to improve on it, you can use the maximum template instead of the default long template, though long should be good enough.

  6. Maarten Billemont closed this discussion on 07 Sep, 2017 04:45 PM.

  7. debiantriage re-opened this discussion on 08 Sep, 2017 07:01 PM

  8. 4 Posted by debiantriage on 08 Sep, 2017 07:01 PM

    debiantriage's Avatar

    ...don't reuse passwords for different sites). MP does this well.

    It does, but can we look at the premise.

    Not reusing a password is a defence against sites which do not hash passwords. For that reason I would agree with you. The password's entropy is reduced to zero when leaked from such a site.

    Using the same 20 char password on sites which do hash is defensible on the grounds that the password does not become weaker when the hash is leaked.

    Very unfortunately, all the web pages and provider's websites which advise not to use the same password on all sites do not make it at all clear why it might be a bad idea. If the sites you use are known to hash passwords (knowing is the main problem) and you use a really strong password, I cannot see the disadvantage. The hash might not be the best but your 20 characters is surely sufficient.

    Why couldn't the output of

    head -c 16 /dev/urandom | base64 | cut -c -20
    

    be used on multiple sites?

    Setting up an account involves striking a bargain between user and provider, The user undertakes to provide a decent password and the provider undertakes to look after it. All too often both sides renege.

    Cheers,

    Brian.

  9. Support Staff 5 Posted by Maarten Billemo... on 08 Sep, 2017 07:36 PM

    Maarten Billemont's Avatar

    Not reusing a password is a defence against sites which do not hash passwords

    Incorrect.

    Not reusing a password is important because whenever you re-use a password between company X and company Y, you are essentially creating a situation where company X can now access your account at company Y. And by extension, when company X is hacked, the hackers can now enter your account at both X and Y.

    1. Completely irrelevant to any kind of hashing: when you enter your password on website X, it is in clear-text. It goes over the internet. It arrives on X's server in clear-text. X's software processes this clear-text password. Any trojan at X can see your password. Any sysadmin at X can do the same. In essence: whether X does hashing (badly or even very well) doesn't matter. When you give X a password of yours, you MUST assume that everyone at X has theoretical access to this password. That means, the people who work at X can take your password and try to log into Y with it.

    2. Let's ASSUME that X hashes your password and stores the hash. If they do so rather naively with a SHA256, imagine your password is "secret bananas". SHA256("secret bananas") = 1d5b4d7e813ac52b47084e47532b324a78f243718e4065530e8d658dc7a81103. Now X stores this hash. Now you make an account at Y and Y also stores your password using hashing, the same way. Now company X gets hacked. Hackers control X's servers. They download a list of all password hashes, getting your password hash. Now they wait for you to log into your account, enter your account password, see the clear-text password come in to X's servers. Now they know your password is "secret bananas". If these hackers can now obtain a leaked list of hashes from Y, they will see that your hash for Y is the same as your hash for X, and that will tell them your Y password is the same as your X password.
      Granted, good password hashing will salt the password's hash meaning this will not be an issue, but you really can't rely on your websites doing things right behind the scenes.

    In essence: if you want to be 100% sure, just isolate every website using a unique password. Now there is no need for trust and no risk that one compromised website will compromise your other accounts.

  10. 6 Posted by debiantriage on 08 Sep, 2017 09:53 PM

    debiantriage's Avatar

    In essence: if you want to be 100% sure, just isolate every website using a unique password. Now there is no need for trust and no risk that one compromised website will compromise your other accounts

    Your explanation makes sense. "Compromise" is such a wide-ranging term and, as you point out, includes ill-intentioned or incompetent sysadmins or other staff at company X or comany Y. By signing up with company X you are implicitly trusting them, but there is no need to link company Y with this particular trust framework by sharing passwords.

    Thank you for putting some perpective on this.

    Cheers,

    Brian.

  11. Support Staff 7 Posted by Maarten Billemo... on 08 Sep, 2017 10:35 PM

    Maarten Billemont's Avatar

    By signing up with company X you are implicitly trusting them

    True, but trust is never absolute and always contextual. You trust someone "with something". Not with everything ever. You sign up with X, that means you trust that X will handle your X things with some degree of professionalism. Using technical measures to enforce those trust boundaries is smart, lest they be abused intentionally or accidentally.

  12. 8 Posted by debiantriage on 09 Sep, 2017 05:59 PM

    debiantriage's Avatar

    I couldn't agree more. X only needs enough to enable to you to log into X.

    And yet - those credit card details you sent to X? That is rather absolute in my terms of internet use. Trust? What technical measures exist to enforce the limits of your trust? (This is probably getting beyond the scope of what mpw is intended to do, so feel free to bring it back on topic).

    Cheers,

    Brian.

  13. Support Staff 9 Posted by Maarten Billemo... on 09 Sep, 2017 06:26 PM

    Maarten Billemont's Avatar

    Well, yeah, mpw doesn't yet allow you to generate and apply for a site-specific credit card number.

  14. 10 Posted by debiantriage on 09 Sep, 2017 07:14 PM

    debiantriage's Avatar

    I'd be rather disappointed if mpw attempted to do this, It should do what it does now and do it as well as it can.

    Enjoying password security, cheers

    Brian

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

15 Sep, 2017 06:37 PM
09 Sep, 2017 08:54 PM
09 Sep, 2017 07:14 PM
07 Sep, 2017 06:26 PM
01 Sep, 2017 10:47 AM

 

01 Sep, 2017 07:46 AM
09 Aug, 2017 03:59 AM
08 Aug, 2017 03:34 PM
27 Jul, 2017 10:48 PM
23 Jul, 2017 10:43 PM
21 Jul, 2017 09:18 AM