Hacker News new | past | comments | ask | show | jobs | submit login
Apple releases open source 'Password Manager Resources' project for developers (9to5mac.com)
87 points by sharjeelsayed on June 5, 2020 | hide | past | favorite | 47 comments



Direct link to Github: https://github.com/apple/password-manager-resources

Seems like a good idea, instead of every password manager trying to re-implement the same kind of edge cases. One day I hope we can just "muss change" password because sites follow a common theme like https://wicg.github.io/change-password-url/index.html - but maybe we have a better strategy than passwords until then.


If Apple wants to throw their weight around on this, that would be best directed at pushing sites to stop having stupid rules IMNSHO.

Of the documented rules only minimum password length is even an excusable rule. Should your site accept 40kB passwords? No, but that's not a "maximum password length" rule at that point it's just common sense about unauthenticated payload sizes. Whereas this list includes limits of just eight characters and in one case simply 4 digits.

The other restrictions - required or prohibited characters - and the shared credential quirk (systems that let you, indeed often require you to use the same credentials but on different FQDNs) are both making users less safe. While there's an argument that just documenting them is neutral I'd argue that for an outfit with Apple's clout it isn't enough and they need to be loudly calling for reform.

That's tempered by the knowledge that Apple has never been very good at doing more than one thing. "Password stores" are definitely not the new iPhone, and so they can't pivot their whole company to this problem, and maybe in the absence of that level of focus this is all they can offer, but that's kind of a shame on its own.


> Of the documented rules only minimum password length is even an excusable rule.

Fun fact: bcrypt, still quite popular, has an inherent password length limit. Everything beyond a certain point (56 bytes) is just ignored. It's possible to work around, but that's messy and you're no longer do "the" bcrypt, bye bye interoperability. And if you don't enforce it, someone might do something silly-but-apparently-harmless, like reuse a long passphrase with some randomness at the end. Edge case, but not impossible. Of course in 2020 you probably should be using things like Argon or something (actually haven't researched the current best in a couple of years, so no longer sure)., but AFAIR Rails, for example, still comes with just bcrypt by default.


This article[0] talks about why at least one company still has maximums. I too can relate to that, at my old job we had a 30 character hard limit because of interop with Oracle systems behind the scenes (we authenticated users twice, once in the web app which could have unlimited passwords stored as PBKDF2, and then again with an Oracle system that was hard restricted). A lot of businesses have backwards compatibility or proprietary systems in the way.

[0] https://arstechnica.com/information-technology/2012/09/secre...


Unfortunately I think they'd rather you just authorize everything against your Apple ID.


That's far from the worst outcome. There are anti-trust concerns in play of course, and we certainly don't want a world where anybody without an AppleID is a second class citizen, but from the security side such systems are a win-win for users and site owners.


I feel like the GitHub link should be the submission link, not 9to5Mac which doesn't really give extra useful info...


The idea of reading a password manager reading a website's password rules (which they are calling "quirks" apparently) is a great idea as the app would then know what the controlling parameters are (15 characters, must have an upper, a lower, and three special characters) when it auto-generates a password. Since I started using KeePassXC I've been shocked at how many websites -- especially financial institutions! -- don't allow you to use 64 character long passwords using multiple "special characters" (why would you make a password rule that says I can only use five select non-number, non-letter characters and only "one to three" of said characters?)...


I cannot conceive of any situation that would make a 64 character password necessary. Even 256 bits of random data can be encoded into less than 42 printable ASCII characters.

And even that is twice as much as would ever seem necessary.


Why 64 characters? Because 128 would be too much...

Seriously though, I like obnoxiously long passwords because it clues me in to who is storing my password in a manner than can be reverted to plain text if not in plaintext directly. If you're using a salted hash to store my password it shouldn't make a difference whether my password is "HN/2020/Jun!" or the full text of War and Peace -- just the hash will be stored. Anyone who tells me my password is too long makes me nervous because they are doing something different.

And of course I'm a little paranoid: how many breach datasets are your credentials in?


> I cannot conceive of any situation that would make a 64 character password necessary

Password for a streaming service that you want to use on your smart TV/Roku/Fire TV/Apple TV/Cable box.

Ideally, they provide some way so you do not have to type your password using a crappy onscreen keyboard and the up/down/left/right/enter keys on your remote. For example, I've seen some that tell you a simple URL (https://<comany_name>/add_device, say) and show you numeric code. You go to that site on your computer, log in to your account, and then enter the code from your device. Your password manager deals with the password.

Sadly, some do not do this, and you find yourself entering your password via the remote and on screen keyboard. Every time your password has a change between {upper case letter, lower case letter, number, punctuation} you have to navigate to some kind of shift key and hit it.

I do not want to try to enter some password like "sW3/W4Bmbx=Md%" that way.

An alternative might be a password that consists of 4 groups of 16 lower case letters, with no duplicate letters within a group, with the first and third groups sorted so the letters are encountered in this order: qwertyuioplkjhgfdsazxcvbnm [1]. The second and fourth groups are sorted using the reverse of that order.

That gives you a 64 character all lower case letter password that can be entered by starting at 'q' and then scanning across the keyboard back and forth, row by row, hitting enter when you come to the characters that are part of the password. It has about the same entropy as "sW3/W4Bmbx=Md%" but might be less frustrating to type. Most of the time entering it you are only having to deal with two remote keys. The arrow for the direction of your scan on the current keyboard row and enter, with just an occasional up/down to move between rows.

(If it is a smart TV or cable box, there is a decent chance the remote includes a numeric keypad. In that case I'd consider a 27 character all digit password, if I wanted something with about the same entropy as "sW3/W4Bmbx=Md%").

[1] assuming the on screen keyboard is QWERTY. Some use alphabetical order.


Do you see a reason to forbid it?


If the customer wants to do it why should the institution care?


pass phrases, where each word is relatively low entropy, but its a lot easier for humans to memorize a long phrase than a long series of random characters


I feel like this would be better as a Well-Known URI, for example /.well-known/password-manager.json with similar format to the repo – That way it's not up to Apple to decide what goes in the repository


Sites would immediately use it to essentially disable password managers "for security." Sites have done everything they can to block password managers historically, I don't anticipate that changing.


Why would any site do that? Other than in a banks website I haven't encountered that behaviour previously


You're asking the wrong person: Sites shouldn't do that. But they do, often.

Banks are the worst offenders, but it isn't limited to that. Any site that thinks it is "special" and requires "extra security" targets password managers for reasons unknown.


I just wish Apple allowed better integration with third-party password managers.


What are your suggestions? Genuinely curious as I find the iOS integration quite excellent, it lets me pick from 1Password directly on the password prompt.


I'm probably just doing something wrong but I haven't figured out how to save a new password for something I just signed up for anywhere other than Apple's password manager.


I am going by memory here so I very well could be wrong/it may have changed but I think the process is as follows -

1. On the signup page select either the username/email or password text box

2. Press the key icon.

3. Select add in whatever password manager you use (I use Bitwarden)

4. Generate a password, etc. then hit save

5. Select it and it will autofill and add any extra stuff in the sign up form

That is how I have done it in the past (maybe not exactly like that, as I said this is from memory) and it has worked well enough. Not a great user experience though to be fair.


Thanks! I think I was missing the key actually, I usually use the little pop up asking me to save to iCloud, didn’t realise the key let you save too and to any password manager. Nice! :)


Settings > Passwords and Accounts > AutoFill Passwords

Make sure it's enabled and uncheck "iCloud Keychain" while leaving "1Password" checked. It'll basically make it your default password manager.

Most apps that I use handle this well. Some (E-trade) don't seem to have the implementation quite right.


It is miles better than the implementation on Android.


They are upgrading Keychain to be a first class password manager in iOS14. Along with WebAuthN improvements, this might negate the need for many third party password managers.


That's not an actual retort to the critique.

Apple cripples third party password managers on purpose. Pointing at Apple's worse product, a product that only works within their confined ecosystem, while claiming it is better than it was isn't a retort, it is a polite middle finger.

On that note, I recently set up a new iPhone & Watch. I had to enter my Apple Password six separate times, and 2F twice. And not once was my password manager allowed to populate it, even though it is saved in there.

Sure, I could use Keychain, but it lacks common & basic features and doesn't work on PCs, non-Apple mobile devices, or on the web. Maybe if Apple competed fairly on quality rather than abusing their anti-competitive silo(s), they'd have a better password manager.


Why do you think Apple is crippling third party password managers? If you want to use 1Password instead of iCloud Keychain then there’s support in iOS to do exactly that, and if you enable it then it will auto fill in the same way it did before. I personally find the 1password experience better on iOS than any other platform I’ve tried.


You also have to use a cellphone number for your apple id and it is always one of the fallbacks for 2fa which is just horrible considering how insecure cellphone numbers are.

Dear Apple, just let me use authy or a hardware token instead of your proprietary bullshit.


Your average Apple consumer doesn’t want a painful time when they lose or damage their hardware token and don’t have a spare, while also not backing up their recovery codes. This happens. It sucks.

Apple is a trillion dollar company because they make their users happy enough. Perfect security is not necessarily the best security posture; usability is still a concern.


So, 2fa is worthless. Hardware tokens are just a token gesture.I have 4 apple devices, which one provides me with a token is somewhat of a gamble...

If this is fine with Apple, ok. Why are they pushing apple school manager on me though? Why do I have to provide a cell number for an apple id to sync backups? Why are ASM accounts unable to install apps from the app store unless you assign them from a central app store profile? Why do ASM accounts not work for iMessage? Why do ASM accounts not work for iCloud backups?

It's not about usability, it is about locking people in.


How do I use Keychain with Firefox?


At some point you however have to wonder : Is it up to a browser to support the OS native password manager, or is it the burden of the OS maker to provide a plugin for each browser?

Beside Firefox now provide it's own password manager. But it is awkwardly limited within the browser.

Same with the recently touted picture in picture mode of Firefox. While I understand it might be enjoyable on OS that don't support that natively it's particularly laughable on OS that does it. Now You potentially have 3 layers of picture in picture implementation. The website, the browser and the OS... (And as you might guess the OS offer the best experience because it have control over all graphical layers).


Can’t yet. Valid use case, point taken. I use Safari.


I keep meaning to try different browsers and then realizing I'd have to manually migrate all of my passwords from safari. Not going to happen.


For the longest time, Firefox and Chrome could move passwords from another browser that was on the machine. Maybe give it a shot?


You can import passwords at least from chrome to safari and then they will sync through keychain. I assume importing from Firefox would work as well.

The issue is it does not stay in sync, if I use my windows machine and update a password there I would have to re-import where as a password manager (and/or its extension) would just stay synced.


I’ll say it. This is kind of a joke.

Not that it would be a joke if an individual developer released it, and built an active community who contributed, or if it was more than 100 websites long.

But the heavy publicity push seems a bit early. And, it feels like Apple’s announcement is little more than “hey guys, check out this POC repo!”.

It kinda feels like Apple doesn’t get OSS.


https://developer.apple.com/news/?id=06052020a&1591373342 doesn't seem like a "heavy publicity push". It's a niche topic and the target audience of people who build password managers isn't exactly a huge one.


1 hour ago this began appearing on plenty of Mac news sites. The PR game is a push not a pull.


Every tiny bit of information trickling out of Apple is circulating on Mac news site. Even if it's just a delivery date changing somewhere in the store. These news site are actively looking for that.

I doubt the PR department is pushing out a footnote on the developer portal to a bunch of Mac rumor blogs.


It's not even on the major Mac rumor blogs.

MacRumors and AppleInsiders both don't have the article.



The sites probably found it on Apple's Developer News RSS feed. (https://developer.apple.com/news/rss/news.rss)


> Not that it would be a joke if an individual developer released it

You're hating on it for being from Apple? That makes as much sense as loving it because it's from Apple.


No. Not hating on it because it's from Apple. Hating on it because they must have more information then they released in the repo.

Perhaps they truly don't have more information and released everything they have – and this is a "what if we were to come together".

But it doesn't feel immediately useful, and so I'm reluctant to believe that companies will bidirectionally contribute to this.


This is not even a drop in the bucket if you think this is some sort of publicity stunt. Outside of the tech bubble nobody knows any of this stuff even exists, and inside the tech bubble there's a much, much higher percentage of incel/redpill types than the general population, so it wouldn't even make sense as a way to change their perception within the tech world.

It may or may not be useful to anyone, I have no idea. But to characterize this as a "heavy publicity push" doesn't make sense. It's not a push, there's no publicity, and there's nothing heavy about it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: