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 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!
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.
Just today I had to reset my Dropbox password b/c it had a "`" character, and I was trying to use a self-service printer at FedEx. Their weird touch keyboard didn't have backticks.
I still have fond memories of "Xyzzy" which was specifically listed as a "pronounceable password generator." That and YAPS on Palm (Yet Another Password Safe) were a great combination - and migrations through the years may mean that I still have a few of those passwords sitting in an unused corner of my current password storage.
The iOS keyboard layout and behavior for many years undoubtedly made password rules like this a necessity - can't be mode switching all the time just to put in a password.
Edit: Xyzzy could also be used to generate plausible drug names or RPG character names.
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
Many corporations require you to have special characters as part of the password and won’t let you create one without them. This is in addition to authentication AND forcing an RSA soft token with a PIN. Many of these firms have had ransomware attacks and attempt to shield by having multilayer network DMZs which you have to traverse to reach a production network. Onerous mesh of required frequent password changes add to the mix. All done with a mishmash of security primitives.
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.
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.
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.
oh gosh... you just reminded me... it's even worse if you are wearing glasses under the vr set. You try to lift up vr and that lifts glasses into your forehead and you can't see anything and it hurts.
These devices are where a physical keys like yubikeys made the most sense. You set one to quickly access services. And you can then quickly invalidate one that is lost. Better than passkeys that try to get me to use a big phone for that purpose.
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 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
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.
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).
I like the generator with the exception of hyphens. Many sites don’t allow them or treat them as a special character. Unfortunately there is no longer any way that I’ve found to tweak rules. There was once a way buried under a few menus but it’s gone.
I hear a lot of complaints about Apple’s generated passwords, but I like them a lot and find them quite easy to memorize for the reasons listed in the article.
Safari also (sometimes) can recognize when “special” characters aren’t allowed, but doesn’t always work and doesn’t seem to detect password length limits, forcing me to manually adjust the password. Usually this just means deleting the hyphens and/or removing the last cluster to bring the length down to 16 or 12 characters.
Parsing out the password requirements from webpages seems like a good use for Apple Intelligence…
By the way, I just found out that older versions of VNC (such as tigervnc and x11vnc) that are still part of modern distros such as Ubuntu use only the first 8 characters of the password. This fact is in itself questionable, but then just dropping the remainder of the characters and not telling the user is plain stupid and unacceptable.
I’d really love to find this dictionary of filthy terms that exists on Apple device for the sake of cleaning passwords. Is it compiled in the code or encrypted? I can’t imagine it’s just laying around in clear text. In a way, both cases are kind of funny when you think about it.
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.
Isn't this essentially the correct horse battery staple method? The only reason I could see anything wrong with it is if the dictionary is somehow limited.
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
I just use my own password hashing tool to make the passwords. Only time I have problems is when the site restricts which characters I'm allowed to use, or enforces a maximum length, especially a different max length on the login vs the creation of the password. (Looking at you PayPal!)
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?
What are the typical password requirements in the Chinese and Arabic writing worlds? Given how rarely English-first websites even accept non-ascii characters within passwords, I honestly have no idea.
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
Why make people enter the dash? On some devices this means switching to the "special characters" mode. And if they are always in the same place, they contribute nothing to entropy/security.
"This post briefly summarizes part of a talk I gave in 2018. All information in this post has been accessible on YouTube since then. There is no new information or news in this post."
[+] [-] mr_mitm|1 year ago|reply
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.
[+] [-] Terretta|1 year ago|reply
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.
[+] [-] brnt|1 year ago|reply
[1] https://pypi.org/project/applephrase/
[+] [-] lhamil64|1 year ago|reply
[+] [-] hoten|1 year ago|reply
[+] [-] fencepost|1 year ago|reply
The iOS keyboard layout and behavior for many years undoubtedly made password rules like this a necessity - can't be mode switching all the time just to put in a password.
Edit: Xyzzy could also be used to generate plausible drug names or RPG character names.
[+] [-] davedx|1 year ago|reply
[+] [-] IOT_Apprentice|1 year ago|reply
[+] [-] vbezhenar|1 year ago|reply
The password generators that generate me 20 characters of different character classes are crazy.
[+] [-] nothercastle|1 year ago|reply
[+] [-] coldpie|1 year ago|reply
"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.
[+] [-] graypegg|1 year ago|reply
[+] [-] beretguy|1 year ago|reply
[+] [-] RockRobotRock|1 year ago|reply
[+] [-] skydhash|1 year ago|reply
[+] [-] calgoo|1 year ago|reply
[+] [-] jorvi|1 year ago|reply
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.
[+] [-] the_snooze|1 year ago|reply
[+] [-] al_borland|1 year ago|reply
[+] [-] hk1337|1 year ago|reply
That option isn't available anymore though.
I use 1Password to store it though and have since 1Password 7, maybe sooner.
[+] [-] nneonneo|1 year ago|reply
[+] [-] VyseofArcadia|1 year ago|reply
[0] Not the one I'm currently using, and I don't remember which
[+] [-] Nifty3929|1 year ago|reply
[+] [-] raverbashing|1 year ago|reply
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
[+] [-] tuxone|1 year ago|reply
[+] [-] tiffanyh|1 year ago|reply
Such as: i, I, l, L, o, O, 0,
[+] [-] explodingwaffle|1 year ago|reply
[+] [-] blame-troi|1 year ago|reply
[+] [-] eviks|1 year ago|reply
[+] [-] lemagedurage|1 year ago|reply
Also, I think some website still have a relatively low upper limit for password length.
[+] [-] bombcar|1 year ago|reply
1password supports it as "memorable password".
[+] [-] DuckConference|1 year ago|reply
[+] [-] wwalexander|1 year ago|reply
Safari also (sometimes) can recognize when “special” characters aren’t allowed, but doesn’t always work and doesn’t seem to detect password length limits, forcing me to manually adjust the password. Usually this just means deleting the hyphens and/or removing the last cluster to bring the length down to 16 or 12 characters.
Parsing out the password requirements from webpages seems like a good use for Apple Intelligence…
[+] [-] bobbylarrybobby|1 year ago|reply
[+] [-] amelius|1 year ago|reply
[+] [-] polycaster|1 year ago|reply
[+] [-] LorenDB|1 year ago|reply
[+] [-] ellisv|1 year ago|reply
At the end of the day any password manager will do the job, the problem is getting people (friends & family) to use them.
[+] [-] reginald78|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] betenoire|1 year ago|reply
[+] [-] Dwedit|1 year ago|reply
[+] [-] pentagrama|1 year ago|reply
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?
[+] [-] sethaurus|1 year ago|reply
[+] [-] hk1337|1 year ago|reply
[+] [-] mr_mitm|1 year ago|reply
Mine produces passwords like this:
It even has more entropy by one or two orders of magnitude.[+] [-] mi_lk|1 year ago|reply
[+] [-] remram|1 year ago|reply
[+] [-] andreareina|1 year ago|reply
[+] [-] mmooss|1 year ago|reply
"This post briefly summarizes part of a talk I gave in 2018. All information in this post has been accessible on YouTube since then. There is no new information or news in this post."