I'm glad someone is thinking about UX and ergonomics when it comes to passwords. Most people I interact with have by now realized that generating passwords is a good idea. But if you are already generating the password, please do not include special characters. I regularly use different keyboard layouts (sometimes it is not even clear which layout is active, like in the vSphere web console), and the fact that passwords are often not shown on the screen when typing them makes for terrible UX and causes frustration.
The usual advice about character classes is only for casual users who don't know what makes a secure password. Entropy is the deciding factor: Ten random lower case letters is much more secure than "Summer2024!", which satisfies most password rules and has more characters.
Personally I stick to lower case letters for things like my Netflix password or Wifi key, because typing with a TV remote can be a huge pain. To keep a similar entropy, just increase the length by one or two characters.
> The usual advice about character classes is only for casual users who don't know what makes a secure password.
Arguably, it was to make early rainbow tables less feasible.
> if you are already generating the password, please do not include special characters.
This would make your generator useless on most sites. Since it's not the generator making up this rule, it's the web site's password "complexity" requirements.
I do agree password strength tests should just measure bits of entropy and allow whatever's typed that's high enough.
I like to subvert those sites by just adding A1! to the end of every otherwise totally lower-case password.
There is a special place in hell for anyone who creates a maximum password length limit, however. That prevents passphrases and gains nothing. If you're working with some weird legacy system that can't handle long password (worst way: just truncating them and matching the first 8 characters), then add Argon2 or heck even SHA where you otherwise add the password length check.
This is the exact reason why NIST, for the better part of a decade now, has strictly recommended against arbitrary password rotations. All it accomplishes is frustration for users with no tangible increase in security (because everyone just increments their password, or follows other simple patterns).
Some research suggests that arbitrary password rotations results in a real-world decrease in security, because as users get frustrated they make simpler and simpler passwords.
Such sites that do not allow Apple passwords I now skip as a user (unless it’s a government site), it says enough about how you view security and there are plenty of competitors that don’t do this
I don’t believe it’s possible to estimate the amount of entropy in a password - it’s too short so then you have to evaluate it against a dictionary. That’s why things are moving to passkeys but NIST recommendations thankfully have finally been updated to stop recommending weird password rules.
>NIST recommendations thankfully have finally been updated
Finally? It's almost been a decade since since special publication 800-63B was published recommending against silly things like composition rules and arbitrary password rotations.
How often do people actually end up typing these random passwords though? Personally, I almost always can copy/paste or autofill. For devices like TVs, it seems like many of them let you pair via a QR code or other mechanism. And sure, there are times where you need to manually type a password, and for those specific cases you can use a different scheme (like avoiding special characters or using something like Diceware https://diceware.dmuth.org/) but I wouldn't go so far as to never include special characters. IMO if you expect to always be able to autofill, use as many character classes as possible.
Well, I do it a lot. I do consulting in IT security and go through the onboarding process of a different company 15 times a year. My customers and co-workers are often security conscious and sometimes give me passwords like RC-A"c\EJe,0l@q. I prefer the US layout but live in Germany, so there is often a mismatch between my physical keyboard and the system I'm typing on, which causes me great frustration. Typing in the LUKS password of a VMware machine via vSphere web console does not allow copy/paste, neither does logging in to a physical device provided by the customer.
I realize I'm far from a typical use case, which is why I'm so glad when people consider password ergonomics. It makes life easier for me and does not make it harder for anyone else.
When I was doing that a lot I just patched my VNC client to send the keys for the data in the clipboard on "paste" so I could use its native "paste" command
One notable exception is the 1Password secret key. It’s long and random. I spent this summer reinstalling Linux on a laptop over and over and having to re-type this one long string was my least favorite part of it. Especially since I use multiple profiles in Chrome, and each needs to be authenticated for 1Password.
I stumbled across a website (think it was a CRM or CMS, I’m evaluating a lot at the moment) that wouldn’t accept an Apple generated password the other day because it didn’t comply with their password strength rules. These days that’s the kind of thing that will make me choose a competitor product
Ordinarily I'd agree with small companies not being informed enough on security best practices and agree with your point. Small companies shouldn't invent security on their own.
But there's something bigger here that stood out and that kind of makes me angry: Apple, a multi-trillion dollar company, is influencing people to stop using products by small companies and small teams.
It's stuff like this, stuff like requirements to "sign in / pay with Apple", and stuff like the green text boxes that make you have to fit everything to Apple and give them their dues.
I really wish we'd regulate or break up the big tech companies. Innovation has barriers to entry because of them.
Apple shouldn't be making their own password standard. They should work in an industry consortium to agree across the board, and they should put in the extra effort to tell users when websites may not comply with their new rules. It's not the website's fault that they didn't get the new and unannounced memo.
Add a new HTML password form property to indicate compliance with the standard before you go generating uncompliant passwords. Do a graceful migration. Stop beating up the little players.
I'm starting to think that neither Google nor Apple should be allowed to have their own web browsers. They're only using them as a means to deepen their platform reach and hobble up more control.
Pretty soon Apple and Google won't generate passwords at all. They'll deprecate the password field and mark it dangerous. Then it'll be an Apple passkey where companies will have to negotiate payment rates and won't be privileged to know their own customer.
I, personally, use my own password generator to generate passwords using 10 lowercase ASCII characters excluding ilo. That's 45 bits of entropy or one year of brute forcing trying 1 million attempts per second. I consider that a reasonable strength for all but the most important websites.
The password generators that generate me 20 characters of different character classes are crazy.
alias genpasswd='openssl rand -rand /dev/random -base64'
Additionally I have a function in Bash that takes words from particular languages which are separated, along with "gpw" ("Generate Pronounceable Password", a C program).
In the context of web authentication, does entropy even matter (beyond an extremely low threshold)? Are there any attacks that actually occur that are defeated by increasing entropy? AFAIK basically all the auth attacks we see today are from password re-use, and out-of-band authentication, neither of which password entropy has an effect on.
"Summer2024!" is perfectly fine, if you use it for exactly one service. Frankly, "1235" is probably fine. No one is out there brute-forcing passwords.
So the user remains at risk in the time between the leak and the time the company discovers it and resets all passwords, which could be months. It might not really be relevant for most sites and for most users, and you might argue that if the hash database is compromised you have other things to worry about, but it's a something to consider.
So the service you used this password at gets its password hashes leaked. Your account is one of the (admittedly many) low-hanging fruits that gets used for whatever else someone might be using it for.
I suppose, if it's some random forum, they could just post some bot spam with your account and get you banned, no big deal. You'll live.
Ah! That's a good point. I had been considering a hash leak to be equivalent to a plaintext password leak, where you're screwed no matter the entropy. But I guess you have a fair point: a high entropy password could prevent your password from being cracked even under that scenario. So you could have a point here.
We could explore that further: are there any recent examples of this happening? is cracking password hashes still hard, given modern GPU hardware techniques? This could help us establish what "low" actually means when I say "low threshold."
Yes it still happens pretty regularly, but in recent years people have gotten a lot better at using libs, so passwords are salted and hashed with a slow algorithm which substantially increases the difficulty of hashed attacks by makign it computationally expensive to hash every password. These days it's not uncommon for it to take months or years to crack 50% of the passwords in a dump. If your password has sufficient entropy, it may never be cracked. Modern GPUs can parallelize across their numerous cores, but statistically a brute force isn't going to work. Hybrid dictionary attacks are where it's at, and if your password is random (pseudo-random) then a dict attack won't work.
You ask a yes/no question, someone says "yes", you say "so what?". You should have just started there. "So what if someone gets my email and password for whatever website?"
So in your very specific contrived scenario that a user is using weak passwords but never reusing them, yes they are fine provided the site with the leaked account data realizes this and makes you reset your password.
But we already know that in reality most people reuse weak passwords. If your reused password was a passphrase that wasn't in the dictionary and couldn't be brute forced in a reasonable time, then you would be fine.
My point with this thread is that if you're focusing on entropy, you're wasting your time. It doesn't matter beyond some threshold, which I argue is quite low. It doesn't matter if it takes 500 years or 5000 years to crack your password, no one's doing it so long as it's beyond (say) 3 months of CPU time.
It would be better to focus on easy and unique, than to focus on entropy.
Yes I agree that the passwords should be unique, easy to type manually when you have the need, and some minimum threshold of entropy is nice to have.
I have no idea what that minimum should be though. Aren't passwords cracked with GPU? I admittedly have no clue about this, but it sounds right to me lol. Assuming they are, a 4090 can probably guess a hell of a lot of passwords per second. I've had the same generated strong Reddit password for like 15 years, what are GPUs going to look like in the next 15?
The last time I had to implement password login for something we just followed NIST guidelines and called it a day.
It depends on what "easy" means to you, but assuming some minimum level of "easy" I would agree. I typically encourage people to think in pass phrases instead of pass words, like the xkcd[1] except throw some personal variances in there. A substituted misspelling, a fake word, intersperse some meaningful numbers, (basically anything to make the standard dictionary attack algorithms fail at generating your password).
> AFAIK basically all the auth attacks we see today are from password re-use
https://haveibeenpwned.com/Passwords says Summer2024! has been seen in two breaches, which means even if it weren't being brute forced it's less safe. 1235 has been seen significantly more times...
I'm curious if you're just being satirical here - it's not entirely obvious.
I'm not. If you use a unique password for every service, entropy doesn't matter beyond a low threshold, because guessing passwords against a live service is not an attack people are actually doing. The "1235" is an extreme example, I wouldn't bet my bank account on it, but I still think the point stands.
> "Summer2024!" is perfectly fine, if you use it for exactly one service. Frankly, "1235" is probably fine. No one is out there brute-forcing passwords.
Respectfully, I disagree. "Summer2024!" is probably the second password I'd try after the username itself if I have to guess a password. Use it in a password spraying attack on a company with 500 users and you will get a few hits, I promise.
It's a fair point, but I think my argument still stands. Guessability is a different property from entropy, yeah? "Summer1975!" has the same entropy, but you probably wouldn't have put that into your password sprayer.
I wasn't an Apple user until almost exactly a year ago, and the auto-generated passwords were an inspiration to me to cobble together a script that generates such passwords in multiple languages [1]. I couldn't find any info on these passwords, so I am glad this is posted, because indeed, I find the format brilliant!
I imagine the main reason for the single capital letters is to make the password acceptable on those annoying websites with annoying requirements, not necessarily to add entropy.
If you already know it's in apple password format, then you know 1/17 of the letters are capital, but not which one so the number of combinations you have to try is multiplied by 17, for just over 4 additional bits of entropy.
You multiply the entropy of the previous word by the added entropy of the new symbol. This grows exponentially!
Extra character classes can help if you're stuck needing to make a really short password for some reason, but if you're randomly generating each symbol anyway, just tossing a few more on the end is *far* more effective. You massively increase the brute force search space with each additional symbol.
Switching one uppercase letter in an otherwise lowercase password adds exactly 1 bit of entropy (per switched letter).
On the other hand, any extra lowercase letter will increase the entropy by 4.7 bits (assuming a password on [a-z]).
Given that most passwords have at best 2 uppercase letters, I would argue it is safer to force longer passwords than passwords with at least one uppercase letter.
question: would it be possible/smart to have a system where the entity that is authenticating you has a way to disclose to you the maximum password complexity that it can handle ? Something like a GeekCode string that you can feed to your password generator and come out with a the strongest password possibly handled by the system ?
One place where this has saved me is trying to type in my VRChat password, on a standalone Quest 3 headset. The tedium of trying to type in a password in VR with a virtual keyboard, while having the headset slid up onto my forehead juuuust enough so I can see my phone with my password manager on it, is by far the worst modern login process I've ever experienced. Just having pronounceable syllables is enough to speed that process up significantly.
I always liked the 1Password word passwords… you select the number of words and it generates each word in upper OR lowercase, and connect them with symbols or numbers. Easy to memorize, and better then keepass or others that use more fixed formats: same characters between words and words are just in title format where the first letter is upper case and rest is lowercase.
The problem is that many sites still use archaic password rules.
1Password should by default just always capitalize one word, and add “1” at the end of the memorable password. Since the words are separated by “-“ or “.”, you already hit the “at least one symbol” rule.
I was presently surprised by the password requirements when I created a bugzilla account just the other day.
- Password must be at least 12 characters long.
- And the password must also contain either of the following:
- A phrase containing at least four unique words of three characters or longer
- or password contains at least 3 of the following qualities:
- uppercase letters
- lowercase letters
- numbers
- punctuation characters
- or more than 12 characters
I’ve seen minimums of 8 and 12, and maximums as low as 20.
AgileBits obviously has done a lot more profiling, but it would be nice if they developed a universal password formula that was still memorable. So with words, “-“ separator (or maybe “.” separator?), maximum length 18, one whole word capitalized, random single digit at the end or beginning.
That way you keep maximum entropy, keep it readable, whilst fitting within the rules of “all” sites.
Although within 5-10 years I see passkeys having largely taken over, especially because mom and pop won’t be able to forget those, and they won’t be able to forget their fingerprint or face either.
I especially like sites that disallow pasting into password fields.... Yes, that is apparently a thing, especially for banking or finance related sites (from my experience)
For a while, the login for TreasuryDirect (the gov site for buying US bonds) disabled paste and typing! It required you to click out your password on an onscreen keyboard.
I pity the folks who don’t know how to use dev tools.
Good on 'em for doing a complete 180 on that. Bank of Melbourne has stated that using a Password Manager is a violation of their Terms of Service (as people have complained about the non-pasteable/autofill fields).
I've been working in finance for 15 years, and the amount of security theatre we're forced to do by various parties is monotonically increasing year by year.
The way it works is you have a hundred government regulators around the world, full of underpaid bureaucrats straight out of school, who introduce vague, poorly thought out requirements. The consequences of non-compliance often being existential for the business: you can lose your license, your clients, and in some cases, your freedom.
Next a bunch of lawyer/compliance-y types take those requirements from around the world and try to distil them down to a specific (but onerous) set of controls by interpreting the guidelines cautiously. Obviously all they care about is making sure that if you do get popped, you can claim you did everything in compliance with the regulations and you get to continue trading.
Often these rules are transitive too, so you need to have some level of certainty that the other parties in your supply chain are also compliant, so independent auditors spring up to provide some third party accreditation. Your CFO sees this purely as a cost and doesn't want to pay much for it, so the pressure is to make this auditing as simple as possible, so their checklists become oriented around things they can easily check to demonstrate compliance with a particular control.
So some original requirement like "it should not be possible to share passwords between multiple users" ends up being bastardised down the chain until the item on the checklist is "don't allow pasting into the password field". Obviously by this point, everyone's actually forgotten why that checklist item was created, so even if the original requirement disappears, the checklist item lives on, often, forever.
It's only in rare, high profile circumstances where a previous requirement is explicitly and noisily repudiated that old items tend to disappear. Even then it can take years. I'm still having to fight back auditors asking for mandatory monthly password changes, for example, in a system that uses passkeys...
I despise sites that disallow pasting into fields.
Banks seem to really like to now allow you to paste direct deposit information, which is insane. I get that they likely are thinking, well we don't want you type it into the first field and copy it into the second.
But I am copying it right from my bank's website, being forced to type it twice is just going to make it more likely I enter an error and I can guarantee you I am looking at that first field when I am typing the verification one.
The web developer should not be able to disable pasting. Just like they should not be able to disable autofill, and other features that the user wants and has enabled.
So many things web sites do that are counter to the user's expectation, where I think to myself: Why even have that lever?
I always make that the default in my 1Password instances. If the threats we're trying to protect against are mainly 1) weak passwords and 2) password reuse, then there's still room there for human-friendly readable passwords. I don't see much marginal benefit of generating something like cnC*i8Npc2J7zWRYFfsy (the common default template across password managers) over teo-PRETENDS4cognac.
I’ve been using 1Password since 2008 and didn’t even know this was an option. It defaulted to complete randomness and I always just left it there. Typically not an issue, but it is annoying on the rare occasion I need to type something. I’ll have to consider this when making new accounts in the future, or updating old ones.
I liked the previous password generation in Keychain when you chose memorable password. It would be two words with a couple of numbers and/or symbols in between.
That option isn't available anymore though.
I use 1Password to store it though and have since 1Password 7, maybe sooner.
The extra randomness really only buys you a couple extra bits of entropy, but makes it more annoying to remember which format your password is in. It’s much more effective (entropy-wise and memory-wise) to tack on an extra word.
There is/was a fork of KeePass[0] that had a similar "pronounceable passwords" feature where you'd end up with things like "JorbHamstrayPrablem" or other things that sound like they'd come out of Coach Z's mouth.
[0] Not the one I'm currently using, and I don't remember which
Apple TV lets you use your phone to input passwords, so in Apple's ecosystem they wouldn't care about that. And being Apple, they wouldn't care about people needing to use anyone else's devices.
Website length limits are a problem though, in the worst case there are websites that silently truncate your password so you don't even realize that the first 12 (or whatever) characters are the only part that matters. If your first 12 characters are two words with a dash in the middle, that could be a real vulnerability.
Another benefit of passkeys is that it limits the ability of websites to do that kind of stupid shit.
> And being Apple, they wouldn't care about people needing to use anyone else's devices.
Did you RTFA?
>> To make these passwords easier to type on suboptimal keyboard layouts like my colleague’s game controller, where the mode switching might be difficult, these new passwords are actually dominated by lowercase characters. And to make it easier to short-term have in your head little chunks of it to bring over to the other device, the passwords are based on syllables. That’s consonant, vowel, consonant patterns. With these considerations put together, in our experience, these passwords are actually a lot easier to type on a foreign, weird keyboard, in the rare instances where that might be needed for some of our users.
Roku, who has about 50% of the streaming device market in the US, supports entering passwords via their mobile apps.
Having to enter a password on a streaming device is rare event for me at least. Almost all of the apps on my Roku support using an off device web browser to authenticate.
The vast majority of passwords does not need to be easy to memorize because they should be stored in a password manager. In fact, I'd argue that the harder it is to memorize, the stronger the password.
Yet they still need to be typed on cell phone keyboards, TVs, or communicated over phone (shared passwords are the best compromise if asymmetric cryptography is not an option), in which case you usually need to spell it out anyway.
Why mention memorizing passwords? Most people have dozens of passwords, and most people would have trouble memorizing even a simple word for dozens of passwords. I have a lot of trouble with those annoying security questions which one would assume would be constant and easy to answer.
How many more passwords of this format can you construct? `have` is fixed, the `!` at the end is a classic, and the 12 number is pre-determined by true cats and the 3. So the only degrees of freedom you have are:
Once I wrote a little pet project to sample words from /usr/share/dic/words and concat them together to produce "memorable" passwords. It was fun but certainly not good enough for real world use.
At the end of the day any password manager will do the job, the problem is getting people (friends & family) to use them.
When I started CS decades ago, our student passwords for our server accounts were all similarly generated. They were given to us on a slip of paper, of course, and I still remember the two I was given over 20 years later. I was (naively) bummed when I didn't see this practice in the industry after graduation
It seems like many recommendations are to use at least 75-100, or even 128. Being fairly conservative, if you had 10k hosts hashing 1B passwords a second, it would take 7.5 years worst case to crack [1]. If a particular site neglects to use a slow hash function and salting, it's easy to imagine bad actors precomputing rainbow tables that would make attacks relatively easy.
You can rebut that that's still a crazy amount of computation needed, but since it's reusable, I find it easy to believe it's already being done. For comparison, if the passwords have 100 bits of entropy, it would take those same 10k servers over 4 billion years to crack the password.
I think the assumption is that this is going into a somewhat modern hashing algorithm like argon, bcrypt (created 1999 - that's a quarter-century ago), or scrypt with salt. With those assumptions, the calculations aren't reusable, and definitely not 1B passwords / second.
If that's not true and the password is being stored using MD5 (something that's been NIST-banned at this point for over a decade), then honestly all bets are off, and even 128 bits of entropy might not be enough.
At least in my iOS 18 Passwords app, the passwords are shown in a monospace font that (probably deliberately) differentiates all these (e.g. a slashed zero).
It sounds like a clever design giving the complex topic, I will like to read some qualitative and quantitative research with real users to validate the design.
And when reading this I was thinking, what about Chinese logographic writing system or Arabic alphabet? Apple has a similar password design solution but for those cases?
Nobody will probably like it but I just use pwgen to generate passwords now and store it in 1Password since Keychain removed the memorable password option.
pwgen: aliased to pwgen --ambiguous --capitalize --numerals --symbols --secure
I usually end up piping the result to a file so I can see it and edit if I need to and cat | pbcopy the file contents to the clipboard and save it in 1password. After that, 1password either fills in the password for me or copying it is just a button click.
The main issue I face is that some web sites will either not allow passwords longer than a certain length or will only allow some special characters.
Doing something like randomly sampling a range of a-zA-Z0-9 and all the symbols without order or structure is absolutely the worse way of doing it for passwords that humans need to type/read, or in fact anything that might get tripped by special characters (like shell scripts, etc)
Yes yes you might lose a bit of entropy, just add one or two characters to it and it will make up for it. Passwords are not so much bruteforced from zero anymore rather than leaked from places with bad password hashes
I just opened the Password app for the first time to look at the generator. It seems like the pattern is: [a-zA-Z0-9]{6}\-[a-zA-Z0-9]{6}\-[a-zA-Z0-9]{6} with exactly only one uppercase char and one digit. I don't want to do the maths but that looks like a lot of removed entropy.
Fully random: 62^18 in that format, or about 107 bits of entropy.
Their approach: ~71 bits per the article (I counted ~73 bits but I’m not using their exact algorithm)
I’d say it’s not too bad. With a good password hashing algorithm you’re looking at nearly 2^100 operations to bruteforce their passwords, which isn’t going to be feasible anytime soon. (Even with a crappy hash algorithm it’s still going to be over 2^80 operations).
And, in this case, that entropy trade off means the passwords are easier to remember and type in, making it more likely for humans to actually use those passwords.
Nit, 160 bits of entropy would be if you could get 8 bits per character, but that’s highly unrealistic. 6.0~6.3 bits is more feasible based on what most websites will tend to accept, which lands you at around 120-126 bits of entropy for a fully random password.
Does anyone have concerns that this reduces the variance of passwords to something than 35^(character length) because of rules like pronounceable memorable and typeable?
thank you for this! i was looking for an easy way to generate passwords for this, and while diceware isn't in my distro's repos, turns out the EFF publishes the word list and the method to generate them online, making it super easy to make a small bash script to generate these! here's the link:
I'm glad someone is thinking about UX and ergonomics when it comes to passwords. Most people I interact with have by now realized that generating passwords is a good idea. But if you are already generating the password, please do not include special characters. I regularly use different keyboard layouts (sometimes it is not even clear which layout is active, like in the vSphere web console), and the fact that passwords are often not shown on the screen when typing them makes for terrible UX and causes frustration.
The usual advice about character classes is only for casual users who don't know what makes a secure password. Entropy is the deciding factor: Ten random lower case letters is much more secure than "Summer2024!", which satisfies most password rules and has more characters.
Personally I stick to lower case letters for things like my Netflix password or Wifi key, because typing with a TV remote can be a huge pain. To keep a similar entropy, just increase the length by one or two characters.
> The usual advice about character classes is only for casual users who don't know what makes a secure password.
Arguably, it was to make early rainbow tables less feasible.
> if you are already generating the password, please do not include special characters.
This would make your generator useless on most sites. Since it's not the generator making up this rule, it's the web site's password "complexity" requirements.
I do agree password strength tests should just measure bits of entropy and allow whatever's typed that's high enough.
I like to subvert those sites by just adding A1! to the end of every otherwise totally lower-case password.
There is a special place in hell for anyone who creates a maximum password length limit, however. That prevents passphrases and gains nothing. If you're working with some weird legacy system that can't handle long password (worst way: just truncating them and matching the first 8 characters), then add Argon2 or heck even SHA where you otherwise add the password length check.
When I am forced to rotate an otherwise good password, I swap the suffix to the front of the password
If they have some perverse check to make sure I am not re-using one of my last X passwords I just rotate in another permutation like A2!
This is the exact reason why NIST, for the better part of a decade now, has strictly recommended against arbitrary password rotations. All it accomplishes is frustration for users with no tangible increase in security (because everyone just increments their password, or follows other simple patterns).
Some research suggests that arbitrary password rotations results in a real-world decrease in security, because as users get frustrated they make simpler and simpler passwords.
also, excessive minimums. I once encountered a website with 20 minimum characters, which I think is longer than some sites' max length.
Such sites that do not allow Apple passwords I now skip as a user (unless it’s a government site), it says enough about how you view security and there are plenty of competitors that don’t do this
I don’t believe it’s possible to estimate the amount of entropy in a password - it’s too short so then you have to evaluate it against a dictionary. That’s why things are moving to passkeys but NIST recommendations thankfully have finally been updated to stop recommending weird password rules.
>NIST recommendations thankfully have finally been updated
Finally? It's almost been a decade since since special publication 800-63B was published recommending against silly things like composition rules and arbitrary password rotations.
How often do people actually end up typing these random passwords though? Personally, I almost always can copy/paste or autofill. For devices like TVs, it seems like many of them let you pair via a QR code or other mechanism. And sure, there are times where you need to manually type a password, and for those specific cases you can use a different scheme (like avoiding special characters or using something like Diceware https://diceware.dmuth.org/) but I wouldn't go so far as to never include special characters. IMO if you expect to always be able to autofill, use as many character classes as possible.
Well, I do it a lot. I do consulting in IT security and go through the onboarding process of a different company 15 times a year. My customers and co-workers are often security conscious and sometimes give me passwords like RC-A"c\EJe,0l@q. I prefer the US layout but live in Germany, so there is often a mismatch between my physical keyboard and the system I'm typing on, which causes me great frustration. Typing in the LUKS password of a VMware machine via vSphere web console does not allow copy/paste, neither does logging in to a physical device provided by the customer.
I realize I'm far from a typical use case, which is why I'm so glad when people consider password ergonomics. It makes life easier for me and does not make it harder for anyone else.
This is an easily solved problem through both software and hardware. If you are frequently typing complex passwords, consider some alternatives:
Software typing of password:
Linux - ydotool / xdotool. Win/Mac have similar tools:
>> physical device provided by the customer.Hardware : Rubber Ducky - https://shop.hak5.org/products/usb-rubber-ducky
I do something like this surprisingly often when dealing with iDRAC/IPMI/etc:
When I was doing that a lot I just patched my VNC client to send the keys for the data in the clipboard on "paste" so I could use its native "paste" command
.. and now the password is stored unencrypted in your bash history.
Use the `read` method the other poster said, or ensure HISTCONTROL is set and then prepend a space to commands that contain secrets.
That's a feature, not a bug. :P
Alright if you prefer:
Or if it's already on your clipboard:> I almost always can copy/paste or autofill.
Have you tried entering a random password using the buttons and dials on the back of a Sony camera? After three tries, I just gave up.
One notable exception is the 1Password secret key. It’s long and random. I spent this summer reinstalling Linux on a laptop over and over and having to re-type this one long string was my least favorite part of it. Especially since I use multiple profiles in Chrome, and each needs to be authenticated for 1Password.
Enough that it's worth thinking about. It's not frequent but it happens.
I stumbled across a website (think it was a CRM or CMS, I’m evaluating a lot at the moment) that wouldn’t accept an Apple generated password the other day because it didn’t comply with their password strength rules. These days that’s the kind of thing that will make me choose a competitor product
They do have a big list of exceptions for password rules, you can find more details here. Seems they are collaborating with some other password tools, so maybe at some point switching products won’t help? Not sure. Bit Warden seems to make no attempt as this currently: https://rmondello.com/2024/09/29/new-quirks-who-dis/ https://github.com/apple/password-manager-resources/blob/mai...
But you can also fix it yourself if it fails. How is detailed here: https://support.apple.com/en-au/guide/iphone/iphf9219d8c9/io...
Ordinarily I'd agree with small companies not being informed enough on security best practices and agree with your point. Small companies shouldn't invent security on their own.
But there's something bigger here that stood out and that kind of makes me angry: Apple, a multi-trillion dollar company, is influencing people to stop using products by small companies and small teams.
It's stuff like this, stuff like requirements to "sign in / pay with Apple", and stuff like the green text boxes that make you have to fit everything to Apple and give them their dues.
I really wish we'd regulate or break up the big tech companies. Innovation has barriers to entry because of them.
Apple shouldn't be making their own password standard. They should work in an industry consortium to agree across the board, and they should put in the extra effort to tell users when websites may not comply with their new rules. It's not the website's fault that they didn't get the new and unannounced memo.
Add a new HTML password form property to indicate compliance with the standard before you go generating uncompliant passwords. Do a graceful migration. Stop beating up the little players.
I'm starting to think that neither Google nor Apple should be allowed to have their own web browsers. They're only using them as a means to deepen their platform reach and hobble up more control.
Pretty soon Apple and Google won't generate passwords at all. They'll deprecate the password field and mark it dangerous. Then it'll be an Apple passkey where companies will have to negotiate payment rates and won't be privileged to know their own customer.
I, personally, use my own password generator to generate passwords using 10 lowercase ASCII characters excluding ilo. That's 45 bits of entropy or one year of brute forcing trying 1 million attempts per second. I consider that a reasonable strength for all but the most important websites.
The password generators that generate me 20 characters of different character classes are crazy.
I use:
Additionally I have a function in Bash that takes words from particular languages which are separated, along with "gpw" ("Generate Pronounceable Password", a C program).KeepassXC allows you to customize its password generator according to your preferences.
Love KeepassXC. Even if you don't want to go full offline, I think Bitwarden does the same.
I'm using Apple Safari passwords storage, it's enough for me, but KeePass is definitely great.
Ideally, any passwords you generate for hand typing or being read over the phone should exclude
include only one of each I/l/1, 0/O
soundalikes without phonetics - so include only one of the following e, p, c, v, t, 3
In the context of web authentication, does entropy even matter (beyond an extremely low threshold)? Are there any attacks that actually occur that are defeated by increasing entropy? AFAIK basically all the auth attacks we see today are from password re-use, and out-of-band authentication, neither of which password entropy has an effect on.
"Summer2024!" is perfectly fine, if you use it for exactly one service. Frankly, "1235" is probably fine. No one is out there brute-forcing passwords.
People are definitely running dictionaries against password hash leaks. Both examples look like they might be in a dictionary.
So what?
So the user remains at risk in the time between the leak and the time the company discovers it and resets all passwords, which could be months. It might not really be relevant for most sites and for most users, and you might argue that if the hash database is compromised you have other things to worry about, but it's a something to consider.
So the service you used this password at gets its password hashes leaked. Your account is one of the (admittedly many) low-hanging fruits that gets used for whatever else someone might be using it for.
I suppose, if it's some random forum, they could just post some bot spam with your account and get you banned, no big deal. You'll live.
Ah! That's a good point. I had been considering a hash leak to be equivalent to a plaintext password leak, where you're screwed no matter the entropy. But I guess you have a fair point: a high entropy password could prevent your password from being cracked even under that scenario. So you could have a point here.
We could explore that further: are there any recent examples of this happening? is cracking password hashes still hard, given modern GPU hardware techniques? This could help us establish what "low" actually means when I say "low threshold."
Yes it still happens pretty regularly, but in recent years people have gotten a lot better at using libs, so passwords are salted and hashed with a slow algorithm which substantially increases the difficulty of hashed attacks by makign it computationally expensive to hash every password. These days it's not uncommon for it to take months or years to crack 50% of the passwords in a dump. If your password has sufficient entropy, it may never be cracked. Modern GPUs can parallelize across their numerous cores, but statistically a brute force isn't going to work. Hybrid dictionary attacks are where it's at, and if your password is random (pseudo-random) then a dict attack won't work.
Modern password hashing is very good.
You ask a yes/no question, someone says "yes", you say "so what?". You should have just started there. "So what if someone gets my email and password for whatever website?"
So in your very specific contrived scenario that a user is using weak passwords but never reusing them, yes they are fine provided the site with the leaked account data realizes this and makes you reset your password.
But we already know that in reality most people reuse weak passwords. If your reused password was a passphrase that wasn't in the dictionary and couldn't be brute forced in a reasonable time, then you would be fine.
My point with this thread is that if you're focusing on entropy, you're wasting your time. It doesn't matter beyond some threshold, which I argue is quite low. It doesn't matter if it takes 500 years or 5000 years to crack your password, no one's doing it so long as it's beyond (say) 3 months of CPU time.
It would be better to focus on easy and unique, than to focus on entropy.
Yes I agree that the passwords should be unique, easy to type manually when you have the need, and some minimum threshold of entropy is nice to have.
I have no idea what that minimum should be though. Aren't passwords cracked with GPU? I admittedly have no clue about this, but it sounds right to me lol. Assuming they are, a 4090 can probably guess a hell of a lot of passwords per second. I've had the same generated strong Reddit password for like 15 years, what are GPUs going to look like in the next 15?
The last time I had to implement password login for something we just followed NIST guidelines and called it a day.
It depends on what "easy" means to you, but assuming some minimum level of "easy" I would agree. I typically encourage people to think in pass phrases instead of pass words, like the xkcd[1] except throw some personal variances in there. A substituted misspelling, a fake word, intersperse some meaningful numbers, (basically anything to make the standard dictionary attack algorithms fail at generating your password).
[1]: https://xkcd.com/936/
Low entropy means your password will be cracked if a list of password hashes leaks.
I had an account on an online game way back in the day with the password 12346, and it got hacked inside of 6 months.
> No one is out there brute-forcing passwords.
They definitely are. I’ve been locked out of my own banks website twice because of people trying to guess the password too many times.
> AFAIK basically all the auth attacks we see today are from password re-use
https://haveibeenpwned.com/Passwords says Summer2024! has been seen in two breaches, which means even if it weren't being brute forced it's less safe. 1235 has been seen significantly more times...
I'm curious if you're just being satirical here - it's not entirely obvious.
I'm not. If you use a unique password for every service, entropy doesn't matter beyond a low threshold, because guessing passwords against a live service is not an attack people are actually doing. The "1235" is an extreme example, I wouldn't bet my bank account on it, but I still think the point stands.
>guessing passwords against a live service is not an attack people are actually doing
Credential stuffing is an attack people are actually doing.
> * guessing passwords against a live service is not an attack people are actually doing*
flat wrong ... if one thinks this, one likely isn't operating a high value target
> "Summer2024!" is perfectly fine, if you use it for exactly one service. Frankly, "1235" is probably fine. No one is out there brute-forcing passwords.
Respectfully, I disagree. "Summer2024!" is probably the second password I'd try after the username itself if I have to guess a password. Use it in a password spraying attack on a company with 500 users and you will get a few hits, I promise.
It's a fair point, but I think my argument still stands. Guessability is a different property from entropy, yeah? "Summer1975!" has the same entropy, but you probably wouldn't have put that into your password sprayer.
I wasn't an Apple user until almost exactly a year ago, and the auto-generated passwords were an inspiration to me to cobble together a script that generates such passwords in multiple languages [1]. I couldn't find any info on these passwords, so I am glad this is posted, because indeed, I find the format brilliant!
[1] https://pypi.org/project/applephrase/
This is awesome. Thank you
How much more entropy do you really get for 1 additional capital letter. Probably only a few bits worth 8-12.
I imagine the main reason for the single capital letters is to make the password acceptable on those annoying websites with annoying requirements, not necessarily to add entropy.
If you already know it's in apple password format, then you know 1/17 of the letters are capital, but not which one so the number of combinations you have to try is multiplied by 17, for just over 4 additional bits of entropy.
You multiply the entropy of the previous word by the added entropy of the new symbol. This grows exponentially!
Extra character classes can help if you're stuck needing to make a really short password for some reason, but if you're randomly generating each symbol anyway, just tossing a few more on the end is *far* more effective. You massively increase the brute force search space with each additional symbol.
Switching one uppercase letter in an otherwise lowercase password adds exactly 1 bit of entropy (per switched letter).
On the other hand, any extra lowercase letter will increase the entropy by 4.7 bits (assuming a password on [a-z]).
Given that most passwords have at best 2 uppercase letters, I would argue it is safer to force longer passwords than passwords with at least one uppercase letter.
A 10 character password with all lowercase is 47 bits, if you do half upper/half lower it goes to 57 (using Shannon entropy).
question: would it be possible/smart to have a system where the entity that is authenticating you has a way to disclose to you the maximum password complexity that it can handle ? Something like a GeekCode string that you can feed to your password generator and come out with a the strongest password possibly handled by the system ?
One place where this has saved me is trying to type in my VRChat password, on a standalone Quest 3 headset. The tedium of trying to type in a password in VR with a virtual keyboard, while having the headset slid up onto my forehead juuuust enough so I can see my phone with my password manager on it, is by far the worst modern login process I've ever experienced. Just having pronounceable syllables is enough to speed that process up significantly.
I always liked the 1Password word passwords… you select the number of words and it generates each word in upper OR lowercase, and connect them with symbols or numbers. Easy to memorize, and better then keepass or others that use more fixed formats: same characters between words and words are just in title format where the first letter is upper case and rest is lowercase.
The problem is that many sites still use archaic password rules.
1Password should by default just always capitalize one word, and add “1” at the end of the memorable password. Since the words are separated by “-“ or “.”, you already hit the “at least one symbol” rule.
I was presently surprised by the password requirements when I created a bugzilla account just the other day.
I went with the phrase option.I’ve seen minimums of 8 and 12, and maximums as low as 20.
AgileBits obviously has done a lot more profiling, but it would be nice if they developed a universal password formula that was still memorable. So with words, “-“ separator (or maybe “.” separator?), maximum length 18, one whole word capitalized, random single digit at the end or beginning.
That way you keep maximum entropy, keep it readable, whilst fitting within the rules of “all” sites.
Although within 5-10 years I see passkeys having largely taken over, especially because mom and pop won’t be able to forget those, and they won’t be able to forget their fingerprint or face either.
I especially like sites that disallow pasting into password fields.... Yes, that is apparently a thing, especially for banking or finance related sites (from my experience)
For a while, the login for TreasuryDirect (the gov site for buying US bonds) disabled paste and typing! It required you to click out your password on an onscreen keyboard.
I pity the folks who don’t know how to use dev tools.
Good on 'em for doing a complete 180 on that. Bank of Melbourne has stated that using a Password Manager is a violation of their Terms of Service (as people have complained about the non-pasteable/autofill fields).
You buried the lead there:
A required on-screen keyboard with RANDOM GENERATED LAYOUT.
I'm a big fan of the "Don't mess with paste" bookmarklet that I got from this thread a while back: https://news.ycombinator.com/item?id=38014653
One click and I can paste anyway. Nyah nyah nyah nyah nyah nyah.
I've been working in finance for 15 years, and the amount of security theatre we're forced to do by various parties is monotonically increasing year by year.
The way it works is you have a hundred government regulators around the world, full of underpaid bureaucrats straight out of school, who introduce vague, poorly thought out requirements. The consequences of non-compliance often being existential for the business: you can lose your license, your clients, and in some cases, your freedom.
Next a bunch of lawyer/compliance-y types take those requirements from around the world and try to distil them down to a specific (but onerous) set of controls by interpreting the guidelines cautiously. Obviously all they care about is making sure that if you do get popped, you can claim you did everything in compliance with the regulations and you get to continue trading.
Often these rules are transitive too, so you need to have some level of certainty that the other parties in your supply chain are also compliant, so independent auditors spring up to provide some third party accreditation. Your CFO sees this purely as a cost and doesn't want to pay much for it, so the pressure is to make this auditing as simple as possible, so their checklists become oriented around things they can easily check to demonstrate compliance with a particular control.
So some original requirement like "it should not be possible to share passwords between multiple users" ends up being bastardised down the chain until the item on the checklist is "don't allow pasting into the password field". Obviously by this point, everyone's actually forgotten why that checklist item was created, so even if the original requirement disappears, the checklist item lives on, often, forever.
It's only in rare, high profile circumstances where a previous requirement is explicitly and noisily repudiated that old items tend to disappear. Even then it can take years. I'm still having to fight back auditors asking for mandatory monthly password changes, for example, in a system that uses passkeys...
Brave has a “force paste” option. Would be nice if 1Password used that.
Although some sites go as far as monitoring input. If you don’t manually focus the field before pasting, the login action will be untriggerable.
I despise sites that disallow pasting into fields.
Banks seem to really like to now allow you to paste direct deposit information, which is insane. I get that they likely are thinking, well we don't want you type it into the first field and copy it into the second.
But I am copying it right from my bank's website, being forced to type it twice is just going to make it more likely I enter an error and I can guarantee you I am looking at that first field when I am typing the verification one.
Why is this even a allowed by browsers?
The web developer should not be able to disable pasting. Just like they should not be able to disable autofill, and other features that the user wants and has enabled.
So many things web sites do that are counter to the user's expectation, where I think to myself: Why even have that lever?
I always make that the default in my 1Password instances. If the threats we're trying to protect against are mainly 1) weak passwords and 2) password reuse, then there's still room there for human-friendly readable passwords. I don't see much marginal benefit of generating something like cnC*i8Npc2J7zWRYFfsy (the common default template across password managers) over teo-PRETENDS4cognac.
I’ve been using 1Password since 2008 and didn’t even know this was an option. It defaulted to complete randomness and I always just left it there. Typically not an issue, but it is annoying on the rare occasion I need to type something. I’ll have to consider this when making new accounts in the future, or updating old ones.
I liked the previous password generation in Keychain when you chose memorable password. It would be two words with a couple of numbers and/or symbols in between.
That option isn't available anymore though.
I use 1Password to store it though and have since 1Password 7, maybe sooner.
The extra randomness really only buys you a couple extra bits of entropy, but makes it more annoying to remember which format your password is in. It’s much more effective (entropy-wise and memory-wise) to tack on an extra word.
There is/was a fork of KeePass[0] that had a similar "pronounceable passwords" feature where you'd end up with things like "JorbHamstrayPrablem" or other things that sound like they'd come out of Coach Z's mouth.
[0] Not the one I'm currently using, and I don't remember which
It is a KeePass extension called Readable Passphrases or something like that, based on that one XKCD comic.
No, it's not that. That uses real words, e.g. correct-horse-battery-staple.
KeepassXC? I use it, and it lets you generate passphrases like that (as opposed to passwords).
Why not just use real words with longer password instead? That'd be easier to type than these shorter "word-like" syllables
When typing through a TV remote or console controller, shorter passwords might be preferred, especially if parts are still easily memorizable.
Also, I think some website still have a relatively low upper limit for password length.
Apple TV lets you use your phone to input passwords, so in Apple's ecosystem they wouldn't care about that. And being Apple, they wouldn't care about people needing to use anyone else's devices.
Website length limits are a problem though, in the worst case there are websites that silently truncate your password so you don't even realize that the first 12 (or whatever) characters are the only part that matters. If your first 12 characters are two words with a dash in the middle, that could be a real vulnerability.
Another benefit of passkeys is that it limits the ability of websites to do that kind of stupid shit.
> And being Apple, they wouldn't care about people needing to use anyone else's devices.
Did you RTFA?
>> To make these passwords easier to type on suboptimal keyboard layouts like my colleague’s game controller, where the mode switching might be difficult, these new passwords are actually dominated by lowercase characters. And to make it easier to short-term have in your head little chunks of it to bring over to the other device, the passwords are based on syllables. That’s consonant, vowel, consonant patterns. With these considerations put together, in our experience, these passwords are actually a lot easier to type on a foreign, weird keyboard, in the rare instances where that might be needed for some of our users.
Roku, who has about 50% of the streaming device market in the US, supports entering passwords via their mobile apps.
Having to enter a password on a streaming device is rare event for me at least. Almost all of the apps on my Roku support using an off device web browser to authenticate.
> Roku, who has about 50% of the streaming device market in the US
Wow, really? That's surprising to me, do you have a link so I can see the rest of the stats?
Even if horse-battery-staple works mathematically people don't trust that it's "really random".
1password supports it as "memorable password".
Seclist actually has a similar password "correct-horse-battery-staple" in one of their dictionary.
Just use the dictionary on your local machine.
> Seclist actually has a similar password "correct-horse-battery-staple" in one of their dictionary.
There's a well-known reason for that (and for GPs comment): https://xkcd.com/936/
We know from user generated passwords that people trust even less random stuff just fine
But you could always have an option for a different, more random-looking, style
Here's a format I really like:
3CatsHave12Legs!
Easy to memorize, and pretty strong.
The vast majority of passwords does not need to be easy to memorize because they should be stored in a password manager. In fact, I'd argue that the harder it is to memorize, the stronger the password.
Yet they still need to be typed on cell phone keyboards, TVs, or communicated over phone (shared passwords are the best compromise if asymmetric cryptography is not an option), in which case you usually need to spell it out anyway.
Cell phone keyboards should have a "QR code input" and then you could just use a QR code generated by your password manager dynamically.
Why mention memorizing passwords? Most people have dozens of passwords, and most people would have trouble memorizing even a simple word for dozens of passwords. I have a lot of trouble with those annoying security questions which one would assume would be constant and easy to answer.
How many more passwords of this format can you construct? `have` is fixed, the `!` at the end is a classic, and the 12 number is pre-determined by true cats and the 3. So the only degrees of freedom you have are:
- the entity number (3)
- the kind of entity (Cats)
- the kind of part (Legs)
and that's not a huge number of combinations.
"My4BikesHave9WheelsBecause1IsATricycle?" is a valid one for example?
The question mark makes this look like it's the title of a new hit light novel
You have to type that all in without error and the archaic app needs to actually support that many characters
I write longer passwords than that periodically. Archaic applications will get shorter variants. No two app will share the same password.
All are no problems for me. With or without a password manager.
Typing that all in without error is considerably easier than typing TMJ0ltu*zif52Cb& in without error.
In theory* having to type it is supposed to be a rare edge case.
Once I wrote a little pet project to sample words from /usr/share/dic/words and concat them together to produce "memorable" passwords. It was fun but certainly not good enough for real world use.
At the end of the day any password manager will do the job, the problem is getting people (friends & family) to use them.
I like the apple password keychain feature too but there have to be rules in place too.
username max 10
password min 32 - batteryhorsestaple structure - 3 languages
strong and easy
When I started CS decades ago, our student passwords for our server accounts were all similarly generated. They were given to us on a slip of paper, of course, and I still remember the two I was given over 20 years later. I was (naively) bummed when I didn't see this practice in the industry after graduation
Am I the only one who is frustrated that most password dialogs wont accept emoji as input?
I want poo-fire-poo-puke, dammit!
Oh dear, did I just reveal a secret password?
71 bits of entropy feels rather low...
It seems like many recommendations are to use at least 75-100, or even 128. Being fairly conservative, if you had 10k hosts hashing 1B passwords a second, it would take 7.5 years worst case to crack [1]. If a particular site neglects to use a slow hash function and salting, it's easy to imagine bad actors precomputing rainbow tables that would make attacks relatively easy.
You can rebut that that's still a crazy amount of computation needed, but since it's reusable, I find it easy to believe it's already being done. For comparison, if the passwords have 100 bits of entropy, it would take those same 10k servers over 4 billion years to crack the password.
[1]: (2*71 / 1e9 / 10000 / (606024*365)) ≈ 7.5
I think the assumption is that this is going into a somewhat modern hashing algorithm like argon, bcrypt (created 1999 - that's a quarter-century ago), or scrypt with salt. With those assumptions, the calculations aren't reusable, and definitely not 1B passwords / second.
If that's not true and the password is being stored using MD5 (something that's been NIST-banned at this point for over a decade), then honestly all bets are off, and even 128 bits of entropy might not be enough.
While I generally like Apple format, it still fails due to including ambiguous characters.
Such as: i, I, l, L, o, O, 0,
Key generation on iOS 12 is unlike generating entropy during AES encryption through a mouse.
That's why my own password generator on my phone (which predates any password generation by iOS) uses base58 encoding.
At least in my iOS 18 Passwords app, the passwords are shown in a monospace font that (probably deliberately) differentiates all these (e.g. a slashed zero).
It sounds like a clever design giving the complex topic, I will like to read some qualitative and quantitative research with real users to validate the design.
And when reading this I was thinking, what about Chinese logographic writing system or Arabic alphabet? Apple has a similar password design solution but for those cases?
Nobody will probably like it but I just use pwgen to generate passwords now and store it in 1Password since Keychain removed the memorable password option.
This would be a more secure and much more ergonomic option:
Your command produces passwords like this: I can't even copy it by double clicking on it.Mine produces passwords like this:
It even has more entropy by one or two orders of magnitude.I usually end up piping the result to a file so I can see it and edit if I need to and cat | pbcopy the file contents to the clipboard and save it in 1password. After that, 1password either fills in the password for me or copying it is just a button click.
The main issue I face is that some web sites will either not allow passwords longer than a certain length or will only allow some special characters.
TIL!
Looks like a good design
Doing something like randomly sampling a range of a-zA-Z0-9 and all the symbols without order or structure is absolutely the worse way of doing it for passwords that humans need to type/read, or in fact anything that might get tripped by special characters (like shell scripts, etc)
Yes yes you might lose a bit of entropy, just add one or two characters to it and it will make up for it. Passwords are not so much bruteforced from zero anymore rather than leaked from places with bad password hashes
I just opened the Password app for the first time to look at the generator. It seems like the pattern is: [a-zA-Z0-9]{6}\-[a-zA-Z0-9]{6}\-[a-zA-Z0-9]{6} with exactly only one uppercase char and one digit. I don't want to do the maths but that looks like a lot of removed entropy.
Fully random: 62^18 in that format, or about 107 bits of entropy.
Their approach: ~71 bits per the article (I counted ~73 bits but I’m not using their exact algorithm)
I’d say it’s not too bad. With a good password hashing algorithm you’re looking at nearly 2^100 operations to bruteforce their passwords, which isn’t going to be feasible anytime soon. (Even with a crappy hash algorithm it’s still going to be over 2^80 operations).
And, in this case, that entropy trade off means the passwords are easier to remember and type in, making it more likely for humans to actually use those passwords.
He mentions the entropy in the article...
Right, thanks. So from 160 bits down to 70 bits of entropy (there is also fancy syllables and bad words to take into account).
Quite the opposite
> these new passwords have 71 bits of entropy, up from the 69 from the previous format.
I am referring to the loss of entropy compared to a (theoretically) fully random 20-chars password.
Nit, 160 bits of entropy would be if you could get 8 bits per character, but that’s highly unrealistic. 6.0~6.3 bits is more feasible based on what most websites will tend to accept, which lands you at around 120-126 bits of entropy for a fully random password.
*They just FYI.
Does anyone have concerns that this reduces the variance of passwords to something than 35^(character length) because of rules like pronounceable memorable and typeable?
^20 is a big number.
Reminder that Diceware uses real words strung together:
* https://en.wikipedia.org/wiki/Diceware
* https://diceware.rempe.us/
* https://packages.debian.org/search?keywords=diceware
thank you for this! i was looking for an easy way to generate passwords for this, and while diceware isn't in my distro's repos, turns out the EFF publishes the word list and the method to generate them online, making it super easy to make a small bash script to generate these! here's the link:
https://www.eff.org/dice