Apple Passwords’ generated strong password format

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.

How much more entropy do you really get for 1 additional capital letter. Probably only a few bits worth 8-12.

A 10 character password with all lowercase is 47 bits, if you do half upper/half lower it goes to 57 (using Shannon 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.

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.

Enough that it's worth thinking about. It's not frequent but it happens.

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.

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.

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.

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.

> "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.

People are definitely running dictionaries against password hash leaks. Both examples look like they might be in a dictionary.

Low entropy means your password will be cracked if a list of password hashes leaks.

So what?

> 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.

It's a fair point, but I think my argument still stands. Guessability is a different property from entropy, yeah? "Summer1975!" has the same entropy, but you probably wouldn't have put that into your password sprayer.

I'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.

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.

I, personally, use my own password generator to generate passwords using 10 lowercase ASCII characters excluding ilo. That's 45 bits of entropy or one year of brute forcing trying 1 million attempts per second. I consider that a reasonable strength for all but the most important websites.

The password generators that generate me 20 characters of different character classes are crazy.

I 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/

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."

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.

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.

> 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.

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.

KeepassXC allows you to customize its password generator according to your preferences.

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.

>guessing passwords against a live service is not an attack people are actually doing

Credential stuffing is an attack people are actually doing.

This is awesome. Thank you

I'm using Apple Safari passwords storage, it's enough for me, but KeePass is definitely great.

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.

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/

Love KeepassXC. Even if you don't want to go full offline, I think Bitwarden does the same.

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

> 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.

> * 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 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.

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.

I do something like this surprisingly often when dealing with iDRAC/IPMI/etc:

    sleep 3; xdotool type "abc123"

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.

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!

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

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

> 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.

Such sites that do not allow Apple passwords I now skip as a user (unless it’s a government site), it says enough about how you view security and there are plenty of competitors that don’t do this

I use:

  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).

>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.

.. and now the password is stored unencrypted in your bash history.

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.

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.

also, excessive minimums. I once encountered a website with 20 minimum characters, which I think is longer than some sites' max length.

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:

  $ sleep 5 ; xdotool type 'RC-A"c\EJe,0l@q'

>> physical device provided by the customer.

Hardware : Rubber Ducky - https://shop.hak5.org/products/usb-rubber-ducky

That's a feature, not a bug. :P

Alright if you prefer:

    read PW; sleep 3; xdotool type "$PW"

Or if it's already on your clipboard:

    sleep 3; xdotool type "$(xclip -o)"

Use the `read` method the other poster said, or ensure HISTCONTROL is set and then prepend a space to commands that contain secrets.

  $ export HISTCONTROL=ignoreboth
  $  echo 'supersecret' | whatever

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...

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.

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.

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 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.

I think 15 is a good secure minimum.

What websites are those, I am curious?

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.

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...

> 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).

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?

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/

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 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.

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.

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.

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.

> even worse when they don't properly enforce it and instead silently truncate it

JetBlue truncated to 10, e.g.:

    fly0nJetBlue -> fly0nJetBl

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!

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.

Add a double space somewhere, and append single space to the end just to be safe.

Just have Keepass pick from the extended ASCII set

    Å`÷½¸Å^çÏ+Í?«~Ðñø'`¾

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.

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.

Lots of wifi points these days come with passwords like "heavycream502" that nobody bothers changing.

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.

> 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 )

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/

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 :)

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.

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.

bcrypt has a built-in 72 byte limit, which helps with the DOS issue

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.

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.

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.

Transunion (credit reporting agency) does this, but after the 15th character.

As did HSBC.

Maybe there is a single space at the end. No way to know. Well done, GP.

I see you, and I raise you

    ĮǶľƶₔâ¾ijĤĬď©‘¦ı‰ęž‰śij²ÔķՎĜ́北¹«ƶ’–­ħ›ĸ«

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?

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 usually just throw a period in there.

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.

Just today I had to reset my Dropbox password b/c it had a "`" character, and I was trying to use a self-service printer at FedEx. Their weird touch keyboard didn't have backticks.

I went through this hell just last week with their terrible website. Jetblue has fallen a gew notches over the years.

A bunch of the Canadian banks too. TD Canada Trust I can personally confirm.

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.

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".

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.

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.

Doesn’t adding a random salt counter rainbow tables? Then you could have fewer requirements on the users

This is a sign they're storing it unhashed on a mainframe system. Airlines also do it.

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.

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.

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.

Yeah, it does. But I am over killing it cause I'm making stuff for myself and I'm using password manager.

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.

That’s not true. You can hash the truncated version

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...

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"?

The desire to truncate comes from wanting to store smaller fields in the database.

> 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.

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

well I want to have some chance at typing it in if I absolutely must...

If I remember correctly they only recommend against password rotation when MFA is in place, which is significantly more important anyway.

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.

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...

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!

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.

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.

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…!

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.

Prefix any command with a space and bash won't append to the history.

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

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.

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.

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

Careful that's only true if you set HISTCONTROL to "ignorespace" or "ignoreboth".

Agreed just because a company thinks my threat model doesn't require anything but letters and should be short enough to memorize, sure does not mean they are correct. Apple is collectively dumbing down complexity for selfish reasons and then not allowing you the user to change default complexity and length. Looks like the only problem they were trying to solve was reuse which might be a plus one for the Apple device population but I am not sure the trade off is really worth it. But hey it's free!

Which seems the default in my anecdotal experience on debian/Ubuntu.

It is also the default on fish shell in the same anecdotal experience.

This is an interesting suggestion but I’m running Ubuntu on a MacBook Air while traveling. When I set up the new home office though, I will try this tactic. Thanks for the idea.

I use a password manager but usually leave it set to lowercase, uppercase and numbers.

Then you get my personal favorite, which is sites that force you to use symbols, but when you do, they say you've used illegal symbols, but don't even tell you what symbols they accept, or which of the ones you've used were illegal.

Lucky my password is very secure, "Èͧ¾÷øÏ¡þää£àèÀ¸Àþ¡ï×ÕÞ£¸«"

>if you expect to always be able to autofill, use as many character classes as possible

I use a password manager but generally set it to only upper, lower and numbers and 24 characters, because so many sites seem to be broken for symbols.

But I do live in fear of the sites that are broken for long passwords (or even worse, silently broken).