I used to do something very similar to this, for around 5 years. It works fairly well, but I've moved away from it largely because: There are always exceptions that won't work (you can't have one scheme that both satisfies "you must have one special character" and "you cannot have any special characters"), and it also doesn't let you change your password for a site. I was able to come up with something that worked in 95% of the cases, it was the 5% that got me to stop using it.

That's what the incrementing variable is for. Of course, you have to then remember how many times you've changed your password for any given site.

That works until you visit the website for my insurance company...

"You must use one of these special characters: %^&*()"

How does incrementing a counter address some sites requiring special characters while others reject them?

The counter only addresses requirements to change password periodically. The special character requirement is addressed by tacking on 'Aa$1' to all passwords (they asked for it; it's what I tacked to all the (good) passwords I memorized even before I had this method).

All your passwords have special characters. Some places do not accept special characters in passwords.

This is what your scheme doesn't address.

Disadvantages:

- You have to keep track of n for every site.

- If the master password is compromised, you have to change each password manually.

- Not well-integrated with browsers.

- Far less convenience on a phone.

> - You have to keep track of n for every site.

I consider this far better than having to keep a password manager's database. n = 0 for the vast majority of sites without sensitive personal data. For the small handful that need to change, I usually sync them all to the same value of n about once or twice a year.

> - Not well-integrated with browsers.

I use Chrome's password-saving feature for websites that don't store sensitive personal data. For websites that I consider sensitive, I actually like that it isn't integrated with the browser.

> - Far less convenience on a phone.

This is true. If my laptop can act as a bluetooth keyboard to my phone it might make life easier.

At this point, couldn't you keep the list of domains/n's in a plain text file? You still don't have the master password.

Re:Bluetooth I use AirDroid for this. It works as a vnc client not as a Bluetooth keyboard.

I use https://pwdhash.com with _n_ suffixed to the master password.

- If last few recent n's don't work, I just reset the password to the most recent n.

- There are browser extensions

- There are apps, and my web UI (https://ph.leftium.com) works OK (and a bookmarklet adds more convenience)

The problem with this solution is that it is only as strong as your master password. Because you suggest to 'never write or store [it] anywhere' it can't be strong enough. To say it in Bruce Schneier's words: "Pretty much anything that can be remembered can be cracked."[1]

[1] https://boingboing.net/2014/02/25/choosing-a-secure-password...

I memorized 1024 digits of pi in high school. I can deal with a strong password.

Keep in mind that most password managers also encrypt your password database with your master password, so my solution isn't any worse than those.

Memorizing a even a 16-character (upper/lower + symbols) random string as your master password would be 16*6 = 96 bits of entropy which is more than enough.

Dealing with memorizing ONE good 16-character random string is within the abilities of most people. Dealing with multiple ones is what is hard.

I don't question your memory, that is not my point. How long do you think it takes to crack a password that consists of digits of Pi or anything derived from it? And it's not about Pi either, it's just that you can't beat a computer in that regard.

For me, playing around with hashcat, was an eye opening experience and I truly believe in the Schneier quote from above.

Create a 10 word diceware passphrase, using the EFF's list. Try to memorize it, it shouldn't take long. Hash it with whatever hash you like. Even MD5. Try to crack it with Haschat. Spend as much time and/or money as you like on the project. It's got over 128 bits of entropy, you won't succeed before the Sun becomes a red giant and incinerates the Earth.

I agree with Schneier's quote, but you're also forgetting about password hashing. If it takes 10 seconds to derive the key (assuming the use of a strong hash function), anything with a good enough amount of entropy (60-90 bits) should be fine.

When an attacker acquires a leaked database, they're not cracking high entropic passwords.

Yes, what speaks for dheera's method is the use of a strong KDF and especially (a point that I missed initially) that they use a truly random master password.

The standard password manager is slightly better because the password database works like a 2nd factor.

Also, a character has at most 8 bits of entropy, not 64. If you use base 64 its only 6 bits of entropy. 16 x 6 = 96 bits is still more than enough though.

A downside if everyone used this scheme would be parallelized attacks on reversing the hash for the key. If you find a key that, with this scheme, creates a password for your service, you found the corresponding secret key. This then compromises all of that users passwords.

Sorry early morning here, I actually fixed that before I saw your comment -- more like 6 bits per character. In any case more than good enough.

I actually am not a fan of 2nd-factor authentication (e.g. phone). If you lose the physical thing or it gets leaked to a stranger, gunman who mugs you, leaked by security holes in the thing's own embedded OS, it's no longer helping your security. I'd rather authentication depend on only what's in my mind and body and nothing external. Also, I lose stuff and forget stuff pretty easily, so I often just avoid carrying anything.

Which technique did you use? I made it to around 150 using the memory palace technique from the excellent book Moonwalking with Einstein.

I'm not sure what the various methods are called or what they are -- never really researched it. I just memorized about 10 digits every day over the course of a summer. Every day I practiced typing out the entire thing a few times as well as practiced the most-recent 100-block several more times.

That's very impressive!

And I thought my memorizing 100 digits was an achievement

"Pretty much anything that can be remembered can be cracked."

Randomly choose 6 words from a 10k English dictionary and you're set. Hell, make it 12 words. Still insanely easier to remember than a 12 character alphanumeric/symbol password, and much more difficult to crack.

I'm partial to using a very broad dictionary: http://app.aspell.net/create?max_size=35&spelling=US&max_var....

It has 50,105 words. Gets you an extra 2.3 bits per word.

Better yet, use the EFF's Diceware list. It's easy to pick randomly from the list (just roll some dice) and the resulting passphrase won't have some of the issues a dictonary chosen one would have, like compound words causing entropy reductions. (EG if fire, truck, and firetruck are included in the dictionary as 3 separate words and you happen to get fire and truck in sequence as part of your passphrase the entropy of those two words is equivalent to the entropy of a single word! Not good.)

> if fire, truck, and firetruck are included in the dictionary as 3 separate words and you happen to get fire and truck in sequence as part of your passphrase the entropy of those two words is equivalent to the entropy of a single word

Not exactly true if they are separate words. In a word-based password scheme, you are treating entire words, not characters, as units. The chance of fire, truck, and firetruck appearing in one password in that sequence, given a 10K word dictionary, is 1/(10K^3). The miniscule possibility of this speaks to the fact that there actually is a large entropy.

I realised after choosing random words that gets annoyingly long to type. In that regard, random characters are better.

What about [1]?

"green rubber yellowed out inside the 1st horizon"

I make random passwords like that (though usually 6+ words) all the time. I admit I can't remember all of them, but I can remember up to ten or twelve. Which is enough passwords to cover all the important services I use.

The big pain with that is that some services don't allow more than N characters for passwords (looking at you, 20-characters-limit-PayPal), some services don't allow spaces and whatnot, so you have to adapt.

Plus, you should enable 2FA wherever possible. You don't really need a super strong password once you have 2FA, so for those cases you can resort to OP solution of having "master_password + 'whatever' + domain" with master password being one of those ten you can actually remember and not even having to encrypt the whole thing.

[1] https://www.xkcd.com/936/

Maybe you have something that calculates what is strong enough? Is there some online calculator?

Online calculator for password strength, what a great idea!

I've got to offer one on my website (gimme all your passwords, mwahahaha!)

Yeah because that is what meant...

This is a long blog post that talks about some drawbacks of this approach: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

Before reading this I was convinced that stateless deterministic approaches like these was the ideal. But some arguments in that post changed my mind.

> Deterministic password generators cannot accommodate varying password policies without keeping state

16 characters + 'Aa$1' has universally satisfied every website I have used to date except Baidu (which imposes a maximum of 16 characters total on passwords). The number of exceptions to this is probably miniscule.

> Deterministic password generators cannot handle revocation of exposed passwords without keeping state

That's what 'n' is for. Either you can keep 'n' as a state variable which is much easier to manage (and if you lose the file, you can try a few values of n and get yourself back into those websites without much hassle), OR sync the values of n every several months on the sites that use it.

> Deterministic password managers can’t store existing secrets

This is orthogonal to the password problem. I store sensitive files that aren't passwords in a GPG-encrypted tarball on Dropbox.

> Exposure of the master password alone exposes all of your site passwords

This is true of stateful password managers as well, if you backup your database on anywhere insecure or any device (e.g. laptop) that could potentially be mugged at gunpoint, confiscated by border control, leaked by buggy software, etc.

He's uses _n_ for state, so it's not really state-less (in fact, issues 1 and 2 don't apply).

You shouldn't use hash functions designed for integrity, they're fast, fast is bad for password hashing, a single AMD graphics card can compute 200M guesses per second for single sha-512 iterations, instead use bcrypt, scrypr or any other hash function specifically designed for key stretching.

https://hashcat.net/hashcat/

https://en.m.wikipedia.org/wiki/Key_stretching

Yep, I'm using pbkdf2-hmac-sha256 which is not just sha-256. The 2nd link you posted mentions pbkdf2.

By the way, for those wondering about convenience, this will wait 3 seconds (during which you switch to your web browser and click the password field) and then it will "type" the password. (You do NOT want to cut-and-paste your password from a terminal as the clipboard can be read by anything.)

    # requires: sudo apt-get install xautomation for 'xte'

    import time
    from subprocess import Popen, PIPE

    macro = ""

    for char in password:
      if char == '$':
        macro += "keydown Shift_L\nkey 4\nkeyup Shift_L\n"
      elif char == '+':
        macro += "keydown Shift_L\nkey equal\nkeyup Shift_L\n"
      elif char == '/':
        macro += "key slash\n"
      elif char.isupper():
        macro += "keydown Shift_L\nkey %s\nkeyup Shift_L\n" % char
      elif char.islower() or char.isdigit():
        macro += "key %s\n" % char

    print("Entering password in 3 seconds ... [^C to abort]")
    time.sleep(3)

    Popen(['xte'], stdin=PIPE).communicate(macro.encode())

I cleaned it up a bit and added the missing keys: https://github.com/wridgers/pwtools/blob/master/bin/pwtype

This is exactly what http://masterpasswordapp.com/ provides.

One of the biggest drawbacks of this approach is that you are stuck with your master-password. You can't change it without modifying those for all the websites.

I do something similar, but the solution instead of `Aa$1` is to use the output to produce a shorter password with those properties [1]. Makes it a little easier to type in.

I also keep a list of the "domains" along with plaintext comments for each of them (username, email I used, etc) that are not strictly required (so still portable) but just make it a little more useful when it's synced.

The big downside I've found is lack of apps. Sure it would run on any phone, but I haven't managed to get it to run on the phones conveniently. So if I'm without a laptop right now for the most part I'm locked out.

[1] https://github.com/passwordly/passwordly-python/blob/master/...

>The 'Aa$1' is to ensure satisfaction of stupid password rules on various websites.

"Your password is too long"

One problem I had when using a similar technique is how to change passwords. Some services require regular password changes, security breaches require it, etc.

So I needed some additional piece of information, namely how many times I've had to change passwords, so a new function argument.

Eventually I gave up and started using a password manager.

That's what 'n' is for in the code above. There are only a small handful of sensitive websites I use that require frequent password changes and I usually sync them all to the same incremented value of n every few months.

Gotcha. I think that the manual effort of that was what put me off managing passwords myself.

Disadvantage: If any website you use has it's password database leaked, an attacker can then do an offline brute force attack to recover your master password. Then, the attacker can then generate your password to every other site you use, such as banks and email, just by trying a couple values of n.

That's the point of using PBKDF-HMAC-SHA256. As long as your master password is strong it's not going to be brute forceable for the forseeable future.

My point is that this is dangerous. The security of this method is equal to the strength of you master password + the least secure website you use. If that website has a password breach, the only thing standing between an attacker and a compromise of every website you use is the strength of you master key. (And GPUs are pretty good at brute forcing PBKDF2 - so it has to be really strong.)

This is unlike a stateful password manager. There the security of the system is related to the strength of your password + the strength of the security of the place you store your password db. If you pick a place that is serious about security, your almost certainly better off. Critically, a compromise of some random forum you signed up for doesn't impact the security of your bank account in any way.

> The security of this method is equal to the strength of you master password + the least secure website you use.

Not exactly. It's equal to the strength of your master password only. Even if one of your passwords leaked, this function does not compute fast enough in the forseeable future to brute force your master password, as long as your master password is strong.

> And GPUs are pretty good at brute forcing PBKDF2 - so it has to be really strong.

Interesting, thanks for telling me this. But how much better? I mean, a GPU with 1024 CUDA cores surely cannot surpass 1024 CPUs. So all we need to do is bump up 100000 to a slightly higher number to make it GPU-proof if that's the case, no?

> There the security of the system is related to the strength of your password + the strength of the security of the place you store your password db. If you pick a place that is serious about security, your almost certainly better off.

The problem is that it's difficult to find some places that is serious, and that you trust to be serious. Most people will end up putting it on Dropbox or Google Drive because there isn't anything else that is accessible to them and easy to use on a phone. Also, what if you're on vacation, PC rendered in an unbootable state, and you need to reinstall your OS? This has happened to me at least 3 times.

> Interesting, thanks for telling me this. But how much better? I mean, a GPU with 1024 CUDA cores surely cannot surpass 1024 CPUs. So all we need to do is bump up 100000 to a slightly higher number to make it GPU-proof if that's the case, no?

The weakness of PBKDF2 is that it requires a small fixed amount of memory to run, making it ideal for brute forcing with a GPU. Algorithms like Scrypt / Argon2 are designed to counter this by requiring lots of memory to run. Best reference I could find or current best GPU brute forcing speed is https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... - which seems to say that the test system could do like 100-200k password guesses / sec with PBKDF2-Sha256 @ 100,000 iterations (extrapolating from the numbers given).

I think the idea is that the master password can be memorable enough by picking say 6 random diceware words and still strong enough to resist all (pre-quantum) brute-force attacks for a long time.

The arithmetic then looks like this:

(7776 ^ 6) = 221073919720733357899776, because there are 7776 words in the diceware list.

(7776 ^ 6)/(10^12) = 221073919720 seconds to try all such password if the imagined hardware accelerated hash cracker can do one trillion hashes per second. In years this is:

(7776 ^ 6)/(10^12)/(365 * 24 * 60 * 60) = 7010 years.

So on average, it will take about 35 centuries to brute force the password when using hardware that can try one trillion guesses per second.

Yeah, in an ideal world... In the real world I'm coerced to use some apps and websites with shit security, and have to store stuff like PINs &c which impose a certain structure on the secret, and if I'm not misunderstanding, this can't help with that sort of secrets.

Wouldn't combining the "master_password", "domain" and your username/email save you from worrying about the "n" variable?

You are using "n" to differentiate from multiple accounts on "domain", right?.. or am I misunderstanding?

No, I'm using 'n' to deal with websites that periodically require you to change password and enforce that you use a new password

I suppose I could also do it as master_password + '/' + domain + str(n) or something like that.

Ahh, ok then how about using the DateTime at runtime? That would then save you from having to keep "n" stored elsewhere for future uses.

Edit: nevermind, this would prevent you from retrieving the password - I had in mind a password generator, sorry.

By the way it's generally not a good idea to use dates in password generation or for random seeds. An attacker who has any information about the approximate time you generated the password (e.g. minutes before registering for a site) would be able to iterate over those several thousand seconds.

For consumer use cases, you should use sources of noise for this, such as microphone noise, mouse movements, fluctuating voltages, etc. If you wanted to be super-secure you would use a quantum random number generator, which is truly random, but unnecessary for the threat models of most consumer uses. Just use anything but date/time. The random number generators of most modern languages and operating systems already have such measures in place.