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.
even worse when they don't properly enforce it and instead silently truncate it.
There was a PayPal bug just a couple years ago where the reset-password page didn't enforce length like other pages did. So it allowed you to create an otherwise illegal password and then your account is completely locked out (I guess, unless you realized the truncation was happening...)
And so I would reset my password, generate a new one... and it would happen again. Took me a while to realize it was the length and not a special character I added messing up with bad encoding logic or something.
Thank you for confirming I'm not crazy. I remember having the same problem a few years back and looking up online if anyone had the same problem as me, but found nothing at the time.
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.
I worked in IT at a tech company that had mandatory 90-day password rotations. That place had the highest rate of “password on sticky note” that I’ve ever seen.
On the tenth call to my bank in the same year to reset one of our user passwords, the account rep just volunteered to them the information that "there is an option you can check on an obscure settings page to NOT have the mandatory password rotation, you know".
At a bank back in the Blackberry days they were handed out with Qwerty1 as the default password. Just incrementing the digit would get you into 80%+ devices in the firm.
I worked for a financial company that had 29 day password rotation. One day I accidentally logged in as my colleague. Our user names differed by just one letter so I simply mistyped. It turned out we used the same password scheme to keep up with the rotation and stupid special character requirements.
My memory is that PCI regulations require password rotation every 90 days - also that the minimum password length should be seven characters, not the eight I always answer when quizzed.
Unless there's a rate limit for changing passwords I just rapidly change them X+1 times and arrive back at my original. This only applies to work stuff, which I don't keep in my password manager.
In my experience, changing the password at big corps usually locks you out and requires a call to IT. I had a success rate of about 50% when I had to change passwords. It was the most frustrating thing...
"Oh yeah your password change properly is not synced to all servers yet. Just wait and try again later"
"Oh you tried the new password too many times while it was not synced yet. Your account is now locked. You need a manager approval to unlock your account."
I remember being shocked when I realized that Charles Schwab, a bank that manages untold illions of dollars, was ignoring everything after the 8th character in their passwords. This was still true until a few years ago.
I remember this. I had enough funds with them at the time (and I am also in tech so I insisted on a technical explanation) that I was able to speak with their security team about the reason for the limit and when it would be fixed. It has been fixed and they require 2FA now (however they require a very specific app for it). Overall my experience with them over the last 10 years has been good.
TLDR; limit on older mainframe system, however password were properly hashed & they plan to remove the limit in the next year, which they did.
> Usernames and passwords containing letters need to be translated to numbers to enter them in a Fidelity phone system (like FAST®, or if you call a representative). Use your telephone keypad to convert the letters to numbers. There is no case sensitivity. Substitute an asterisk (*) for all special characters. Here's an example:
> To enter a username, e.g., Smith123, press or say 7-6-4-8-4-1-2-3
> To enter a password, e.g., Lucky1$23, press or say 5-8-2-5-9-1-*-2-3
> There is a special place in hell for anyone who creates a maximum password length limit
People abuse everything, you can be dossed trying to compute <pick your hashing algorithm-of-choice> of a password as big as the maximum body size your webserver accept (which is a limit btw, so remember to dress light :-p )
Don't tell me that if you allow long passwords you'll run into the body size limit of the http server when you set the maximum password length to a measly 16 bytes because your choice of password hash scales like O(length(password)*iterations) which opens you up to a denial of service if you allow longer passwords. 50, 100, even 200 byte passphrases are reasonable and make no discernible performance difference to sanely designed auth servers.
There's no reason* why the time a hashing algorithm takes to do security rounds should vary with the length of the user's password. If you want to prevent DoS as GP mentioned then run all passwords through one round of a (fast) secure hash algorithm, then do security rounds with the output. This is what Argon2 does by default https://en.wikipedia.org/wiki/Argon2
Haha - i have the same kind of Logic. Would be great if Bitwarden would add this appendix as an option as it is required on quite a number of websites…!
It's not really meaningful to measure entropy of a single password, only of a distribution of passwords. You could assume a password comes from some distribution, but how would you know? Does "grefn" come from a distribution of "pick a 5 letter dictionary word and then randomly change one letter or a distribution of "pick 4-7 random ASCII characters"?
> It's not really meaningful to measure entropy of a single password
Here’s a ‘not meaningful’ formula then: E = L × log₂(R)
• E is the entropy, in bits, representing how hard the password is to crack.
• L is the password length (number of characters).
• R is the size of the character set (e.g., 26 for lowercase letters, 52 for upper/lowercase, 62 if digits are included).
• log₂(R) is the number of bits needed to represent each character.
I hear your point: a single password might not actually use all character types, so the actual entropy could be less than its potential. Maybe they could have drawn from a wider range and didn’t.
But for everyday user feedback, assuming the fewest sets seems fine to nudge people toward picking stronger passwords.
One definition for the randomness of a finite string is the size of the smallest program that produces it. The definition is dependent on how programs are interpreted.
If my string is "aaaa", does that mean its entropy is zero? There is at least information about its length. And by your definition, how do we know that this password isn't from a 256 character set? Does "Aaab" have 26 times the entropy of "aaab"?
Topics like this make more sense to me when the strings are infinite, or when the population of strings is known.
A good password generator should check that the random generation did not give too many repeats or that the password is not easily guessed by a simple common password list
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
Not GP, but I had one just the other day that didn’t allow dashes in the password, but did require a special character (of a list of like a dozen, just not including dash). Also, it wasn’t that the dash wasn’t recognized as a special character, but that it wasn’t allowed at all. Wish I could remember what site now.
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.
An important distinction that often gets lost is that entropy is a property of a probability distribution. A system to generate passwords has entropy, one specific password does not.
It's possible to read "hunter2" from /dev/random.
To infer entropy from a single password, the best you can do is to see if it falls within the domain of some known, low-entropy systems. This works ok in practice, but is very far from perfect.
To be fair, one specific password does tell you something about the entropy of the generator. If I can grab 1 MiB of data from your password generator, I can probably estimate quite well the entropy of the generator. 10-20 bytes? That tells you almost nothing (but still not nothing). That means there must be some way of updating an estimate of the entropy of the generator from every additional byte of output and the amount of confidence that you gain about that estimate grows (probably exponentially) with every new byte.
But your password is 10-20 bytes so you can say nothing about the generator.
Well, trying to infer entropy of a password by classifying it into the lowest possible low entropy system actually works well against brute forcing because brute forcing usually works exactly doing that.
That's the crucial point. You can have a super high entropy probability distribution straight from a quantum lava lamp, but if it gives you "hunter2" as a password, you should still not use that password, no matter the entropy of the distribution.
Right, I was just about to ask: Entropy is the measure of how "surprised" I'll get from the next character in the password. It's not a property of the password, it's a property of me. "Γεια" is very surprising to everyone here, as everyone would assume the first character to be English, but not if you know that the user is Greek.
>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.
The NIST guidelines have changed "should not" to "shall not" for 800-63B this year. The reason this is important is that the very first NIST guidelines recommended rotations and composition rules. Even after 800-63B was first published, people continued to use the earlier guidelines under the assumption it was better and the "should" wording let them keep doing it. The shall change should force a broader change which is why it's significant. Another notable change this year is the banning of security questions:
> Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
> Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
> Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
> Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
Estimating entropy is challenging because it's a reverse process from how it ought to work. I created https://phrase.shop, which generates passphrases with a known quantity of entropy. Hover over any of the three action buttons to see exactly how many bits of entropy will be used to generate the passphrase.
In my personal website template I required a length of 15 characters and at least one of each: lower+upper case letter, number and symbol, to counter rainbow tables.
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.
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.
If you ever have to do that again it might be worth considering some hardware assistance. An ESP32 S2 or S3, from what I've read, can act as a USB HID and emulate a keyboard from the computer's point of view. The necessary code is included in the ESP32 libraries for Arduino, with examples [1], so for software all you'd need is the Arduino IDE or command line tools, which run fine on Linux.
With that it would be easy to build a temporary "type my secret key" dongle.
An ESP32 S2 or S3 dev kit board from a reputable source along with the other necessary hardware would probably be under $20.
There are also some models of Arduino that have the necessary USB support such as the Arduino Leonardo [2], but the Leonardo is more than an EPS32 at the non-sketchy sellers I've seen.
Even if you've never played around with microcontrollers this would be a beginner level project.
I add some of my more common passwords as macros on my keyboard. No companion software, just firmware. Saves a lot of time and now the passwords can be typed anywhere by just plugging yhe keyboard in! I've also added my email :)
As you note many devices now have mechanisms that let you enter the password from a phone or computer where it should be possible to copy/paste from a password manager.
But that usually requires some sort of two way communication between your computer or phone and the device you are setting up or requires that the device has a network connection to a server that your phone or computer can also connect to.
You may still need to manually enter the password for that network connection.
Many WiFi streaming TV boxes are like that if I recall correctly. Manual setup to give them network access, but then later when setting up apps on them for Disney+, Netflix, and the like the apps can use an authentication protocol that doesn't need manual password entry.
I make my WiFi password easy to type for that reason.
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.
Some characters felt illegal to use in passwords, like starting your password with space. Not only feels, but will not pass validation during sign up in many places.
those things are dogshit. It's really incredible how terrible and difficult Kinkos has made the process of printing. The email service has also never worked for me.
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
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.
If Apple’s password manager required websites to indicate compliance before generating passwords for them, it would defeat the goal of a password manager to work with existing sites. It’s not like Apple invented the idea of a password manager.
Reasonable sites should already allow passwords of the sort Apple generates, because they tick the usual boxes (length, entropy, and the pointless at-least-one-uppercase/digit/punctuation requirement). Now, many websites are not reasonable and enforce even-more-pointless requirements. Apple tries to mitigate this with a hardcoded list of popular websites’ password policies [1], which is used to tailor password generation for those websites. To be fair, this approach doesn’t scale for smaller websites. But there’s not much more Apple could do. In any case, at this point websites have had many years to adapt to Apple’s password manager and its password style (which has not changed recently).
Accepting passkeys doesn’t cost money, and they’re based on a web standard. There are valid objections to passkeys but this ain’t it.
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.
Bitwarden's password generation is actually a little weak - it's great at generating random gibberish passwords, but it seems to be randomized at the character level so you'll get things like "Cq$ypWocG6Byp#" - hard to remember, hard to type. It lets you specify length, upper, lower, digits, (limited) special, minimum # of digits, minimum # of special, and "avoid ambiguous characters" but that's the extent of it. Even the ability to have it group character types would be helpful if you're ever going to be typing on mobile devices.
It also offers Passphrase generation using dictionary words plus digits and specials (as word separators). You can change the special character used, but it's not randomly chosen each time.
I'd love it if it had an option for pronounceable or syllable-based generation as described in the article.
Sure that's fine for things that truly don't matter, but if you're using a password manager then you might as well generate more characters. Bear in mind there is no guarantee that services storing your passwords are using something like bcrypt with slow settings. I've definitely seen things like PBKDF2 set to comically low iterations or even raw sha/md5.
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).
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.
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.
Why is it my responsibility to keep my data secure? You (the ~1+bil dollar company) should be responsible for that if my password is 65 characters of gibberish or `111`.
I just find it funny that my bank doesn't say to reset my bank website password if my identity gets stolen or there's fraudulent charges on my account. They go after the root of the problem.
I'm not sure i know which side of the debate you're on but the analogy that comes to mind is if you put your watch on a shelf in Walmart, they're supposed to protect it for you? It's absolutely your responsibility to lock your doors at night even if the bank currently owns your home.
People are walking around trying car doors at night and people are throwing dictionaries and tables at log in forms. Would you blame the bank if someone guessed your password of 1234? How are they supposed to tell it isn't you?
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.
> is cracking password hashes still hard, given modern GPU hardware techniques
Yes, if the entropy is high enough. What else would be the point of salting and hashing passwords?
There's no known way to reverse major hash algorithms like SHA-256 or bcrypt; you have to try all the combinations. So you have to do exponential work in the amount of entropy whereas GPUs only give a constant factor speedup over CPUs.
If this ever changes (e.g., someone breaks SHA-256 or bcrypt) you will definitely see it as the #1 story on HN (and probably pretty prominently in mainstream media too).
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.
The measure of uniqueness is effectively entropy (entropy = log base 2 of the number of possible passwords). Ease of use is just unnecessary (for entropy purposes) padding on top of that (constraints on symbol sets, order, etc). The necessary threshold is entirely dependent on your threat model, combined with the risks that your use cases are exposed to when using the password.
Your point that using entropy rich passwords is foolish, is incorrect most of the time, and even if it weren't people's general understanding of where specifically to draw that line is generally significantly underestimated as a collective. The evidence of this is the amount of data breach information available, and the actual attacks which are available using this information.
Service breaches happen where the password database is insufficiently secured, and that often correlates strongly with insufficient protection of the password hashes. This means that low entropy passwords can be cracked and used for a period of time before the data breach is discovered. Entropy (and MFA) are the only protections against that.
56 DES was cracked in a day in 1999. Your passwords should definitely have more entropy than that. Probably around 80 bits is enough (about 16 alphanumeric characters or so). Your much lower threshold on entropy is insufficient for pretty much any reasonable threat model except public access.
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.
Summer1975! would be equally likely to be checked by a password sprayer. It has the same number of hits on HIBP, and falls into a category where heuristic password guess algorithms would generally group them as being the same thing.
My old work used to give a default month-year-org name and an exclamation mark. The majority of people who still used it was insane. LinkedIn was a treasure trove for logging into accounts.
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.
OH yeah I can imagine. Now you have your glasses about to smush into your eyes, your vision is blurry, the quest is probably making some "about to sleep" sound now because you're trying to pull your glasses away, which the headset interprets as it being removed and of course... will decide to cull the app you were in so you can start the godforesaken process all over again.
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 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.
Not sure why people are re-inventing the wheel here. Just use zxcvbn[0] to determine password strength, and reject passwords if it falls below an unacceptable minimum. Because you can compute it client-side, you can give real-time feedback.
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)
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...
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).
For whomever is interested, IIRC, this requirement of random layout came up in late 2000/early 2010 due to:
- keyloggers (safer to click instead of type instead -> on-screen keyboard then)
- but then it turned out Internet Explorer had a bug which allowed attackers to read the mouse click events' X/Y coordinates in other windows which then could be mapped to the on-screen keyboard digits if the layout is predictable
I'm aware of one case where it's a useful feature: the "type this name to delete" form on GitHub (found elsewhere as well).
The purpose, which is to make sure the user knows what they're deleting permanently, is defeated if they can copy the end of the URL string and paste it straight in. Adding a bit of friction there is helpful.
The actual answer to your question is more like "someone thought it was a good idea and now we're stuck with it", though. More browsers should offer a force paste in the context menu, because when said is done, it's my browser, and if I want to do something, I should be able to do it.
> I'm aware of one case where it's a useful feature: the "type this name to delete" form on GitHub
While I like the dialogue it’s only a step up over a confirmation dialog (forcing you to switch from clicking to typing). So disabling paste don’t add anything to that. I’d rather they have a trash section so I can undelete or force remove the project.
A less vicious but similarly dumb ‘ux/security’ measure is when the password being entered only registers after a key event fires while the field is in focus. An event that never occurs with password manager autocomplete, making the user add a random character and then remove it.
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.
There is a force paste context menu in brave. Firefox should copy the feature as well, if they still have anyone who works on new features for the browser.
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
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.
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’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.
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.
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.
I don't believe that was an option when I set mine up but that was a few years ago. Also there is a wide range of Roku devices and TVs with differing capabilities so even ig mine didn't it might be that some do support this. I honestly don't know.
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.
Ok, but if there isn't a high-entropy sequence of "something you know" somewhere in the system, you've created some pretty bad failure modes. 1Password requires a master password periodically, but can otherwise be unlocked by AppleID (presumably also true for secure-element biometrics on other platforms).
I maintain that a good secrets management system has a number of passwords which should be memorizable (and memorized) which is greater than zero. Possibly by only one element.
Every password manager I know of, including Apple's, requires a strong password to unlock the vault. FaceID or YubiKey allow me to bypass typing that so often, but anyone trying to get into my accounts or password manager would have to know the strong password and get past the physical/biometric 2FA.
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:
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…
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!)
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
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.
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.
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.
"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."
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?
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 ?
Yeah, actually, that would work fine. But the people who maintain the login pages don't update their complexity rules right half the time, so the geekcode would go out of date quickly, and you'd end up spitting out invalid passwords, and people would stop using it
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:
Also, people speak languages other than English, and things like Unicode normalization mean that identical characters can be encoded differently depending on what's being used to type the password in, and I'd be willing to bet most websites don't handle that properly. Not to mention non-latin alphabets, which can be even messier. Good luck explaining to someone that the reason their bank's website isn't matching their password is due to there being two ways to encode "olá" (and there isn't a good way to use a specific one, or know which one was used to set the password!)
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.
If you have an adversary that can afford to tie up 10k servers each capable of doing gigahash per second for 7.5 years go ahead and use a stronger password. And while you're at it you better buy the best physical security that money can buy.
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.
even worse when they don't properly enforce it and instead silently truncate it.
There was a PayPal bug just a couple years ago where the reset-password page didn't enforce length like other pages did. So it allowed you to create an otherwise illegal password and then your account is completely locked out (I guess, unless you realized the truncation was happening...)
And so I would reset my password, generate a new one... and it would happen again. Took me a while to realize it was the length and not a special character I added messing up with bad encoding logic or something.
> even worse when they don't properly enforce it and instead silently truncate it
JetBlue truncated to 10, e.g.:
So I can tell you it's even worse when they silently truncate it on save, and on some logins, but not on all logins!I went through this hell just last week with their terrible website. Jetblue has fallen a gew notches over the years.
Thank you for confirming I'm not crazy. I remember having the same problem a few years back and looking up online if anyone had the same problem as me, but found nothing at the time.
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.
I worked in IT at a tech company that had mandatory 90-day password rotations. That place had the highest rate of “password on sticky note” that I’ve ever seen.
On the tenth call to my bank in the same year to reset one of our user passwords, the account rep just volunteered to them the information that "there is an option you can check on an obscure settings page to NOT have the mandatory password rotation, you know".
At a bank back in the Blackberry days they were handed out with Qwerty1 as the default password. Just incrementing the digit would get you into 80%+ devices in the firm.
I worked for a financial company that had 29 day password rotation. One day I accidentally logged in as my colleague. Our user names differed by just one letter so I simply mistyped. It turned out we used the same password scheme to keep up with the rotation and stupid special character requirements.
My memory is that PCI regulations require password rotation every 90 days - also that the minimum password length should be seven characters, not the eight I always answer when quizzed.
PCI DSS 4.0[0] requirement 8.3.9 updates this to 12 characters and only requires rotation if the password is the only factor used for authentication.
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
If I remember correctly they only recommend against password rotation when MFA is in place, which is significantly more important anyway.
Unless there's a rate limit for changing passwords I just rapidly change them X+1 times and arrive back at my original. This only applies to work stuff, which I don't keep in my password manager.
In my experience, changing the password at big corps usually locks you out and requires a call to IT. I had a success rate of about 50% when I had to change passwords. It was the most frustrating thing...
"Oh yeah your password change properly is not synced to all servers yet. Just wait and try again later"
"Oh you tried the new password too many times while it was not synced yet. Your account is now locked. You need a manager approval to unlock your account."
Symbols should be restricted to the set that are mostly insensitive to keyboard layout.
'!' is a good one. Quotation marks are not. Currency signs are not.
I usually just throw a period in there.
I remember being shocked when I realized that Charles Schwab, a bank that manages untold illions of dollars, was ignoring everything after the 8th character in their passwords. This was still true until a few years ago.
I remember this. I had enough funds with them at the time (and I am also in tech so I insisted on a technical explanation) that I was able to speak with their security team about the reason for the limit and when it would be fixed. It has been fixed and they require 2FA now (however they require a very specific app for it). Overall my experience with them over the last 10 years has been good.
TLDR; limit on older mainframe system, however password were properly hashed & they plan to remove the limit in the next year, which they did.
Wait til you see what Fidelity does.. https://www.fidelity.com/customer-service/faqs-managing-your...
> Usernames and passwords containing letters need to be translated to numbers to enter them in a Fidelity phone system (like FAST®, or if you call a representative). Use your telephone keypad to convert the letters to numbers. There is no case sensitivity. Substitute an asterisk (*) for all special characters. Here's an example:
> To enter a username, e.g., Smith123, press or say 7-6-4-8-4-1-2-3
> To enter a password, e.g., Lucky1$23, press or say 5-8-2-5-9-1-*-2-3
A bunch of the Canadian banks too. TD Canada Trust I can personally confirm.
This is a sign they're storing it unhashed on a mainframe system. Airlines also do it.
That’s not true. You can hash the truncated version
The desire to truncate comes from wanting to store smaller fields in the database.
Transunion (credit reporting agency) does this, but after the 15th character.
As did HSBC.
also, excessive minimums. I once encountered a website with 20 minimum characters, which I think is longer than some sites' max length.
I think 15 is a good secure minimum.
> There is a special place in hell for anyone who creates a maximum password length limit
People abuse everything, you can be dossed trying to compute <pick your hashing algorithm-of-choice> of a password as big as the maximum body size your webserver accept (which is a limit btw, so remember to dress light :-p )
Don't tell me that if you allow long passwords you'll run into the body size limit of the http server when you set the maximum password length to a measly 16 bytes because your choice of password hash scales like O(length(password)*iterations) which opens you up to a denial of service if you allow longer passwords. 50, 100, even 200 byte passphrases are reasonable and make no discernible performance difference to sanely designed auth servers.
There's no reason* why the time a hashing algorithm takes to do security rounds should vary with the length of the user's password. If you want to prevent DoS as GP mentioned then run all passwords through one round of a (fast) secure hash algorithm, then do security rounds with the output. This is what Argon2 does by default https://en.wikipedia.org/wiki/Argon2
bcrypt has a built-in 72 byte limit, which helps with the DOS issue
Haha - i have the same kind of Logic. Would be great if Bitwarden would add this appendix as an option as it is required on quite a number of websites…!
70% of all passwords in Japan. 8-10 characters max length is the most common.
I understand where it comes from (having computer systems designed by people who never spend a second thinking about your language) but still.
It’s 2024!
It's not really meaningful to measure entropy of a single password, only of a distribution of passwords. You could assume a password comes from some distribution, but how would you know? Does "grefn" come from a distribution of "pick a 5 letter dictionary word and then randomly change one letter or a distribution of "pick 4-7 random ASCII characters"?
> It's not really meaningful to measure entropy of a single password
Here’s a ‘not meaningful’ formula then: E = L × log₂(R)
• E is the entropy, in bits, representing how hard the password is to crack.
• L is the password length (number of characters).
• R is the size of the character set (e.g., 26 for lowercase letters, 52 for upper/lowercase, 62 if digits are included).
• log₂(R) is the number of bits needed to represent each character.
I hear your point: a single password might not actually use all character types, so the actual entropy could be less than its potential. Maybe they could have drawn from a wider range and didn’t.
But for everyday user feedback, assuming the fewest sets seems fine to nudge people toward picking stronger passwords.
One definition for the randomness of a finite string is the size of the smallest program that produces it. The definition is dependent on how programs are interpreted.
If my string is "aaaa", does that mean its entropy is zero? There is at least information about its length. And by your definition, how do we know that this password isn't from a 256 character set? Does "Aaab" have 26 times the entropy of "aaab"?
Topics like this make more sense to me when the strings are infinite, or when the population of strings is known.
A good password generator should check that the random generation did not give too many repeats or that the password is not easily guessed by a simple common password list
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
What websites are those, I am curious?
Not GP, but I had one just the other day that didn’t allow dashes in the password, but did require a special character (of a list of like a dozen, just not including dash). Also, it wasn’t that the dash wasn’t recognized as a special character, but that it wasn’t allowed at all. Wish I could remember what site now.
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.
An important distinction that often gets lost is that entropy is a property of a probability distribution. A system to generate passwords has entropy, one specific password does not.
It's possible to read "hunter2" from /dev/random.
To infer entropy from a single password, the best you can do is to see if it falls within the domain of some known, low-entropy systems. This works ok in practice, but is very far from perfect.
To be fair, one specific password does tell you something about the entropy of the generator. If I can grab 1 MiB of data from your password generator, I can probably estimate quite well the entropy of the generator. 10-20 bytes? That tells you almost nothing (but still not nothing). That means there must be some way of updating an estimate of the entropy of the generator from every additional byte of output and the amount of confidence that you gain about that estimate grows (probably exponentially) with every new byte.
But your password is 10-20 bytes so you can say nothing about the generator.
Well, trying to infer entropy of a password by classifying it into the lowest possible low entropy system actually works well against brute forcing because brute forcing usually works exactly doing that.
That's the crucial point. You can have a super high entropy probability distribution straight from a quantum lava lamp, but if it gives you "hunter2" as a password, you should still not use that password, no matter the entropy of the distribution.
Right, I was just about to ask: Entropy is the measure of how "surprised" I'll get from the next character in the password. It's not a property of the password, it's a property of me. "Γεια" is very surprising to everyone here, as everyone would assume the first character to be English, but not if you know that the user is Greek.
>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.
The NIST guidelines have changed "should not" to "shall not" for 800-63B this year. The reason this is important is that the very first NIST guidelines recommended rotations and composition rules. Even after 800-63B was first published, people continued to use the earlier guidelines under the assumption it was better and the "should" wording let them keep doing it. The shall change should force a broader change which is why it's significant. Another notable change this year is the banning of security questions:
> Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and > Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. > Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
> Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
Estimating entropy is challenging because it's a reverse process from how it ought to work. I created https://phrase.shop, which generates passphrases with a known quantity of entropy. Hover over any of the three action buttons to see exactly how many bits of entropy will be used to generate the passphrase.
In my personal website template I required a length of 15 characters and at least one of each: lower+upper case letter, number and symbol, to counter rainbow tables.
Doesn’t adding a random salt counter rainbow tables? Then you could have fewer requirements on the users
Yeah, it does. But I am over killing it cause I'm making stuff for myself and I'm using password manager.
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 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:Prefix any command with a space and bash won't append to the history.
Careful that's only true if you set HISTCONTROL to "ignorespace" or "ignoreboth".
I would simply save that into 1password and never have to type it or remember it ever again.
In your obscure set of requirements (no paste?), yes you might have to copy it again, but at least you don't have to remember it.
1?Z-2>@.#x3O0_l^,fNO%0o
Your comment was interesting to me, so I was trying to come up with the most "ergonomically unsound" password. How did I do?
Add a double space somewhere, and append single space to the end just to be safe.
Maybe there is a single space at the end. No way to know. Well done, GP.
Just have Keepass pick from the extended ASCII set
I see you, and I raise you
well I want to have some chance at typing it in if I absolutely must...
> 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.
If you ever have to do that again it might be worth considering some hardware assistance. An ESP32 S2 or S3, from what I've read, can act as a USB HID and emulate a keyboard from the computer's point of view. The necessary code is included in the ESP32 libraries for Arduino, with examples [1], so for software all you'd need is the Arduino IDE or command line tools, which run fine on Linux.
With that it would be easy to build a temporary "type my secret key" dongle.
An ESP32 S2 or S3 dev kit board from a reputable source along with the other necessary hardware would probably be under $20.
There are also some models of Arduino that have the necessary USB support such as the Arduino Leonardo [2], but the Leonardo is more than an EPS32 at the non-sketchy sellers I've seen.
Even if you've never played around with microcontrollers this would be a beginner level project.
[1] https://github.com/espressif/arduino-esp32/tree/master/libra...
[2] https://docs.arduino.cc/hardware/leonardo/
I add some of my more common passwords as macros on my keyboard. No companion software, just firmware. Saves a lot of time and now the passwords can be typed anywhere by just plugging yhe keyboard in! I've also added my email :)
As you note many devices now have mechanisms that let you enter the password from a phone or computer where it should be possible to copy/paste from a password manager.
But that usually requires some sort of two way communication between your computer or phone and the device you are setting up or requires that the device has a network connection to a server that your phone or computer can also connect to.
You may still need to manually enter the password for that network connection.
Many WiFi streaming TV boxes are like that if I recall correctly. Manual setup to give them network access, but then later when setting up apps on them for Disney+, Netflix, and the like the apps can use an authentication protocol that doesn't need manual password entry.
I make my WiFi password easy to type for that reason.
Enough that it's worth thinking about. It's not frequent but it happens.
this is the way, completely random letters, numbers, symbols as many as it will let you use; let the computer do the work for you
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.
You're entering your Dropbox password on other people's machines? Was there no option to just share the document as a public link or something?
I reset my password again shortly after.
Some characters felt illegal to use in passwords, like starting your password with space. Not only feels, but will not pass validation during sign up in many places.
those things are dogshit. It's really incredible how terrible and difficult Kinkos has made the process of printing. The email service has also never worked for me.
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.
Lots of wifi points these days come with passwords like "heavycream502" that nobody bothers changing.
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.
If Apple’s password manager required websites to indicate compliance before generating passwords for them, it would defeat the goal of a password manager to work with existing sites. It’s not like Apple invented the idea of a password manager.
Reasonable sites should already allow passwords of the sort Apple generates, because they tick the usual boxes (length, entropy, and the pointless at-least-one-uppercase/digit/punctuation requirement). Now, many websites are not reasonable and enforce even-more-pointless requirements. Apple tries to mitigate this with a hardcoded list of popular websites’ password policies [1], which is used to tailor password generation for those websites. To be fair, this approach doesn’t scale for smaller websites. But there’s not much more Apple could do. In any case, at this point websites have had many years to adapt to Apple’s password manager and its password style (which has not changed recently).
Accepting passkeys doesn’t cost money, and they’re based on a web standard. There are valid objections to passkeys but this ain’t it.
[1] https://github.com/apple/password-manager-resources/blob/mai...
I don’t get this complaint. Apple’s password generation and quirks “database” is open source and anyone can use it and do a pull request
https://github.com/apple/password-manager-resources/tree/mai...
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...
There‘s also some work to be able to indicate these rules via an HTML attribute but the work is a bit stalled.
https://www.stefanjudis.com/today-i-learned/safari-allows-to...
https://github.com/whatwg/html/issues/3518
Another cool feature Apple spearheaded was the ability for websites to indicate the change password page in standard manner: https://w3c.github.io/webappsec-change-password-url/
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.
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.
Bitwarden's password generation is actually a little weak - it's great at generating random gibberish passwords, but it seems to be randomized at the character level so you'll get things like "Cq$ypWocG6Byp#" - hard to remember, hard to type. It lets you specify length, upper, lower, digits, (limited) special, minimum # of digits, minimum # of special, and "avoid ambiguous characters" but that's the extent of it. Even the ability to have it group character types would be helpful if you're ever going to be typing on mobile devices.
It also offers Passphrase generation using dictionary words plus digits and specials (as word separators). You can change the special character used, but it's not randomly chosen each time.
I'd love it if it had an option for pronounceable or syllable-based generation as described in the article.
I'm using Apple Safari passwords storage, it's enough for me, but KeePass is definitely great.
Sure that's fine for things that truly don't matter, but if you're using a password manager then you might as well generate more characters. Bear in mind there is no guarantee that services storing your passwords are using something like bcrypt with slow settings. I've definitely seen things like PBKDF2 set to comically low iterations or even raw sha/md5.
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).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
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).
Wouldn't that be 54.98 bits? 57 bits would be if you allowed mixed case with no constraint on how many are upper and how many are lower.
With the constraint that it has to be half upper/half lower you only get 252 times as many passwords instead of 1024 times as many.
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.
Why is it my responsibility to keep my data secure? You (the ~1+bil dollar company) should be responsible for that if my password is 65 characters of gibberish or `111`.
I just find it funny that my bank doesn't say to reset my bank website password if my identity gets stolen or there's fraudulent charges on my account. They go after the root of the problem.
I'm not sure i know which side of the debate you're on but the analogy that comes to mind is if you put your watch on a shelf in Walmart, they're supposed to protect it for you? It's absolutely your responsibility to lock your doors at night even if the bank currently owns your home.
People are walking around trying car doors at night and people are throwing dictionaries and tables at log in forms. Would you blame the bank if someone guessed your password of 1234? How are they supposed to tell it isn't you?
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.
> is cracking password hashes still hard, given modern GPU hardware techniques
Yes, if the entropy is high enough. What else would be the point of salting and hashing passwords?
There's no known way to reverse major hash algorithms like SHA-256 or bcrypt; you have to try all the combinations. So you have to do exponential work in the amount of entropy whereas GPUs only give a constant factor speedup over CPUs.
If this ever changes (e.g., someone breaks SHA-256 or bcrypt) you will definitely see it as the #1 story on HN (and probably pretty prominently in mainstream media too).
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.
The measure of uniqueness is effectively entropy (entropy = log base 2 of the number of possible passwords). Ease of use is just unnecessary (for entropy purposes) padding on top of that (constraints on symbol sets, order, etc). The necessary threshold is entirely dependent on your threat model, combined with the risks that your use cases are exposed to when using the password.
Your point that using entropy rich passwords is foolish, is incorrect most of the time, and even if it weren't people's general understanding of where specifically to draw that line is generally significantly underestimated as a collective. The evidence of this is the amount of data breach information available, and the actual attacks which are available using this information.
Service breaches happen where the password database is insufficiently secured, and that often correlates strongly with insufficient protection of the password hashes. This means that low entropy passwords can be cracked and used for a period of time before the data breach is discovered. Entropy (and MFA) are the only protections against that.
56 DES was cracked in a day in 1999. Your passwords should definitely have more entropy than that. Probably around 80 bits is enough (about 16 alphanumeric characters or so). Your much lower threshold on entropy is insufficient for pretty much any reasonable threat model except public access.
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.
> 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
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.
> "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.
Summer1975! would be equally likely to be checked by a password sprayer. It has the same number of hits on HIBP, and falls into a category where heuristic password guess algorithms would generally group them as being the same thing.
My old work used to give a default month-year-org name and an exclamation mark. The majority of people who still used it was insane. LinkedIn was a treasure trove for logging into accounts.
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.
OH yeah I can imagine. Now you have your glasses about to smush into your eyes, your vision is blurry, the quest is probably making some "about to sleep" sound now because you're trying to pull your glasses away, which the headset interprets as it being removed and of course... will decide to cull the app you were in so you can start the godforesaken process all over again.
The mobile app used to have a feature to let you type from your phone but Meta removed that because fuck you
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 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.
Not sure why people are re-inventing the wheel here. Just use zxcvbn[0] to determine password strength, and reject passwords if it falls below an unacceptable minimum. Because you can compute it client-side, you can give real-time feedback.
[0] https://github.com/dropbox/zxcvbn
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)
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...
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.
For whomever is interested, IIRC, this requirement of random layout came up in late 2000/early 2010 due to:
- keyloggers (safer to click instead of type instead -> on-screen keyboard then)
- but then it turned out Internet Explorer had a bug which allowed attackers to read the mouse click events' X/Y coordinates in other windows which then could be mapped to the on-screen keyboard digits if the layout is predictable
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.
Brave has a ‘force paste’ option in the right click context menu, that way you don’t need an extension. Awesome feature
Why is disabling paste even a thing that a website is allowed to do?
I'm aware of one case where it's a useful feature: the "type this name to delete" form on GitHub (found elsewhere as well).
The purpose, which is to make sure the user knows what they're deleting permanently, is defeated if they can copy the end of the URL string and paste it straight in. Adding a bit of friction there is helpful.
The actual answer to your question is more like "someone thought it was a good idea and now we're stuck with it", though. More browsers should offer a force paste in the context menu, because when said is done, it's my browser, and if I want to do something, I should be able to do it.
> I'm aware of one case where it's a useful feature: the "type this name to delete" form on GitHub
While I like the dialogue it’s only a step up over a confirmation dialog (forcing you to switch from clicking to typing). So disabling paste don’t add anything to that. I’d rather they have a trash section so I can undelete or force remove the project.
A less vicious but similarly dumb ‘ux/security’ measure is when the password being entered only registers after a key event fires while the field is in focus. An event that never occurs with password manager autocomplete, making the user add a random character and then remove it.
It's slower but out of spite I usually go into the console and remove the `onpaste="false"` nonsense from their markup.
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.
There is a force paste context menu in brave. Firefox should copy the feature as well, if they still have anyone who works on new features for the browser.
Firefox has had this feature for a long time.
Set dom.event.clipboardevents.enabled to false in about:config.
That is not the same. On Brave it is just a right click and then "force paste".
Plus, I suspect that setting disables the buttons on sites that copy the entire field to your buffer.
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?
Totally agree! My strategy is to use no word separators, and add the same sequence (dash, number, letter) at the end of every password.
Here's the generator I built if you want to try it yourself:
https://home.jrmann.com/utilities/godango.html
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).
[dead]
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.
While I generally like Apple format, it still fails due to including ambiguous characters.
Such as: i, I, l, L, o, O, 0,
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).
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.
It's less of an issue on high-resolution screens.
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’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.
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.
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.
How about during initial setup of the Roku itself? Can you use the mobile app to give the Roku your WiFi password?
I don't believe that was an option when I set mine up but that was a few years ago. Also there is a wide range of Roku devices and TVs with differing capabilities so even ig mine didn't it might be that some do support this. I honestly don't know.
> 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?
https://www.coolest-gadgets.com/streaming-devices-statistics...
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.
Have you not memorized the password to your password manager?
How would that even work?
FaceID or YubiKey
Ok, but if there isn't a high-entropy sequence of "something you know" somewhere in the system, you've created some pretty bad failure modes. 1Password requires a master password periodically, but can otherwise be unlocked by AppleID (presumably also true for secure-element biometrics on other platforms).
I maintain that a good secrets management system has a number of passwords which should be memorizable (and memorized) which is greater than zero. Possibly by only one element.
Every password manager I know of, including Apple's, requires a strong password to unlock the vault. FaceID or YubiKey allow me to bypass typing that so often, but anyone trying to get into my accounts or password manager would have to know the strong password and get past the physical/biometric 2FA.
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
Typing that all in without error is considerably easier than typing TMJ0ltu*zif52Cb& in without error.
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.
[dead]
In theory* having to type it is supposed to be a rare edge case.
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…
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Site seems to be down. Here's a Wayback Machine link: https://web.archive.org/web/20241009143931/https://rmondello...
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!)
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
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.
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.
Because a lot of sites these days require special (but not too special) characters.
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!
(2018)
"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."
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?
Article says it has 71 bits of entropy, that's a number with 22 digits in it. It's not really an issue.
^20 is a big number.
https://archive.is/DKOtf
Archive.is snapshot of the article
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
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 ?
Apple/OP actually maintains a list of crowdsourced password rules for websites https://github.com/apple/password-manager-resources/blob/mai...
On one hand it’s terrible that they have to do this. On the other, in terms of attention to detail and user experience it’s great.
Apple some years ago proposed a string format for password rules – to be used in password managers and also an HTML attribute for that:
It seems implemented in Safari and UIKit, but I can’t find any implementation documentation for other brothers. Sad.https://developer.apple.com/password-rules/
https://developer.apple.com/documentation/security/customizi...
I think we just moved to Passkeys for that.
Yeah, actually, that would work fine. But the people who maintain the login pages don't update their complexity rules right half the time, so the geekcode would go out of date quickly, and you'd end up spitting out invalid passwords, and people would stop using it
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
Compile and drop it into /usr/local or /opt:
* https://github.com/ulif/diceware
Apple Passwords are precisely memorizable.
Obligatory: open source password rules and other info that anyone can use to generate passwords and contribute to the list. It’s used by WebKit.
https://github.com/apple/password-manager-resources/tree/mai...
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?
Why not just do the 4 english words thing? https://xkcd.com/936/
Because this is ~25% shorter, and have 71 bits of entropy instead of 44 bits.
Also, people speak languages other than English, and things like Unicode normalization mean that identical characters can be encoded differently depending on what's being used to type the password in, and I'd be willing to bet most websites don't handle that properly. Not to mention non-latin alphabets, which can be even messier. Good luck explaining to someone that the reason their bank's website isn't matching their password is due to there being two ways to encode "olá" (and there isn't a good way to use a specific one, or know which one was used to set the password!)
[dead]
[flagged]
-1 very obscure format.
Here's a great password dictionary that only contains common English words [1]. Use 5 words and you have a 70-bit password.
[1] https://github.com/sts10/generated-wordlists
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.
If you have an adversary that can afford to tie up 10k servers each capable of doing gigahash per second for 7.5 years go ahead and use a stronger password. And while you're at it you better buy the best physical security that money can buy.