So on Security Now 910 Steve Gibson was discussing using Base64 to generate a good password from a simple to remember base like Password12345678. What about using something like Scrypt or Argon2 for the same purpose? If done, would it matter too much what parameters you use in those algorithms so long as you remember what parameters you do and did use? Or does it not really matter so long as an attacker doesn’t know whether you used Base64, Base128, Scrypt, Argon etc? The point is the password is not found in a dictionary used in a dictionary attack?
From show notes:
Steve, I know we are all tired of talking about the security of our passwords but I am
interested in your thoughts on the following. Selecting a known BitWarden master password
that is already considered somewhat secure, then running it through something like a Base64
calculator to generate an actual password used to unlock the vault. As you would likely never
remember the password, anytime you need to unlock you would run the known password
through the calculator to generate the vault password. For example, although clearly you
would never use this, Password12345678 would generate the password you would use as your
Master Password to be UGFzc3dvcmQxMjM0NTY3OA== . There are many Desktop and Mobile
applications that can complete this calculation without running the known password through an
online encoder/decoder.
Algorithmic password generators are an interesting idea. The concept was to use an HMAC
function which is essentially a keyed hash function. So the user would generate a single secret
permanent key which would key the hash function. Then they would enter the domain they’re
visiting into the hash function and it would output an absolutely maximum entropy password.
Since every domain would produce a different unique password, there would be no password
reuse, and there would also be nothing to remember per domain since any domain’s password
could be recreated on demand.
This idea intrigued me so much that I wondered whether it might be possible to create a truly
secure paper-based encryption system. Our long time listeners may recall that the idea I hit
upon and developed was the idea of traversing a per-user customized Latin Square. I called the
system “Off The Grid” since the passwords came from a grid and the system was offline and
used no electricity.
So, anyway, Brad’s right that yet another means of generating unique per-site passwords would
be to employ some form of algorithmic system. But using a secretly keys hash function would be
a good place to start.
I don’t know why people uphold Steve Gibson as some kind of security expert. Every idea of his that I’ve seen posted by his (evidently numerous) listeners/readers seems to be worse than the previous one. To be clear:
This is a bad idea!
I cannot explain it any better than Tony Arcieri did in a widely cited 2016 article:
Sorry but your thoughts on SG aside, nobody said anything about deterministic password managers?? The idea is simply to hash or transform something easy to remember to be used for a potential Master password?
Well, Gibson (or whoever is talking in the show notes excerpt that you posted above) is talking about a deterministic (= “algorithmic”) password generation system: they propose to use a memorable password or passphrase, in combination with the domain name, and feed these two pieces of information into an algorithm that generates a unique hash to use as the password on the specified domain. In some cases, additional inputs are used (e.g., username, iteration count) — see one example.
Reading your response (and re-reading your OP), I’m now thinking that you may be suggesting/asking about something different. You seem to be suggesting that instead of using a memorable master password, we should create a hash of a memorable password, and use the hash as the master password. It seems that your proposal is motivated in part by a concern about dictionary attacks.
Assuming that my (re-)interpretation of your post is correct, I offer the following feedback:
Dictionary attacks are effective only if you use a password consisting of a single dictionary word (or perhaps 2-3 words), including transformed versions of those words (e.g., “l33t” substitutions, backwards writing, pig-latin, etc.) as well as addition of numbers, special characters, and/or capitalization. Dictionary attacks are nothing to be feared if using a concatenation of multiple (>3) words that were selected at random from a word list containing at least 5000 word choices. Even if the attacker has a copy of the exact word list used, there are simply too many combinations and permutations that could be made when generating a random passphrase consisting of 4 or more words — the attacker will not be able to guess the passphrase in your lifetime. Therefore, if you are already using a randomly generated passphrase (of 4 or more words) as your master password, there is no benefit in transforming this passphrase into a string of gibberish using a hashing function.
Relying on the attacker to not have information about your password generation method (e.g., which hashing function was used) is an example of “security by obscurity”, which should never be your main line of defense. In any case, there is only a limited number of plausible candidates (let’s approximate the number as 10), and the attacker could try them all; if the average number of parameter combinations for each possible algorithm choice is in the environs of 8000, then at most you’ve produced 16 bits of entropy by hiding your hashing algorithm. Thus, if you feel that the hashing process gives you a license to choose a weak input password like Passsword12345678, then total entropy of your master password will be very low, even though it looks like a high-entropy random password.
I understand your points here. Just to follow thru on the concept, what if my random words were “absurdly pyralidae suicides portals bourne” and I could easily remember them; would there be any security benefit in hashing or transforming them via some method like scrypt/Argon2 or a “Latin Square” like process?
Assuming that each of your five words (absurdly pyralidae suicides portals bourne) was selected at random from a word list or dictionary containing at least 5000 words, then no further hashing/transformation should be required, because the number of possible random word combinations would be over 3×1018.
If you are using the Bitwarden’s default KDF settings (600,000 iterations of PBKDF2), then it should take around 5 million years for a single GPU to crack the master password by brute-force guessing (or it would take billions of dollars to assemble the hardware necessary for cracking the password in less than a year).
While argon2(password123, somesalt) = b42d3ec9594e421984a64648b55c937e78fb6cd66fa5731a7c228ad07c36e90a = your master password
would resist an attacker who just tries a dictionary attack on the master password hash, this relies on your cryptographic scheme being secret. As soon as your scheme is leaked, the attacker is able to adapt the attack and there would be no more benefit (except if your external KDF has much higher settings than the ones built into Bitwarden).
As @grb pointed out, for just 5 words the time to crack, even on PBKDF2, is so large that no attacker can feasibly do it. Heck, due to the salting even with LastPass’ weak KDF settings, broad attacks are infeasible, and only targeted attacks or credential stuffing are feasible.
Additionally, using external tools has other operational problems. Lets say you run argon2 to pre-hash your password in a cli. If you copy the hash out of the terminal, what if some program records your clipboard? What if the password hash shows on screen in the terminal and someone can see it if you are in a public setting? What do you do on mobile, how do you compute the hash there?
It seems like a lot of work for no real benefit, and possibly some increased risk (clipboard stealing). Just use a good, unique master password.
The best security is unquestionably from pure randomness (entropy). There is no substitute.
I think depending on the situation there may be a tradeoff between security and convenience. Sometimes we want a degree of convenience, such as being able to create a long string of “random-ish” characters repeatably without memorizing them. Whether that’s a worthwhile objective is subject to debate, but personally i think there are situations when it may be helpful and i think that’s what you’re trying to do.
In cryptography of hash functions, the assumption would be that the algorithm used is known and the inputs are random. In that case , then the entropy of the output is the same as the entropy of the input to the algorithm. If there are parameter inputs to the algortihm, then we can take credit for the entropy of the parameters and consider that the output has the entropy of the input plus the entropy of the parameters. (And of course the algorithm with certian paramters increase computational cost, but that increases linearly while entropy increases exponentially). Can we take also credit for entropy in the algorithm itself? Certainly not if it is a standard published algorithm. Maybe if you write the algorithm yourself then it’s very obscure and you’d be more justified in taking credit for a degree of entropy in the algorithm. Even then no doubt some people would label it as security through obscurity and look down upon it. Personally I think there is a place for security through obscurity on occasion, but it’s a situational question.
