[throwaway2056]

> Buy a second Yubikey

I can (as a geek) but this is a problem for average Joe or a single mum with 2 kids.

This is the reason even banks or <your employer> incl. Federal places uses Cisco DUO not an opensource solution.

Most things are for average customer. passkeys are great

- Assuming a person keeps one password (either Apple or Google OK)

- Phishing for them is reduced

- No need to squeeze brain for was it username or email address (for login field)

- Most phones have fingerprint (even < $60 in developing world too with Android)

- Passkeys work from Android 9 onwards

- At the end some one needs to compromise.

[danShumway]

- And they can't move ecosystems.

- And logging into your bank requires a proprietary device.

Let's be clear about what we're "compromising" about. If passkeys are going to be a replacement for passwords (and Google/Microsoft/Apple are very up-front about the fact that they want passkeys to be a replacement for passwords) they have to handle all of the use cases. But even if that wasn't the case and they could just target the general consumer, the downsides here are not just for techy people. The platform lock-in will absolutely affect ordinary people as well.

It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.

[throwaway2056]

> ecosystems

A majority don't. A majority use their phones/banks rather than analysing ecosystems.

> It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.

That is acceptable solution. Buy and then move on with life. Everything will be back after your shell out $$ (android).

But with local will the family member send the hard disk or USB disk containing keys to recovery? Which recovery company? Will they be honest?

Whereas if you want to new phone - all works then easy.

People want simplicity. Really thats it.

(Again it may be sad for those that don't want to carry phone but the world is designed for average user).

BTW, why do you thing banks are using proprietary device.

Ask the HN -er to

- make it possible using U2F or TOTP keys (QR code)

- the same HN-user likes to implement flashy APP - so that they

- track, help whatever

[danShumway]

> A majority don't. A majority use their phones/banks rather than analysing ecosystems.

Is this intended to be an argument for my point or against it?

The majority of people don't think about platform lock-in until it bites them, and money is tight and they can't afford to get an iPhone and then they sigh and buy one anyway because it's too annoying to switch.

> That is acceptable solution. Buy and then move on with life.

Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "Yes, passkeys are vendor lock-in and I don't care" is maybe not as strong of an argument as you think it is? People like to be able to choose which phone they're going to buy.

----

> But with local will the family member send the hard disk or USB disk containing keys to recovery

No. They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone. They won't need to wonder if their new phone is compatible with anything, they won't need to wonder about whether their computer will work or not. It'll just work, immediately, as soon as their password app is installed.

Literally every single restoration/syncing option that's available for passkeys is also available for password databases, just as simple if not simpler. But you get an addition of a number of other simple solutions like:

- if you lose your phone and show up to a friend's house, you can type a password into a web browser and get all of your passwords back instantly.

- if you buy a windows computer and you have all of your passwords on an iPhone, you type a password into a web browser or an app and get all of your passwords back instantly.

None of that is supported with passkey.

Vendor lock-in does not make people's lives easier, it makes things more complicated. Do people really think that passkey is easier to back up than Bitwarden is?

[throwaway2056]

I understand your argument from a philosphical or idealistic view. You are correct

People know Google/FAANG rather than bitwarden.

If your family knows bitwarden then kudos. I am living in a different world.

> Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "

- We can talk about it

- And we are now.

- But people in power don't understand (or care).

There are no equivalent, easy option. I wish some company like proton mail or some one else would run a phone with all equivalent google services. But they don't.

> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.

Are you sure? People would ideally like

- Buy phone

- sign in google/apple account

- All apps installed and ready to consume/produce MEDIA

> Do people really think that passkey is easier to back up than Bitwarden is?

People think in different way. They know 2 things

- Google/Apple username + password

- get SMS recovery info (again I am not recommending - people are simplistic). May be you can replace this with some other option

- For example, facebook allows for nominating a friend or a facebook for recovery

- Enter the code

- ready to consume/produce MEDIA

> They won't need to wonder if their new phone is compatible with anything,

Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.

> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.

Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?

I agree to your no-vendor lockin sentiment but this means some one should invest and build a platform neutral + verifiable thing.

And even if some decent govt steps in people will claim it is all to track you. So EOF.

[danShumway]

> There are no equivalent, easy option

Of course there is, the equivalent easy option is passkeys without vendor lock-in. Vendor lock-in does not make any of this easier or simpler.

Also note that current platform-offered password managers already allow syncing to new devices, so even for the people who are saying "I only want to use my Google account", syncing passwords through their Google account to Android is just as easy as using passkeys would be.

> Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.

This is just not true. I see people switch ecosystems all the time, and when they refuse to switch ecosystems, the reason they usually give is "it would be too annoying to port everything." Lock-in is something that affects ordinary people, I see this all the time.

> Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?

Weren't you just arguing for simplicity? The average user doesn't use 2FA. They should, but they don't because it's too complicated for them.

----

But this is silly, we've graduated from "people need a simple solution" to "any solution that involves anything other than a Google or iCloud account doesn't count as simple."

Which, sure, if your definition of simple is literally "the passwords stay in your Google account" then only putting keys in a Google account will do. But it's a pretty tautological definition.

And also a definition that doesn't hold up for ordinary users in my experience. People do actually understand that there are passwords for services other than Google and Microsoft because they interact with those systems today just fine. Pretty provably they can handle that level of complexity because that level of complexity is embedded in every single service that we use today.

But let's assume you're right. Even under that criteria, even if your definition of simplicity is "I sign in with an Apple/Google password and that's it, and it has to be specifically an Apple/Google password -- I want to re-emphasize that current password vaults with Google/Apple already handle this use case fine today just as simply as passkeys do, so there's still no extra simplicity or ease-of-use with passkey synchronization. At best, for those users it's as easy to sync a passkey as it would be to use a password manager. But password sync to new phones on log-in is already supported natively if you use the native built-in password managers (ie, the same password managers you'd be using for passkey).

Even under the most restrictive criteria with the least possible number of steps for syncing -- password vaults can be synced just as easily if not easier than passkeys can be.

[dv_dt]

If they buy another iPhone, how do they authenticate to the cloud account? A password that hasn’t been used in months or years? Standard credit collection agency data (which is stealable and has been stolen for many people already?)

[danShumway]

Yes, correct. Apple documents its restore process here:

- https://support.apple.com/en-us/HT210217

- https://support.apple.com/en-us/HT204974

They also have account recovery processes which use metadata about you to try and verify your identity.

Note, this is the system they are using today for passkeys. So this is not some kind of compromise or complexity with password vaults that passkeys eliminate, it's just the universal process of account recovery that we have today with all of its flaws, and passkeys don't add any additional protections or simplicity on top of this system.

[signal11]

> At the end some one needs to compromise

Sure. Google and Meta and similar companies can compromise by having proper redressal processes which will hold up in court, should they lock your account.

Being an identity provider who can take away your identity with no legal recourse is not legally tenable and will be challenged legally.

If you’re an engineer working on this, expect to get beat up by the EU on this, to start with. There is a solution though — build import & export into the spec and actually implement it well.

Google actually has done a decent job with Google Takeout. It’s worth learning from.

[rkeene2]

The US Federal Government got rid of passwords in 2004. They use smart cards issued by approved issuers. They are certificate-based, so if you lose your card another one can be issued to you with the same properties on the certificate. Additionally, they usually escrow the Email Certificate private key.

I maintain some open source middleware for these cards [0].

[0] https://cackey.rkeene.org/

[sidewndr46]

Having worked with the Federal government you are woefully misinformed. There likely is a policy statement announcing that passwords are being phased out, but I can assure they were alive and well past 2004.

[rkeene2]

There was a Presidential Directive signed by George W. Bush in August of 2004 [0] that resulted in follow-up actions by every department of the executive branch of the US Government, the creation of the physical infrastructure, annual reports on compliance.

As someone who has worked with the DOD OCIO on this, I am likely significantly more informed than you and the assertion to the contrary is unfounded and likely incorrect.

https://www.dhs.gov/homeland-security-presidential-directive...

[sidewndr46]

The word 'password' does not even appear in the document you linked.

[rkeene2]

... do you think that's the only way it applies ? Did you read it ?

It says that no other method of authentication to US Government (exempting specifically national security systems) except for the approved method may be used. Since there are no passwords in the list of strong authenticators, it's not permitted.

Here are the relevant sections pieced together so you can't miss it:

Note "Mandatory"

> establishing a mandatory, Government-wide standard for secure and > reliable forms of identification issued by the Federal Government > to its employees and contractors (including contractor employees)

Note that the definition of the phrase used above excludes passwords:

> "Secure and reliable forms of identification" for purposes of this > directive means identification that (a) ...; (b) is strongly resistant > to identity fraud, tampering, counterfeiting, and terrorist exploitation;

This is the part that says they have 8 months after the August publication of HSPD-12 to comply with the above, and specifically for US Government computers (called Information Systems).

> As promptly as possible, but in no case later than 8 months after the > date of promulgation of the Standard, the heads of executive departments > and agencies shall, to the maximum extent practicable, require the use > of identification by Federal employees and contractors that meets the Standard > in gaining [...] logical access to Federally controlled information systems. > Departments and agencies shall implement this directive in a manner > consistent with ongoing Government-wide activities, policies and > guidance issued by OMB, which shall ensure compliance.

So, upon... actually reading HSPD-12 there's no interpretation that can be made where passwords are permitted to access unclassified systems... aka, my original statement.

You are wrong.