Even then, you’re better off with a passphrase as they are longer, easier to remember, and are harder to brute force. It’s like a dictionary resistant password.
depending on what you mean by passphrase, “dictionary resistant” is kind of the opposite of how I’d describe them. Sure they’ll be long and unique but an english language dictionary will surely make bruteforcing them a lot easier
my main opinion is just that simple pass phrases ala: https://xkcd.com/936/ can be brute forced with an english dictionary which is super predictable. tossing in leet speak or a caesar cipher or almost anything else is unpredictable enough to make that risk pretty low unless the attacker knows you are using it.
From what I understand it doesn’t help at all. I’m not a crypto (cool crypto, not fake banking) guy but from what I know passphrases generate much entropy. That said, I stick with passwords that are easier to enter, but still pretty high entropy
hmm. you know I haven’t done the math in a while but you might be partially right. It definitely does still help to use a dictionary for passphrases, but especially if you include all the words in the english language, not just a much smaller subset like diceware, and if you add anything to dress it up a little, it can still be pretty hard to crack… before password managers were a thing I was known to do like 3-5 random words plus 2-4 digits, and maybe a punctuation character if I was feeling spicy. A pre-calculated hash/rainbow table attack is not feasible if the password hashes are properly salted but a plain wordlist/dictionary attack still is
For the curious, I came up with something like 650-700 years on average to crack a 4 random word passphrase at 20 billion tries/sec (that rate was a real life example sourced from some pentesting firm’s site) if your word list includes every last word in modern use in english (171000 words). If your wordlist is only 2048 common words (like diceware) though, that’s like 10 minutes or less.
xkcdpass (based on the well known comic) by default uses the EFF’s long wordlist, which is 7776 words I believe, so a 4 word passphrase from that would average about 24 hours to crack at that same speed. Not great but if you spice it up with digits, special chars, etc then maybe that’s okay for the average person. But it’s pretty long to type out especially on mobile.
A randomly-generated password can be a lot shorter than an equivalent-strength passphrase, actually:
If you have a dictionary with 25,000 words in it, and you randomly select 5 of them, your passphrase will have a strength of about 73 bits of entropy, which is decent (but actually less than the NIST recommendation of 80 bits, as it happens; to get there, you’d need 6 words).
A similar-strength randomly-generated password consisting of letters (upper- and lower-case), numbers, and a selection of 10 possible symbol characters (so, a total spread of 26 + 26 + 10 + 10 = 72 possible characters) would only need to be 12 characters long (and would have a strength of about 74 bits of entropy–13 characters would top 80 bits).
The passphrase would take over 300 years to brute-force at 1 trillion guesses per second, but the extra bit of entropy in the 12-character password means it would take 600 years to guess that one at the same rate.
I use randomly generated passphrases that do use symbols and integers. It’s easier to type if I’m copying it from my manager manually. I really dislike the focus some services have on maximum length.
My argument would be that 300 years vs 600 years is meaningless when the human lifespan is so much shorter. At that point, who gives a shit? I’ll personally take a passphrase I can easily remember over doubling the already insanely long amount of time it would take to brute force the phrase.
Most people pick bad passwords because it’s easier to remember. Why not encourage them to use something that is both easy to remember AND more secure than the original?
The other aspect is the actual hashing algorithm used for storing and validating the input. Using a system that allows for artificially inflating the amount of time required (bcrypt rounds for example) makes it easier to mitigate a brute force attack. If the service is using an algorithm that is ready “broken” then it really doesn’t matter what you used as the input.
The goal is not to reach the most secure system, rather to increase overall security by getting as many people to use things that are better than before while balancing usability. There’s a reason not everyone uses 2FA, or has physical devices for it.
Well, I used 1 trillion guesses a second here. 10 years ago I’d have used 10 billion. So length does matter. And 300 years drops to 1 year if a dedicated attacker is willing to spend a good bit more on hardware (which, in the era of cryptocurrency, could actually be worth it, even just for a criminal).
And yes, sites should use good hashing algorithms, but we users can’t count on them doing so. Plus, even a technically-but-not-practically broken hashing algorithm isn’t so broken as to be equivalent to plaintext storage (unless it’s unsalted), so it’s less about specific algorithm choices and more about overall design security.
Not saying passphrases are useless, but password managers are the better technological path, in my opinion, because they obviate the need to remember more than just one password, and allow to you skip typing in passwords too (in fact, a pw manager is better for passphrase users, because they they can still use memorable phrases but don’t have to type them in all the time).
And as it happens, my master password for my pw manager was originally a 6-word passphrase, but has since been changed to a 20-character randomly-generated password, because it’s a ton easier to type, particularly on mobile.
Absolutely agree on the usage of a password manager. And yes, as hardware increases in power we run into the issue of timelines being shorter. I disagree on MD5 being not totally broken, considering a collision can be found in seconds on even low end hardware these days. Even salted, a collision would still be viable.
Again, the real problem overall is adoption. Getting people to use better passwords/phrases that are less likely to be brute forced. Everyone should be using non-SMS 2FA, ideally with an authenticator app or physical key. As well, password length should only be limited by a minimum value rather than being in a small range. Services should be using algorithms that are recent, well audited, and have the ability to artificially inflate the time taken to get the result for future-proofing. SSO is also an option, since services without IT departments or people with the ability to handle passwords should offload it to a service that can. SSO as a service provider is very appealing, as you no longer have the responsibility of storing sensitive hashes and account information.
Was not aware of the latest efforts on MD5, in all honesty; I take back what I said before.
I agree with everything you said there 100% except the bit about SSO. SSO is great for people working in managed environments (I wish my workplace would make broader use of it, honestly), but expanding it to everyone as a whole creates some serious issues (putting everyone’s eggs in the same basket is a security risk, and worse, having a centralized third party notified of every login request totally undermines user privacy).
I don’t mean to imply that it should be everywhere, rather it is appealing as an option when the only other option is to roll your own setup.
It’s useful for connected services, orgs, etc. Especially when it comes to easily setting up access controls. But you’re right, it’s not a solution that should be used everywhere due to the fact that a single point of failure is bad.
Btw this has been a great discussion and I hope that others reading this might help further the goal of creating a safer internet
The absolute best practice is to add random spaces that don’t correspond to syllables. A 10 character password can go from taking a few seconds to crack to several hundred years with a few well placed spaces.
That said, there are databases out there that don’t like spaces, and for some reason lots of financial institutions are this way.
Fucking ridiculous in 2023. If I want to have a 300 character password, that’s my business, hate these arbitrary rules of a max number, no special characters…
That’s why stuff like webauthn is better; if we’re going to maintain a list of garbled text, let’s make it secure one-way encrypted keys instead, which are way stronger.
You’re still only as secure as your password manager, but no one’s gonna decrypt your private key from a stolen database of public keys unless some really monumental exploit is discovered - and if that happens we’ve got MUCH bigger problems.
Even then, you’re better off with a passphrase as they are longer, easier to remember, and are harder to brute force. It’s like a dictionary resistant password.
depending on what you mean by passphrase, “dictionary resistant” is kind of the opposite of how I’d describe them. Sure they’ll be long and unique but an english language dictionary will surely make bruteforcing them a lot easier
multiple language passphrase and proper nouns
that’s why you use pig latin
I’ll stick with 1337 5P33K
that’s very common, widely understood and easy to replicate, i.e., not that great
make up your own 1337 5p33k with 3 characters changed
I simply become the zodiac and convert my pass phrase to a cipher
I mean it’s better than pig latin lol
my main opinion is just that simple pass phrases ala: https://xkcd.com/936/ can be brute forced with an english dictionary which is super predictable. tossing in leet speak or a caesar cipher or almost anything else is unpredictable enough to make that risk pretty low unless the attacker knows you are using it.
From what I understand it doesn’t help at all. I’m not a crypto (cool crypto, not fake banking) guy but from what I know passphrases generate much entropy. That said, I stick with passwords that are easier to enter, but still pretty high entropy
hmm. you know I haven’t done the math in a while but you might be partially right. It definitely does still help to use a dictionary for passphrases, but especially if you include all the words in the english language, not just a much smaller subset like diceware, and if you add anything to dress it up a little, it can still be pretty hard to crack… before password managers were a thing I was known to do like 3-5 random words plus 2-4 digits, and maybe a punctuation character if I was feeling spicy. A pre-calculated hash/rainbow table attack is not feasible if the password hashes are properly salted but a plain wordlist/dictionary attack still is
For the curious, I came up with something like 650-700 years on average to crack a 4 random word passphrase at 20 billion tries/sec (that rate was a real life example sourced from some pentesting firm’s site) if your word list includes every last word in modern use in english (171000 words). If your wordlist is only 2048 common words (like diceware) though, that’s like 10 minutes or less.
xkcdpass (based on the well known comic) by default uses the EFF’s long wordlist, which is 7776 words I believe, so a 4 word passphrase from that would average about 24 hours to crack at that same speed. Not great but if you spice it up with digits, special chars, etc then maybe that’s okay for the average person. But it’s pretty long to type out especially on mobile.
A randomly-generated password can be a lot shorter than an equivalent-strength passphrase, actually:
If you have a dictionary with 25,000 words in it, and you randomly select 5 of them, your passphrase will have a strength of about 73 bits of entropy, which is decent (but actually less than the NIST recommendation of 80 bits, as it happens; to get there, you’d need 6 words).
A similar-strength randomly-generated password consisting of letters (upper- and lower-case), numbers, and a selection of 10 possible symbol characters (so, a total spread of 26 + 26 + 10 + 10 = 72 possible characters) would only need to be 12 characters long (and would have a strength of about 74 bits of entropy–13 characters would top 80 bits).
The passphrase would take over 300 years to brute-force at 1 trillion guesses per second, but the extra bit of entropy in the 12-character password means it would take 600 years to guess that one at the same rate.
I use randomly generated passphrases that do use symbols and integers. It’s easier to type if I’m copying it from my manager manually. I really dislike the focus some services have on maximum length.
My argument would be that 300 years vs 600 years is meaningless when the human lifespan is so much shorter. At that point, who gives a shit? I’ll personally take a passphrase I can easily remember over doubling the already insanely long amount of time it would take to brute force the phrase.
Most people pick bad passwords because it’s easier to remember. Why not encourage them to use something that is both easy to remember AND more secure than the original?
The other aspect is the actual hashing algorithm used for storing and validating the input. Using a system that allows for artificially inflating the amount of time required (bcrypt rounds for example) makes it easier to mitigate a brute force attack. If the service is using an algorithm that is ready “broken” then it really doesn’t matter what you used as the input.
The goal is not to reach the most secure system, rather to increase overall security by getting as many people to use things that are better than before while balancing usability. There’s a reason not everyone uses 2FA, or has physical devices for it.
Well, I used 1 trillion guesses a second here. 10 years ago I’d have used 10 billion. So length does matter. And 300 years drops to 1 year if a dedicated attacker is willing to spend a good bit more on hardware (which, in the era of cryptocurrency, could actually be worth it, even just for a criminal).
And yes, sites should use good hashing algorithms, but we users can’t count on them doing so. Plus, even a technically-but-not-practically broken hashing algorithm isn’t so broken as to be equivalent to plaintext storage (unless it’s unsalted), so it’s less about specific algorithm choices and more about overall design security.
Not saying passphrases are useless, but password managers are the better technological path, in my opinion, because they obviate the need to remember more than just one password, and allow to you skip typing in passwords too (in fact, a pw manager is better for passphrase users, because they they can still use memorable phrases but don’t have to type them in all the time).
And as it happens, my master password for my pw manager was originally a 6-word passphrase, but has since been changed to a 20-character randomly-generated password, because it’s a ton easier to type, particularly on mobile.
Absolutely agree on the usage of a password manager. And yes, as hardware increases in power we run into the issue of timelines being shorter. I disagree on MD5 being not totally broken, considering a collision can be found in seconds on even low end hardware these days. Even salted, a collision would still be viable.
Again, the real problem overall is adoption. Getting people to use better passwords/phrases that are less likely to be brute forced. Everyone should be using non-SMS 2FA, ideally with an authenticator app or physical key. As well, password length should only be limited by a minimum value rather than being in a small range. Services should be using algorithms that are recent, well audited, and have the ability to artificially inflate the time taken to get the result for future-proofing. SSO is also an option, since services without IT departments or people with the ability to handle passwords should offload it to a service that can. SSO as a service provider is very appealing, as you no longer have the responsibility of storing sensitive hashes and account information.
Was not aware of the latest efforts on MD5, in all honesty; I take back what I said before.
I agree with everything you said there 100% except the bit about SSO. SSO is great for people working in managed environments (I wish my workplace would make broader use of it, honestly), but expanding it to everyone as a whole creates some serious issues (putting everyone’s eggs in the same basket is a security risk, and worse, having a centralized third party notified of every login request totally undermines user privacy).
I don’t mean to imply that it should be everywhere, rather it is appealing as an option when the only other option is to roll your own setup.
It’s useful for connected services, orgs, etc. Especially when it comes to easily setting up access controls. But you’re right, it’s not a solution that should be used everywhere due to the fact that a single point of failure is bad.
Btw this has been a great discussion and I hope that others reading this might help further the goal of creating a safer internet
The absolute best practice is to add random spaces that don’t correspond to syllables. A 10 character password can go from taking a few seconds to crack to several hundred years with a few well placed spaces.
That said, there are databases out there that don’t like spaces, and for some reason lots of financial institutions are this way.
I just hate fucking sites that tell me it has to be under 16 characters. Like wtf
Fucking ridiculous in 2023. If I want to have a 300 character password, that’s my business, hate these arbitrary rules of a max number, no special characters…
That’s why stuff like webauthn is better; if we’re going to maintain a list of garbled text, let’s make it secure one-way encrypted keys instead, which are way stronger.
You’re still only as secure as your password manager, but no one’s gonna decrypt your private key from a stolen database of public keys unless some really monumental exploit is discovered - and if that happens we’ve got MUCH bigger problems.