
Safari Password Generation - tosh
https://twitter.com/_inside/status/959549503920660480
======
sgillen
I think putting in the effort and basically hard coding many popular solutions
is an underutilized strategy in dealing with these sorts of things. Many times
I see programmers try to come up with a general solutions which becomes a much
more difficult sort of problem.

~~~
niftich
Hand-harvesting data is a perfectly legitimate solution, although it comes
with a steep initial cost and an ongoing maintenance cost. However, this
enables the data to be curated and validated.

For this, they wanted to accurately capture the exact rules each site uses,
which makes sense to do out-of-band -- ahead of time, and validated by humans
-- than to try to discover from the site dynamically, especially because the
latter solution, in a world without sites making their own requirements
available in a programmatically readable format, would have been complex and
brittle.

In a program, this sort of data may be hard-coded directly in the code, or
dynamically loaded from config files. That's largely an implementation detail.

~~~
Bromskloss
> a world without sites making their own requirements available in a
> programmatically readable format

About that, is there a standardised way to do it?

~~~
chrismorgan
Not well for arbitrary rules, but for simple syntactic rules at least, regular
expressions in the `pattern` attribute of the <input type=password> will do
it. Bonus points for using look-ahead assertions for more complex
restrictions.

The following, for example, creates a password field that requires exactly six
ASCII letters, including at least one uppercase and one lowercase letter, and
forbidding having the same character twice in a row:

    
    
      <input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">

~~~
blattimwind
If your stateless password rules are stronger than a backtracking RE engine, I
have bad news for you.

~~~
rocqua
Isn't best practice to:

1) have a minimal password length 2) check all passwords against a set of
known bad passwords

I don't see a decent way to do 2) based on a backtracking RE engine.

~~~
chrismorgan
It’s a terrible approach, but it _is_ easily feasible. Here’s a simplified
pattern that forbids “password”, “123”, “1234”, “12345” and “123456”:

    
    
      (?!password$)(?!123(?:4(?:56?)?)?$).*

------
deedubaya
Password restrictions are the worst.

Office365 doesn't support passwords > 16 characters in length. WTF.

~~~
gruez
serious question: what's the issue? 16 characters alphanumeric = 95 bits of
entropy, which is enough for most purposes.

~~~
YSFEJ4SWJUVU6
With password generation, nothing really. If you want to choose the password
yourself, it limits your options (for no good reason for the user).

~~~
mediumdeviation
Yes - for instance it makes the Correct Horse Battery Stapler passphrase
strategy[1] difficult to apply, because now you can only pick words up to ~4
letters long.

[1]: [https://xkcd.com/936/](https://xkcd.com/936/)

------
osteele
Someday maybe the web will catch up with: “Memorized secrets SHALL be at least
8 characters in length if chosen by the subscriber. Memorized secrets chosen
randomly by the CSP or verifier SHALL be at least 6 characters in length and
MAY be entirely numeric. […] No other complexity requirements for memorized
secrets SHOULD be imposed.” — 5.1.1.1 Memorized Secret Authenticators, NIST
Special Publication 800-63B: Digital Identity Guidelines Authentication and
Lifecycle Management
[https://pages.nist.gov/sp800-63b.html](https://pages.nist.gov/sp800-63b.html)

~~~
orf
> Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6
> characters in length and MAY be entirely numeric.

Is that really secure? I mean, 6 numbers is not exactly a very strong secret.

~~~
Terribledactyl
It's fine if you can invalidate the secret after some finite number of tries
and block a particular actor from attacking many accounts. And there's no
leaking cross sites if someone obtains and breaks the salted hash db.

------
mojuba
I think the Web could come up with a robots.txt-like standard where all the
requirements for passwords, usernames, maybe even form field names etc. would
be published in a parseable form.

~~~
SquareWheel
The "pattern" attribute on an <input> can do that using regex.

------
blattimwind
This looks to me like something you could (literally) throw up on Github as a
JSON file, so that it's easily updated by people and usable to other
applications.

------
firefoxd
Wouldn't it make more sense to have this information in the website's
manifest? This way we don't have to wait for a manual update and it doesn't
have to be limited to Safari

~~~
Antrikshy
Well, yes, but standards are kinda hard to incite.

~~~
cal5k
Sounds like we need a standard for setting standards to make this easier!

------
sashk
Great. As long they attempt to keep these rules up-to-date.

Recently, saw strange thing -- I was allowed to have password with lengths
between 16 and 128 characters, but my password manager 1Password supports
only... 60 or 64 characters. Oh well, wish that _this_ would be a problem, not
other way around. Still kills me that my health records are behind 12
characters password, and my bank think 16 character password is enough.

~~~
jsjohnst
I have several 100+ character passwords stored in 1Password.

~~~
sashk
Yes, 1Password supports long passwords, but it's password generator can
generate only 64 character long. (I'm not talking about word-based passwords).

~~~
jsjohnst
Ah yes, agree there. What I do is generate twice and combine together,
annoying, but works.

------
Bromskloss
Is there a way (for a non-MacOS user) to have a look at this database? I seem
to remember that there was a website that collected password requirements, but
i can't find it.

~~~
scarlac
I don't know if this is a complete list, but a search returned this page:
[https://codegists.com/snippet/xml/wbsautofillquirksplist_saa...](https://codegists.com/snippet/xml/wbsautofillquirksplist_saagarjha_xml)

------
andy_ppp
What is the desired requirements for passwords these days then? No passwords
just a magic link or some open but difficult to hack standard (12+
characters?).

I’ve always liked the idea of using a predefined sentence structure and having
lots of choices to increase entropy, e.g. The magic butterfly flapped
faithfully. Article adjective noun verb adverb. No one does this of course.

~~~
chrismorgan
In Topicbox, we use emailed codes/magic links by default, but you can set a
password and use that if you prefer (and if you want 2FA, you must use a
password). We then use zxcvbn for password strength detection, denying weak
passwords (those where it is estimated to take less than 10⁶ attempts to
guess). I believe this is working well for us.

In FastMail, it’s much the same but without emailed codes as an option,
because it _is_ your email account that you’re trying to log in to.

I think we support almost arbitrary lengths and arbitrary Unicode in both now.
(And note that due to how the fancier password hashing algorithms like bcrypt
work, supporting beyond ~72 characters without _loss_ of entropy actually
tends to take deliberate design; and if you get it wrong, it can be a DoS
vector—Django had such a problem a few years back, where you could feed it a
1MB password and keep it occupied hashing it for ages.)

I have wondered before how secure a single astral plane Unicode code point
would be as a password. I haven’t investigated the question at all.

~~~
andy_ppp
This is excellent advice and zxcvbn [1] looks awesome.

[1] [https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

------
CGamesPlay
This probably isn't mostly about password generation rules, but rather about
how to fill the forms, e.g. what's the user name field named, etc. (Otherwise
why would it be called "AutofillQuirks" and not "PasswordRequirements"?)

~~~
defap
Overall the file does appear to contain various autofill quirks, but the
expanded dictionary in the screenshot is literally named
“PasswordGenerationRequirements”. It’s definitely about password generation
rules.

------
RGS1811
The most disturbing thing about iCloud Keychain is that you can get access to
all of your stored passwords just by unlocking a device linked to your Apple
ID. Not just the ability to log in with them, the actual plaintext.

~~~
falcolas
Urm, if you have the ability to log in with a password to a website, you
require the plain text password. Keychain also prompts for your user password
before allowing plaintext access, not just the fact you're logged in.

Not sure what else is expected in this case, you'd get the same behavior from
most other password managers.

~~~
RGS1811
Keychain doesn't prompt for your user password on iOS. Just your unlock code.
That's what bothers me.

~~~
nextstep
But iOS won’t reveal the plaintext password from the keychain to the user (it
will only autocomplete forms).

~~~
lotsofpulp
It will if you go to settings->accounts and passwords.

~~~
hrktb
you still get a password or touch if prompt before showing the passwords.

~~~
lotsofpulp
I assume RGS1811 was worried about someone using your finger for TouchID or
face for FaceID, involuntarily. I also worry about that, especially if you get
knocked out or black out or something, but I think the solution is to not have
important login info in the keychain at all, such as access to money (bank
apps), email, or other uses that can be used to verify your identity or steal
from you.

~~~
falcolas
If that is a legitimate concern, then don't use Touch ID or Face ID. By using
those a person is intentionally choosing convenience over security. By even
saving passwords in an account-shared fashion (be it Keychain, LastPass, or
1Password), you're giving up some security for convenience.

The latest iOS versions have also included a "five clicks on the power button"
emergency option, which disables both TouchID and FaceID. It's not perfect,
but if you're going into a questionable situation, it's a good way to avoid
being coerced into using those to unlock your phone.

------
scoates
apple.com: PasswordGenerationDisallowed

Hmmmm.

~~~
comex
Makes sense if you consider that the keychain is typically backed up to
iCloud, under your Apple ID. So if you generate your Apple ID password through
Safari and then lose your device, you’re going to have a chicken and egg
problem…

------
citrusui
Alternate link if Twitter is blocked behind your corp firewall, etc:
[https://archive.is/Uzssa](https://archive.is/Uzssa)

------
Bromskloss
I like Hacker News' policy of "it's up to you to be in the know and generate
your password securely".

(I mean HN doesn't impose any restrictions, as I remember it.)

~~~
chrismorgan
The HN audience is _mostly_ not _completely_ incompetent in password matters.

But by and large, people have been trained into terrible habits concerning
passwords, and they have no idea how to make a halfway decent password. I tend
to think a good baseline for most sites is to use zxcvbn and reject passwords
with score 0 (which means, guessing is expected to take less than 1,000
attempts). That way you’re not being particularly onerous, but you are at
least blocking _useless_ passwords.

Still, there’s a space in some services for allowing no password. NewsBlur
allows a zero-character password, for example, _and that’s fine_. I’d much
prefer a thing to allow no password if possible, deny useless passwords and
allow anything else (with hints about weaknesses), than have rules about
character classes and mandatory inclusions.

------
baddox
I wonder who has the best-maintained list of these password requirements for
popular websites. Probably some group that does black-hat brute forcing of
passwords.

------
tptacek
I wonder how many sites reject random A-Z, a-z, 0-9, and -.

~~~
saagarjha
In my experience, the number of websites doing this has gone down
significantly. Of the passwords I have, only around 2-3% are "specialty"
passwords generated through Keychain Access rather than Safari.

------
orf
Interesting, but there are only 48 sites in this list, which is really tiny.
Perhaps they will continue to expand it in the future.

------
barneybooroo
All this time I thought they were using an amazing heuristic to infer password
requirements from the page

------
cratermoon
Does Apple maintain this and update it when the websites change their
requirements?

------
m3kw9
I always thought curation creates value

------
maddyboo
Can someone post the .plist?

~~~
exikyut
Unfortunately, Safari itself is closed source, only WebKit is open. :(

Googling the filename of course returns no results.

I am VERY curious how 1Password were confident they'd be able to get anywhere
with getting a copy of this. I have no info suggesting they'd have a problem
with it, of course, and time will tell if it works out.

~~~
zwily
The plist is probably just stored within the Safari bundle, and 1password
could look there at runtime.

~~~
saagarjha
It doesn't even have to be done at runtime. All they need to do is extract it
from an iOS install image.

------
bjornstar
This is coming from the same company that doesn't allow you to put a space in
your AppleID password? The irony is thick.

~~~
rrdharan
I have spaces in my AppleID password. Four of them in fact.

~~~
blattimwind
A reader's exercise: Can you determine how many bits of apparent entropy in
his password rrdharan has disclosed in this post?

~~~
rocqua
If you presume rrdharan generated his password as a string of random
alphanumeric characters and round that to there being 64 of those, he revealed
$32 / n pick 4$ bits of entropy. Where $n pick 4$ is the number of
combinations of length 4 drawn from n.

That only works if you presume his password was generated as a string of
random bits though. If the password was generated as a dice-ware password [1]
with 5 characters this reveals roughly 2 bits of entropy. For we know he
doesn't use -, _ or nothing as his word-separator. Those 2 bits aren't
included in the calculation that states his diceware password has about 65
bits of entropy though. (5 words from a list of 8000) 65 bits feels like
plenty to me.

[1]
[http://world.std.com/~reinhold/diceware.html](http://world.std.com/~reinhold/diceware.html)

------
dzmien
For a clever intern, or at least one who knows a little python, it probably
wasn't that bad. Or maybe I am missing something.

~~~
pvg
How does knowing a little python help here? Most of this seems like manual
scutwork - going to each site and finding and reading the stupid password
rules.

~~~
ams6110
Possibly even testing them, because I've used sites that rejected passwords
that met all the requirements.

