[HN Gopher] Apple Passwords' generated strong password format
___________________________________________________________________
Apple Passwords' generated strong password format
Author : tambourine_man
Score : 309 points
Date : 2024-10-18 11:12 UTC (11 hours ago)
(HTM) web link (rmondello.com)
(TXT) w3m dump (rmondello.com)
| raverbashing wrote:
| 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
| tuxone wrote:
| 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.
| timabdulla wrote:
| He mentions the entropy in the article...
| tuxone wrote:
| Right, thanks. So from 160 bits down to 70 bits of entropy
| (there is also fancy syllables and bad words to take into
| account).
| eviks wrote:
| Quite the opposite
|
| > these new passwords have 71 bits of entropy, up from
| the 69 from the previous format.
| tuxone wrote:
| I am referring to the loss of entropy compared to a
| (theoretically) fully random 20-chars password.
| nneonneo wrote:
| 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.
| Veliladon wrote:
| *They just FYI.
| nneonneo wrote:
| 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.
| eviks wrote:
| Why not just use real words with longer password instead? That'd
| be easier to type than these shorter "word-like" syllables
| bombcar wrote:
| Even if horse-battery-staple works mathematically people don't
| trust that it's "really random".
|
| 1password supports it as "memorable password".
| eviks wrote:
| 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
| david422 wrote:
| Here's a format I really like:
|
| 3CatsHave12Legs!
|
| Easy to memorize, and pretty strong.
| rhaps0dy wrote:
| 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.
| bayindirh wrote:
| "My4BikesHave9WheelsBecause1IsATricycle?" is a valid one
| for example?
| nothercastle wrote:
| You have to type that all in without error and the
| archaic app needs to actually support that many
| characters
| bayindirh wrote:
| 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.
| BobaFloutist wrote:
| Typing that all in without error is considerably easier
| than typing TMJ0ltu*zif52Cb& in without error.
| Dilettante_ wrote:
| The question mark makes this look like it's the title of
| a new hit light novel
| mangodrunk wrote:
| 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.
| samatman wrote:
| Have you not memorized the password to your password
| manager?
|
| How would that even work?
| mr_mitm wrote:
| 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.
| bombcar wrote:
| Cell phone keyboards should have a "QR code input" and
| then you could just use a QR code generated by your
| password manager dynamically.
| edweis wrote:
| Seclist actually has a similar password "correct-horse-
| battery-staple" in one of their dictionary.
| curl https://raw.githubusercontent.com/danielmiessler/SecList
| s/refs/heads/master/Discovery/DNS/dns-Jhaddix.txt | grep
| "horse-battery-staple"
| zikduruqe wrote:
| Just use the dictionary on your local machine.
| sort -R /usr/share/dict/words | head -n 4| sed
| 's/.\*/&/;$!s/$// ' |tr '\n' '-' |sed 's/-$/\n/'
| unsterilized-compoundedness-betrayer-pentathlon
| scoot wrote:
| > _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/
| DuckConference wrote:
| In theory* having to type it is supposed to be a rare edge
| case.
| lemagedurage wrote:
| 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.
| wlesieutre wrote:
| 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.
| tssva wrote:
| 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.
| jeffhuys wrote:
| > 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?
| tssva wrote:
| https://www.coolest-gadgets.com/streaming-devices-
| statistics...
| jonhohle wrote:
| > 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.
| calgoo wrote:
| 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.
| nneonneo wrote:
| 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.
| the_snooze wrote:
| 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.
| jorvi wrote:
| 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.
| dark-star wrote:
| 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)
| yojo wrote:
| 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.
| commandersaki wrote:
| 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).
| nytesky wrote:
| You buried the lead there:
|
| A required on-screen keyboard with RANDOM GENERATED
| LAYOUT.
| nerdjon wrote:
| 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.
| ryandrake wrote:
| 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?
| kyleee wrote:
| 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.
| ziddoap wrote:
| Firefox has had this feature for a long time.
|
| Set dom.event.clipboardevents.enabled to false in
| about:config.
| jorvi wrote:
| 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.
| cameronh90 wrote:
| 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...
| bruckie wrote:
| 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.
| kyleee wrote:
| Brave has a 'force paste' option in the right click
| context menu, that way you don't need an extension.
| Awesome feature
| encom wrote:
| Why is disabling paste even a thing that a website is
| allowed to do?
| samatman wrote:
| 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.
| skydhash wrote:
| > _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.
| graftak wrote:
| 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.
| benced wrote:
| It's slower but out of spite I usually go into the console
| and remove the `onpaste="false"` nonsense from their
| markup.
| extraduder_ire wrote:
| 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 went with the phrase option.
| jorvi wrote:
| 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.
| jszymborski wrote:
| 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
| jrmann100 wrote:
| 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
| al_borland wrote:
| 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.
| hk1337 wrote:
| 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.
| mr_mitm wrote:
| 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.
| nothercastle wrote:
| How much more entropy do you really get for 1 additional
| capital letter. Probably only a few bits worth 8-12.
| candiddevmike wrote:
| A 10 character password with all lowercase is 47 bits, if you
| do half upper/half lower it goes to 57 (using Shannon
| entropy).
| tzs wrote:
| 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.
| zeta0134 wrote:
| 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.
| plopilop wrote:
| 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.
| bryanlarsen wrote:
| 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.
| lhamil64 wrote:
| 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.
| ezfe wrote:
| Enough that it's worth thinking about. It's not frequent but
| it happens.
| mr_mitm wrote:
| 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.
| aftbit wrote:
| I do something like this surprisingly often when dealing
| with iDRAC/IPMI/etc: sleep 3; xdotool
| type "abc123"
| rkeene2 wrote:
| 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
| didsomeonesay wrote:
| .. and now the password is stored unencrypted in your
| bash history.
| aftbit wrote:
| 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)"
| mmh0000 wrote:
| 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
| mmh0000 wrote:
| 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
| umanwizard wrote:
| 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.
| butlike wrote:
| 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?
| ziddoap wrote:
| Add a double space somewhere, and append single space to
| the end just to be safe.
| mr_mitm wrote:
| Maybe there is a single space at the end. No way to know.
| Well done, GP.
| encom wrote:
| Just have Keepass pick from the extended ASCII set
| A`/1/2,A^cI+I?<<~Dno'`3/4
| svieira wrote:
| I see you, and I raise you
| IHVlz[?]a3/4ijHIdA(c)|iesij2OkOGPey 1<<zhk<<
| browningstreet wrote:
| 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.
| tzs wrote:
| 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/
| Novosell wrote:
| 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 :)
| hoherd wrote:
| > 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.
| tzs wrote:
| 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.
| coldpie wrote:
| _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.
| mr_mitm wrote:
| > "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.
| coldpie wrote:
| 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.
| nemo8551 wrote:
| 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.
| jusssi wrote:
| People are definitely running dictionaries against password
| hash leaks. Both examples look like they might be in a
| dictionary.
| coldpie wrote:
| So what?
| fkyoureadthedoc wrote:
| 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.
| coldpie wrote:
| 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.
| fkyoureadthedoc wrote:
| 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.
| freedomben wrote:
| 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/
| jusssi wrote:
| 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.
| coldpie wrote:
| 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."
| freedomben wrote:
| 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.
| umanwizard wrote:
| > 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).
| Plutoberth wrote:
| 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.
| butlike wrote:
| 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.
| wholinator2 wrote:
| 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?
| umanwizard wrote:
| Low entropy means your password will be cracked if a list of
| password hashes leaks.
| joshka wrote:
| > 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.
| coldpie wrote:
| 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.
| ziddoap wrote:
| > _guessing passwords against a live service is not an
| attack people are actually doing_
|
| Credential stuffing is an attack people are actually
| doing.
| Terretta wrote:
| > * 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
| mr_toad wrote:
| > 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.
| aftbit wrote:
| 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.
| vbezhenar wrote:
| 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.
| aniviacat wrote:
| KeepassXC allows you to customize its password generator
| according to your preferences.
| vbezhenar wrote:
| I'm using Apple Safari passwords storage, it's enough for
| me, but KeePass is definitely great.
| seanw444 wrote:
| Love KeepassXC. Even if you don't want to go full offline,
| I think Bitwarden does the same.
| fencepost wrote:
| 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.
| Aloha wrote:
| 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
| johnisgood wrote:
| 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).
| evantbyrne wrote:
| 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.
| brnt wrote:
| 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/
| victor106 wrote:
| This is awesome. Thank you
| Terretta wrote:
| > _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.
| aftbit wrote:
| 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.
| mingus88 wrote:
| 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!
| ziddoap wrote:
| 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.
| Vegenoid wrote:
| 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.
| sebastiennight wrote:
| 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".
| stevekemp wrote:
| 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.
| mrWiz wrote:
| 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.
| umpalumpaaa wrote:
| 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."
| bobthepanda wrote:
| also, excessive minimums. I once encountered a website with
| 20 minimum characters, which I think is longer than some
| sites' max length.
| beretguy wrote:
| I think 15 is a good secure minimum.
| xahrepap wrote:
| 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.
| Terretta wrote:
| > _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!
| username135 wrote:
| I went through this hell just last week with their
| terrible website. Jetblue has fallen a gew notches over
| the years.
| mm_00 wrote:
| 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.
| HPsquared wrote:
| 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.
| icedchai wrote:
| I usually just throw a period in there.
| bsimpson wrote:
| 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.
| jp191919 wrote:
| Transunion (credit reporting agency) does this, but after
| the 15th character.
| happymellon wrote:
| As did HSBC.
| doubled112 wrote:
| A bunch of the Canadian banks too. TD Canada Trust I can
| personally confirm.
| riquito wrote:
| > 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 )
| mrbabbage wrote:
| bcrypt has a built-in 72 byte limit, which helps with the
| DOS issue
| vlovich123 wrote:
| 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.
| ziddoap wrote:
| > _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.
| vlovich123 wrote:
| 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.
| cobbal wrote:
| 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.
| tirant wrote:
| 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.
| stavros wrote:
| 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. "Geia" 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.
| pmw wrote:
| 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.
| davedx wrote:
| 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
| beretguy wrote:
| What websites are those, I am curious?
| beretguy wrote:
| 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.
| EligibleDecoy wrote:
| Doesn't adding a random salt counter rainbow tables? Then
| you could have fewer requirements on the users
| davedx wrote:
| 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
| echelon wrote:
| 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.
| comex wrote:
| 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...
| lathiat wrote:
| 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...
| realityking wrote:
| 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/
| fencepost wrote:
| 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.
| bsimpson wrote:
| Lots of wifi points these days come with passwords like
| "heavycream502" that nobody bothers changing.
| IOT_Apprentice wrote:
| 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.
| hoten wrote:
| 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.
| ivanjermakov wrote:
| 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.
| sebastiennight wrote:
| 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?
| hoten wrote:
| I reset my password again shortly after.
| pentagrama wrote:
| 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?
| throw0101b wrote:
| 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
| q0uaur wrote:
| 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
| throw0101b wrote:
| Compile and drop it into /usr/local or /opt:
|
| * https://github.com/ulif/diceware
| hk1337 wrote:
| 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
| mi_lk wrote:
| TIL!
| mr_mitm wrote:
| This would be a more secure and much more ergonomic option:
| pwgen --ambiguous --no-capitalize --secure 12
|
| Your command produces passwords like this:
| X3_>r"9'
|
| I can't even copy it by double clicking on it.
|
| Mine produces passwords like this:
| stq7nt4nvh3g
|
| It even has more entropy by one or two orders of magnitude.
| hk1337 wrote:
| 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.
| tiffanyh wrote:
| While I generally like Apple format, it still fails due to
| including ambiguous characters.
|
| Such as: i, I, l, L, o, O, 0,
| explodingwaffle wrote:
| 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).
| kccqzy wrote:
| That's why my own password generator on my phone (which
| predates any password generation by iOS) uses base58 encoding.
| unit149 wrote:
| Key generation on iOS 12 is unlike generating entropy during
| AES encryption through a mouse.
| mmooss wrote:
| It's less of an issue on high-resolution screens.
| VyseofArcadia wrote:
| 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
| Nifty3929 wrote:
| It is a KeePass extension called Readable Passphrases or
| something like that, based on that one XKCD comic.
| VyseofArcadia wrote:
| No, it's not that. That uses real words, e.g. correct-horse-
| battery-staple.
| seanw444 wrote:
| KeepassXC? I use it, and it lets you generate _passphrases_
| like that (as opposed to passwords).
| nashashmi wrote:
| 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?
| ec109685 wrote:
| ^20 is a big number.
| chrisshroba wrote:
| 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 / (60 _60_ 24*365)) [?] 7.5
| lordofmoria wrote:
| 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.
| betenoire wrote:
| 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
| gorkish wrote:
| Am I the only one who is frustrated that most password dialogs
| wont accept emoji as input?
| ChrisMarshallNY wrote:
| I want poo-fire-poo-puke, dammit!
|
| Oh dear, did I just reveal a secret password?
| mediumsmart wrote:
| 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_
| ellisv wrote:
| 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.
| reginald78 wrote:
| 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.
| graypegg wrote:
| 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.
| beretguy wrote:
| 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.
| graypegg wrote:
| 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.
| skydhash wrote:
| 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.
| pdxpatzer wrote:
| 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 ?
| sureIy wrote:
| I think we just moved to Passkeys for that.
| 0xbadcafebee wrote:
| 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
| madeofpalk wrote:
| Apple/OP actually maintains a list of crowdsourced password
| rules for websites https://github.com/apple/password-manager-
| resources/blob/mai...
| ttepasse wrote:
| Apple some years ago proposed a string format for password
| rules - to be used in password managers and also an HTML
| attribute for that: <input type="password"
| passwordrules="minlength: 8; maxlength: 12; required: lower;
| required: upper; required: digit; required: [-];">
|
| 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...
| LorenDB wrote:
| Site seems to be down. Here's a Wayback Machine link:
| https://web.archive.org/web/20241009143931/https://rmondello...
| 0xbadcafebee wrote:
| Why not just do the 4 english words thing? https://xkcd.com/936/
| sedatk wrote:
| Because this is ~25% shorter, and have 71 bits of entropy
| instead of 44 bits.
| notfed wrote:
| -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
| blame-troi wrote:
| 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.
| gnarlouse wrote:
| Apple Passwords are precisely memorizable.
| lukewrites wrote:
| https://archive.is/DKOtf
|
| Archive.is snapshot of the article
| mmooss wrote:
| (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."
| amelius wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-18 23:00 UTC)