Apple Launches Open Source Project to Let Password Management Apps Create Strong Passwords (macrumors.com) 38
Apple today informed developers that it has launched a new open source project that's designed to let those who develop password management apps create strong passwords compatible with popular websites. From a report: The new Password Manager Resources open source project allows password management apps to integrate website-specific requirements used by the iCloud Keychain password manager to generate strong, unique passwords. "Many password managers generate strong, unique passwords for people, so that they aren't tempted to create their own passwords by hand, which leads to easily guessed and reused passwords. Every time a password manager generates a password that isn't actually compatible with a website, a person not only has a bad experience, but a reason to be tempted to create their own password. Compiling password rule quirks helps fewer people run into issues like these while also documenting that a service's password policy is too restrictive for people using password managers, which may incentivize the services to change," the company said.
Just stop using passwords already. (Score:3)
The problem isn't the complex set of rules. The problem is that passwords are the wrong tool for the job. If Apple wants to help, it should try to find ways to make it easier for websites to adopt OpenID, not make it easier for them to continue the status quo.
Re: (Score:1)
Passwords are okay, they just need to be combined with 2FA. I actually like having different passwords for each site rather than using OpenID or similar because centralised identity verification means a single point of failure.
Apple do seem to have this arse about face though. Instead of adapting the passwords to match what the site can cope with they should just mandate that sites accept good passwords.
Re: (Score:2)
And yet, such strategies don't work.
Forcing webmasters to fix their password policy just so you can use your password manager of choice? It's just as likely they'll push back and say "We don't support Mac. Use Windows." or other nonsense.
And some of the worst offenders would be intranet servers at corporations, where due to legacy all sorts of crap happens, and the chance corporat
Re: (Score:2)
Supporting iPhone is pretty much mandatory, it's a big chunk of the mobile market.
They could make it optional but display a warning along the lines of "this web site may not support strong passwords", like how many browsers warn when accessing unencrypted HTTP sites now. No breakage but a strong incentive to suck less.
Re: (Score:2)
Re: (Score:2)
If the change was to force a better-quality password, I can see that. People often don't change passwords for ages, especially if trying to to re-use them. A little warning and explanation would be nice, though, not just "your password is no longer good here" - hopefully they allowed you to change it.
Re: Just stop using passwords already. (Score:2)
Re: (Score:2)
Lots of websites have adopted OpenID, or something close to it. They just make you use Facebook, Google, Twitter, LinkedIn, etc.
I don't want to use any of the privacy abusing services, and I sure don't want to be forced to manage what information RandomDotCom.com requests from these accounts.
Re: (Score:2)
And, of course, Google, MS, etc will ask for your password THERE, plus a 2FA code if that's enabled (and why isn't if if it's not?). One way or another, you still need a password, and I'd rather not have Google for instance tracking my secure logons all over the web.
Keepass and other PW managers can generate passwords that follow all sorts of rules. Why not use one of those, now?
Re: (Score:2)
No thanks, I don't want a third-party knowing where I bank, where I post family pictures, and where I tell people on the Internet that they're wrong. OpenID is a fine system, and it's a massive improvement over the status quo for a great many people, but some of us want more control over our privacy than it provides.
Towards that end, I want a non-intermediated, unique relationship between myself and each organization with which I do business, which means having an account with them that isn't tied to anythi
Re: (Score:2)
No thanks, I don't want a third-party knowing where I bank, where I post family pictures, and where I tell people on the Internet that they're wrong. OpenID is a fine system, and it's a massive improvement over the status quo for a great many people, but some of us want more control over our privacy than it provides.
Towards that end, I want a non-intermediated, unique relationship between myself and each organization with which I do business, which means having an account with them that isn't tied to anything or anyone else.
And that's fine. OpenID shouldn't be the only option. Users should have the choice of having individual accounts or using a shared identity, on a per-site basis.
BUT — and here's the big but — for 99% of websites, that account sign-in process should still not use passwords. A much better scheme would involve the browser generating a unique PK key pair and sending the public key to the server. The server would then sign a nonce with that key, and the browser would display that nonce. Then,
Re: (Score:2)
Great. And the way to achieve this self-sovereign identity is to require that web service signups will not ask for an email address.
Every email is transmitted in plaintext across five-eyes jurisdictions and multiple ISPs and contain the exact information you are describing.
Re: Just stop using passwords already. (Score:2)
Re: (Score:2)
Agreed in principle, though the way client certificates are done in HTTPS right now is pretty much broken beyond repair, IIRC, and would need to be completely rethought.
Re: (Score:2)
There is no OpenID, just other people's passwords.
Re: (Score:2)
Security is a balance between ease of use and defense. A key lock is easy to use but easy to break. Passwords are often insecure because secure passwords are hard to use. Passwords managers allow us to use more secure passwords, but have drawbacks. In apples case it is that you tend to lose data between devices
A joke? (Score:2)
Is Apple doing this for humorous purposes? Apple is the same company that wont allow chrome and firefox to use the OS keychain/safari password store. Why don't they allow that first?
Re: (Score:1)
Not sure what you're talking about, because on my Mac Keychain Access is used by Safari, Chrome and Firefox.
Re: (Score:1)
No, Chrome and Firefox are not using Keychain.
Re: (Score:2)
Then why are my website passwords, for websites I only use in Chrome, stored in Keychain?
Re: (Score:1)
Can't believe I have to tell a slashdotter this
https://bugs.chromium.org/p/ch... [chromium.org]
It's five years since Chrome stopped supporting Keychain.
Re: A joke? (Score:2)
They can use the keychain all they want. What they cannot do is access credentials placed there by other apps or the OS.
Idiots (Score:2)
How about no mmmkay? I don't want my passwords in the cloud even if they are generated by open source.
Re: (Score:3)
Idiots indeed. Someone sees "cloud" and starts frothing at the mouth while writing an angry clueless rant. Your passwords don't get stored in the cloud and this has zero to do with storing passwords in the cloud, something you'd know if you read the summary and actually understood it as well.
Or offer free 2FA services (Score:1)
Re: Or offer free 2FA services (Score:2)
They do. Itâ(TM)s called âoelogin with Appleâ. It uses biometrics on your iOS device.
Uh, we need this? (Score:2)
And you can't use apg because...?
Re: (Score:2)
That would be answered if you had a clue about what this is doing, but for that I guess you'd need to read the summary.
we'd be better off (Score:1)
with 2FA everywhere that requires username and a 6 digit PIN
failing that, long plain alphabetic "pass phrases" are superior to passwords of limited length no matter how complex you make them and of course the problem with a long complex password is no one can remember the dozens required for modern life
Re: (Score:2)
Why do people still get this wrong? (Score:2)
The age old established rule that a password must be at least x characters and no more than y characters is nuts. Allow the user to put in as short of a password, or as long of a password with any variety of character (heck even emoji should be allowed). Then transform this to something that is hashable, hash it and store the hash. When the user re-enters, re-hash what they give you and compare it to the stored hash.
Now if
Re: (Score:2)
Stop with this whole complexity thing and "trying to protect the user" garbage!
The age old established rule that a password must be at least x characters and no more than y characters is nuts. Allow the user to put in as short of a password, or as long of a password with any variety of character (heck even emoji should be allowed). Then transform this to something that is hashable, hash it and store the hash. When the user re-enters, re-hash what they give you and compare it to the stored hash.
Now if the user wants a password to be "12345" or "password", that is on them not you. But for the love of god stop making me put in at least 1 upper case, 1 lower case, 1 number, 1 symbol (but only from a limited set of symbols), more than 12 characters, but no more than 16 characters. This isn't security, this is just repeating the same mistakes over and over again.
I for one tend to use phrases for passwords, long 32+ character phrases. When I can't enter these because some site has deemed a max of 16 characters or some stupid enforcement that I can't use words, or some symbol; then I have to write the thing down somewhere because of an artificial limit you have placed on your software!
This.
https://xkcd.com/936/ [xkcd.com]
https://xkcd.com/792/ [xkcd.com]
Re: (Score:2)
Re: (Score:2)
This. And the worst is that it could even be more secure. Just implement state of the art attack detection to limit the number of tries and report to the user his account is under attack, but do not lock it !. 2FA is fine as well, on top of it.
All these stupid rules came from math on local attacks (i.e. I have the hash and want to brute force it). But those attacks are a lost cause now. If you want to truly defend against those, you would require extra-long, truly random passwords. So, password managers or
Re: (Score:1)
This. And the worst is that it could even be more secure. Just implement state of the art attack detection to limit the number of tries and report to the user his account is under attack, but do not lock it !. 2FA is fine as well, on top of it.
Sort of the right idea. Instead monitor from where the login request is coming from (ip address/host), then limit the attempts from this host to no more than say 7 attempts in 7 minutes. That gives a legit user 7 chances to login (usually after the couple of attempts they realize they incremented the only digit in their password by 1 last time). More than 7 attempts and the user has no idea or isn't the right user. Also if they don't wait the 7 minutes it resets the lock out period again.
Now the plus
Re: (Score:2)
limit the attempts from this host to no more than say 7 attempts in 7 minutes
And that's the completely wrong approach. If I have a password that can be guessed then I don't have a password. If I can't remember whether I added an 11 or a 12 at the end after I was forced 11 or 12 times to change my password, that's just nonsense. Safari (which we are talking about here) generates passwords with about 70 bits of entropy. That's uncrackable if your site doesn't store passwords.
Re: (Score:1)
Safari (which we are talking about here) generates passwords with about 70 bits of entropy.
This is exactly the problem, your using some password manager to store your passwords which is way less safe the knowing your password. If your device is compromised, lost, or dies, there goes all your passwords. Backing these up to some cloud storage is also a bad idea as that to will be eventually cracked or leaked. Storage tools no matter how well built will be cracked. That is the first rule of security, all encryption will be broken at some point. On top of that a random generated password does y