Bringing passkeys to Android and Chrome

https://android-developers.googleblog.com/2022/10/bringing-passkeys-to-android-and-chrome.html

by Heavywater • 4 years ago

231 258 4 years ago

android-developers.googleblog.com

colordrops2• 4 years ago

Ugh, I hope they don't make it difficult to use third party password managers. I'm pretty happy with vault warden.

selykg8• 4 years ago

Pretty sure there's been talk on the Bitwarden community forums about them adopting support for using it as a provider. I assume once that's available you might start to see it move into Vaultwarden. But, that's sort of the risk you run with using a 3rd party to a 3rd party...

colordrops2• 4 years ago

At least with Vaultwarden, it's open source and running locally with data stored on a server in my house, so if they misbehave, I could easily fork or switch projects. If Android doesn't allow or otherwise hobbles 3rd party password managers, there isn't much recourse.

madjam0022• 4 years ago

See also https://security.googleblog.com/2022/10/SecurityofPasskeysin... which provides a more technical overview

LibertyBeta2• 4 years ago

Interesting. I'm still struggling to see how this is better than just using a yubi/solo-key

eli• 4 years ago

More people own an Android phone than a yubikey?

jrm49• 4 years ago

More convenient, but less safe for everyone in the long run.

runako• 4 years ago

Passkey will be supported, with no new user behavior, by ~a billion devices currently in use. It is better because a billion+ devices already have support for this.

selykg8• 4 years ago

I would use this in addition to those. Instead of having to buy two Yubikeys I can buy one and use a software solution as well.

Since I already use a phone capable of doing the same thing, let my phone be my main authenticator, and then I can use a Yubikey as a backup.

It's not like one is necessarily better than the other, except that you already carry a phone and they're capable of being a hardware device that works with Webauthn. No need to carry a second device or, pay for one, for that matter. Since at least with Apple's solution it'll sync over iCloud Keychain.

If you're happy with Yubikey's, nothing changes. But for the average person, this makes Webauthn an option without having to buy any hardware or carry something you are more likely to lose because you don't understand the intricate details of how the thing works. I wouldn't expect my parents to understand how a Yubikey works well enough to know it should be used as a pair, for backup purposes, but that is a barrier to entry for them that they don't need to worry about now.

LibertyBeta2• 4 years ago

That makes sense. I do worry we are starting to build key chains that are leveraged obliquely to the user.

Once passkey support comes to bitwarden I'll be a little more comfortable I think.

mpalmer• 4 years ago

This is public-key-crypto-based authentication for the average user who will almost certainly never buy a security key but who probably owns a device that offers secure identity verification (laptop, phone).

Yubikeys are great but they're super niche. Among Android users alone there might be a billion people who will never buy one.

sowbug3• 4 years ago

"To address the common case of device loss or upgrade, a key feature enabled by passkeys is that the same private key can exist on multiple devices. This happens through platform-provided synchronization and backup."

Thus, unlike a FIDO2 key, you don't have to visit every online service to tell it about the new redundant keys you add.

The rest of the security article linked by madjam002 goes into detail how Google implements their version of that backup. It's a bit like Keybase in the sense that your other devices act as keys to unlock the backup for new devices.

aseipp2• 4 years ago

At the very minimum, one undeniable technical advantage Passkeys have -- that they share with their foundation, WebAuthn -- is that Passkeys are unphishable.

potatoz23• 4 years ago

That’s not a technical advantage over Yubikeys/SoloKeys, since they also use WebAuthn and are also unphishable.

postalrat2• 4 years ago

Don't all fido2 yubikeys support webauthn? They have the advantage that they can't be cloned/sync/etc. Might be an inconvenience for some but for me that's an advantage.

jasonjayr• 4 years ago

And what happens if your Google account that these keys are tied to is locked/revoked for a nebulous ToS violation?

ezfe• 4 years ago

At least on iOS, passkeys are stored locally in Keychain, even if they're also synced over iCloud (when enabled).

zie• 4 years ago

In my experience on iOS, you can't make Passkeys work without also turning on syncing, that's sort of the entire point of Passkeys, otherwise they would just be WebAuthN tokens.

makeitdouble2• 4 years ago

I'd assume it's the same story on iOS, as you won't get access to Keychain if your Apple ID is locked ?

Provided Apple has fewer services and less surface for your account to get banned, but that's still a valid concern.

sowbug3• 4 years ago

From TFA (the security blog): "The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones."

toomuchtodo3• 4 years ago

Final step is key escrow authority that will store your private key and produce it to you if you can proof your identity with government ID. It is not enough to store in cloud storage (which Google, Apple, or someone else could deny you access to), or your own device you could lose or destroy (which is why backup hardware tokens are always recommended for U2F MFA); you need the ability (but not a requirement) to bind cryptographic identity to IRL identity.

Of course, one doesn’t need to utilize this, but you’re SOL without a recovery mechanism of last resort (unless individual sites and services have their own recovery processes to re-provision a user who no longer has access to their cryptographic credentials).

ur-whale• 4 years ago

Except for the fact that a mobile phone does not, as far as I'm concerned, fall in the "user's own device" category, as much as Google would like you to believe it does.

megous• 4 years ago

"Passkeys on users’ phones and computers are backed up and synced through the cloud to prevent lockouts in the case of device loss."

"Only on the user's device", right.

waynesonfire• 4 years ago

so what? maybe it is also pinned to your google account so regardless that it's a private key that only lives on your device, doesn't at all mean you can somehow transfer it. it could simply be one of many components that make up the effective key.

xg156• 4 years ago

"on your device" doesn't mean that you can actually access the key though. It might be stored in the secure enclave/TPM or otherwise unavailable if the phone has a locked bootloader.

insane_dreamer• 4 years ago

can you download/print backup recovery codes?

googlryas• 4 years ago

I suppose you would just do the "I forgot my passkey" flow.

jrm49• 4 years ago

Nah.

For all the talk of "one app to rule them all" (which is an awful idea) this is a step closer to that.

For all it's faults, crypto has one thing right -- not your keys, not your stuff. I get that doing keys/passwords is hard, but the best thing in the long run is for them to stay in the hands of the user.

And if not, the holder of the keys needs to be someone you can easily hold accountable, i.e. either fire, or arrest, or sue if they get it wrong.

jackson14423• 4 years ago

it is your key, it lives on your device (and is synced across devices using your cloud account if you so choose)

webmobdev7• 4 years ago

And BigTech's cloud (who will have no problem sharing it with the authorities). And when all your keys are on the device, it also becomes a lot easier for the government to access all your internet accounts by getting access to the device.

jrm49• 4 years ago

It's a nanny-ish third-party in the middle. That increases convenience, but also greatly increases your threat surface.

mindslight• 4 years ago

For all it's faults, crypto has one thing right -- not your keys, not your stuff

Erm, this isn't really an aspect of cryptocurrency, per se. It's more of a general rule that informed the initial thinking around cryptocurrency. In fact, most users of cryptocurrency seem quite content to give up cryptographic custodianship.

If you went back a similar time to the nascent web/cloud/etc, you'd find plenty of similar sentiment about remote software and storage. It's just that individual autonomy loses out over time due to convenience created by the massive investment in the surveillance economy.

jrm49• 4 years ago

That's a fair point, in that I should have said something like "crypto-fundamentalists." But the idea is the one I wanted to get across, and I have mostly those same feelings about remote software and storage (e.g. I tell students, priority one in your life -- if there's something digital you care about, e.g. photos, get at least one copy of them on something you can hold in your hand)

greatgib2• 4 years ago

Another product that they will use their dominant position to force down our throat!

selykg8• 4 years ago

This is all part of the FIDO Alliance, so, a standards based solution that anyone with the wherewithal to implement it can do so. Many password managers have already said they'll be supporting it, as well as major vendors (Google and Apple for instance).

I'm struggling to see your complaint being a valid one. This is basically webauthn, so use a Yubikey or similar device if you wish.

greatgib2• 4 years ago

Remember how gmail was just imap/smtp? etc...

stevewatson301• 4 years ago

You'll be out of luck when trying to switch from one ecosystem to another (for example, from Apple to Google).

dane-pgp2• 4 years ago

When you say "the FIDO Alliance", you mean the entity that runs a Metadata Service[0] which:

provides organizations deploying FIDO Authentication with a centralized and trusted source of information about FIDO authenticators.

The aim of this centralized system is to allow revocation of hardware that doesn't meet their unchallengeable opinion of whether you've spent enough money on your device or not. They can similarly require that devices do biometric scanning[1], and be issued by your government, and require you to agree to lengthy (and self-updating) terms of use.

There are actually (at least) two different types of device attestation that FIDO support[2]. One uses a hardcoded on-device private key, that's common between 100,000 devices of the same model, which means that an attacker can brick 99,999 other people's devices just by extracting the key from their own device. The other method requires a certificate from a "trusted third-party Attestation CA", which presumably allows a malicious (perhaps government-mandated) CA to spy on (and filter) every login request you make.

This system is like a dystopian parody of the traditional model of web security, which had no need for "authenticators that have a Trusted Platform Module (TPM) onboard", and which only required CAs to be on a list that the user agent is in control of (and users can add their own CAs to). Instead, what FIDO are building is basically DRM for human identity, with all the corruption and failure modes that entails.

[0] https://fidoalliance.org/metadata/

[1] https://fidoalliance.org/specs/biometric/requirements/

[2] https://research.kudelskisecurity.com/2020/02/12/fido2-deep-...

okhuman• 4 years ago

Check out AuthCompanion, a passwordless login implementation for ideas. https://github.com/authcompanion/authcompanion2

aseipp2• 4 years ago

Also along these lines, there's a really neat little library called "SimpleWebAuthn" that also supports Passkeys, and is basically a small dependency-free set of client Javascript (for initiating the user flow) and a small JavaScript server component to go with it: https://simplewebauthn.dev/

The code is pretty simple and a good place to start, as well as AuthCompation, if you wanted to roll your own library in your language of choice or whatever, or something very custom. I found both useful recently.

wnevets4• 4 years ago

Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.

redandblack• 4 years ago

yeah. will be switching to this for all google apps, with firefox for general use

api2• 4 years ago

The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison.

What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is even considering or talking about.

The implications are pretty profound: large companies having the power to lock you out of everything on a whim (even your own systems and unaffiliated third party services), levy taxes on the use of everything (e.g. Google starts charging you or sites to log in with Google), surveil literally everything (including logging into everything you have as you and sucking down data), and if a big identity provider gets seriously hacked it'll be an epic security apocalypse. Imagine someone stealing the master keys for a provider and pushing ransomware to millions of companies at once.

... and don't forget the obvious: "Oops I got locked out of Google and now I'm locked out of 50 SaaS services, my company's bank, my VPN, and my remote servers."

It just totally blows me away that these systems have no privacy protection at all, no portability provision for me to select or change my provider built into the protocol, no built-in support for third factor auth that I can control (e.g. FIDO2), no built in provision for recovery codes, and so on. These kinds of things didn't even seem like they were considered in the design of things like OpenID/OIDC. It's just a big "oh hey lets give god level access with no recourse to third parties and implement it so there's total lock-in... what could go wrong?"

Edit: yes some well-implemented systems offer their own built-in support for some of those things (recovery codes, changing your auth provider, reverting to password, etc.) but in my experience it's a minority and there is obviously nothing in the standard to encourage it or provide any guidance on how to do those things securely.

r00fus2• 4 years ago

Compare this with status quo for users like my parents. They constantly forget their passwords and quail at screwing up the 2nd factor all the time.

If they could just use their fingerprint/faceID to login (after initial registration on the device) they would be super happy.

Rest of us should be happy there will be less exploits where people give up the keys to their kingdom by clicking on a random email.

dickhardt4• 4 years ago

I founded Hellō to address your concerns. Check out the Show HN post I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

stavros15• 4 years ago

Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself.

Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?

webmobdev7• 4 years ago

This is also going to be a body blow for our privacy - if BigTech have access to your keys, so will the government and both can abuse it. The idea is to force you to "save password on device" (whether you want to or not) so that when a government authority gets your device they can also easily access all your internet accounts. US courts have already affirmed that it is legal for the police to force you to unlock your device if it is biometric protected (fingerprint or face scan etc.). Moreover, by forcing you to use your personal device for identity verification, BigTech is ensuring that identifying you and datamining your personal data becomes more easy for them. Don't be surprised if this is also extended in the future as a "super cookie" service to allow easy tracking.

yupper32• 4 years ago

Why would this be different than any other password manager in that aspect?

goalieca2• 4 years ago

There will be services from 1password, yubikey, etc. This is actually great news!

mooreds• 4 years ago

My understanding of passkeys is that they are using WebAuthn under the hood (hence the nod to the w3c/FIDO at the end, and the fact that the passkey in the screenshot was associated with tribank.us).

They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse.

It's a blessing because it eliminates a whole trove of phishing attacks. After all, if no one can get the private key, they can't steal or share it. Well, of course they could steal the actual device, but that's orders of magnitude harder than stealing online credentials (points to https://haveibeenpwned.com/ ). That's a good thing.

It's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times. For each domain/website (broadly speaking). If they only set it up once and lose the device, well, they are either locked out or need to have another means of account recovery (username/password, calling a customer service rep).

This curse is what passkeys managed by Apple/Google are attempting to solve.

I believe the WebAuthn 3 draft is going to try to address some of this: https://www.w3.org/TR/webauthn-3/ but that's based on what a co-worker said. A quick scan didn't turn up anything.

If you want to know more about WebAuthn, I wrote a lot more here (my company is going to release an implementation Real Soon Now): https://fusionauth.io/learn/expert-advice/authentication/web...

wnevets4• 4 years ago

They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created.

To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these randomly generated keys synced across multiple devices is to use the "cloud".

If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".

josteink4• 4 years ago

it's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times.

Or just get some Yubikeys.

skybrian3• 4 years ago

Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords?

Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).

If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.

jjnoakes• 4 years ago

I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager).

With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).

throwaway415973• 4 years ago

The lock-in is very real and relevant.

Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.

IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.

fotta• 4 years ago

Google's auth is getting increasingly frustrating. Recently when I logged in with TOTP 2FA, I had to also open up YouTube on another device and click approve. What's the point of 2FA if they're just going to ignore it?

htrp• 4 years ago

Welcome to user hostile revenue maximization algorithms

account-52• 4 years ago

I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager.

At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help" with this so you're locked into their services and they are better able to track your activity.

alyandon• 4 years ago

Exactly. I will never trust Google to control access to my logins knowing that the Sword of Damocles (the Google "AI" deciding I'm a bad person) is hanging over my head.

If Google did an about face and started providing reasonable escalation mechanisms for when they lock you out of your account based on a faulty decision of their algorithm I'd consider it.

forty• 4 years ago

You might be able to do "passkey" with your password manager https://www.theverge.com/2022/8/31/23329373/dashlane-passkey... (I work for this specific one, but I'm sure others have similar things in the work)

smileybarry• 4 years ago

AgileBits have passkeys in the works for 1Password:

https://blog.1password.com/1password-is-joining-the-fido-all...

Spivak• 4 years ago

I mean that’s gonna be my adoption path. Once I can store passkeys in Bitwarden I’ll switch to them everywhere.

KronisLV2• 4 years ago

I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager.

More or less the same, except that I haven't found good TOTP solutions for the desktop, to the tune of KeePass (something that can run on Windows/*nix instead of making me use something like FreeOTP, Google Authenticator or other Android/iOS apps; or in addition to the mobile apps).

That said, even with multiple Google accounts for different things (e.g. personal e-mails, file storage, cloud services etc.) it feels like eventually you might want something like Qubes OS, another way to run multiple separate VMs, or just use separate devices for separate use cases.

Much like how some orgs have separate laptops for accessing prod environments, that are more tightly controlled, even though that's not convenient enough for most people.

Ciantic• 4 years ago

Depending on your setup you could just generate TOTPs on command line and copy to clipboard, that's what I've implemented: https://github.com/Ciantic/totper

It works pretty well with pass (password manager) that stores each individual entry in GPG encrypted file. GPG is pain, but if you happen to use it already then it works.

saulrh2• 4 years ago

Bitwarden will do TOTP, and its CLI tool is quite usable. If you want it fully local, just stand up a docker of their server software (which is open source) or the open source reimplementation (vaultwarden).

SAI_Peregrinus• 4 years ago

KeePassXC supports TOTP. Right-click a key, TOTP→Set Up TOTP... and put in the secret key (and settings if needed).

pabs38• 4 years ago

I do TOTP on desktop Linux with Firefox, browserpass and pass.

https://github.com/browserpass https://www.passwordstore.org/

40four• 4 years ago

I’m with you, I de-Googled all my services a few years ago, and I couldn’t be happier with the decision.

I’m curious though, what’s preventing you from using a password manager on your phone? I use KeePass, and I’m able to use my password DB on any device I want.

account-52• 4 years ago

Nothing really other than it's a device I can loose to easily or it could be stolen. I don't do banking on my phone either. Plus there's the hassle of syncing it too.

kelnos• 4 years ago

How do you handle syncing? I use KeePassXC on my desktop, and I back up the encrypted password DB to SpiderOak, but I haven't figured out a good way to get that DB onto my phone, auto-synced.

Also are you worried about the security of the DB on your phone? My password DB's passphrase is a good 50+ characters long, which I can type quickly on my laptop, but I can't imagine pecking that out on a phone. And I feel like I would not want the DB unencrypted/unlocked all the time on my phone; given the possibility of my losing it or it getting stolen, I'd want it to re-lock immediately after each use.

yalogin• 4 years ago

Why can't the password manager kill your account? I am not advocating for google, just asking about the other solution you are relying on.

erklik• 4 years ago

I don't think the point is that they can't. Just far more unlikely to, and there's usually more recourse. Google is mega-corp who never listens to their users, and are un-contactable. Some AI can and probably will ban some people for no real reason and even Google won't know why it happened.

Danidada• 4 years ago

you can always use a password manager like the KeePass family which is file based. sync it across devices with nextcloud/syncthing instead of gdrive/Dropbox/one if you are extra paranoid

pabs38• 4 years ago

You could use virtual-fido to store the keys on your computer, potentially in your password manager. Theres a link in my other comment about it.

cglong• 4 years ago

People are raising really good points here, but I do find it interesting how negatively this news is being received vs. when Apple said the same thing: https://news.ycombinator.com/item?id=31643917

Someone1234• 4 years ago

The second most popular top level comment chain is:

Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.

Which is the same sentiment as this thread. The first comment was just talking about the open standard of Apple's implementation and weakness of 2FA loss/recovery.

https://news.ycombinator.com/item?id=31644190

throw10920• 4 years ago

Yup - GP made the mistake of treating HN as a single person with a coherent opinion. It's not, and it's extremely tiring and intellectually uninteresting to repeatedly see people doing that.

notyourday2• 4 years ago

I do not trust one company anymore.

Especially when that company is Google.

Ferret7446• 4 years ago

I find that sentiment ironic because I won't use it unless it can't be backed up (the main selling point of 2FA and hardware keys).

If it can be backed up, then a casual bystander/process can also "back up", filch all of your credentials in a few moments with you being none the wiser.

The protocol is open, so I can use one proprietary key from company A, one from company B, and a few open source keys. Keep one for regular use and the rest as backups.

quadrifoliate3• 4 years ago

It's not particularly surprising. Apple has a much better reputation at customer service than Google does – they have actual stores you can walk into.

Now I'm not sure whether they can help you unlock your Apple ID if you prove to them that you're the owner of the account, but I can at least visualize Apple having the scale to do that.

Google on the other hand has a horrendous reputation for locking out people out of their accounts totally and permanently. Of course everyone has concerns about handing all your account login responsibilities to a company with such terrible customer service.

TheNewsIsHere• 4 years ago

At the risk of being pedantic, no. Apple Stores aren’t able or empowered to provide Apple ID support beyond what the public website based recovery workflows provide. I am sure someone will note that someone at an Apple Store has helped them reset an Apple ID password. What I mean is that Apple Store employees have neither procedure nor access to override Apple’s account system. You have to call support for assistance beyond what the website can do. I am sure Apple Store employees have been helpful and I’m sure policies have changed over time.

As an Apple user I find this as frustrating as it is wise. Mostly for future-me who may one day not be as savvy and manage to screw myself.

I don’t fully trust iCloud Keychain and Apple to never lose my data in a “I don’t concern myself with backups” manner. So I opt for using Passkeys where I can also add my FIDO2 tokens.

politelemon3• 4 years ago

but I can at least visualize Apple having the scale to do that.
Google on the other hand has a horrendous reputation for

Neither are true nor false but definitely exaggerations. All you're doing is displaying personal biases by providing them with benefit-of-the-doubts. They too have a reputation for locking people out, and are well known for turning data over, but one that HN in gernal prefers to ignore.

linsomniac3• 4 years ago

Apple, on the other hand, has terrible problems with working with others that google does not.

Apple will happily tell you that if you want grandma to have a whatever color text bubble, you should buy her an iPhone, to name a recent example, rather than adopt the standard everyone else is using. I bought a Macbook last holiday season and couldn't even set it up until my wife set up her iPhone on my account to activate the laptop. I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone (they have a "kids" feature where a parent can activate it but it basically has no smarts at that point AFAIK).

So, for making an authentication standard, I'd trust Google over Apple.

pGuitar• 4 years ago

Apple isn't any better then Google... they are just better at hiding it.

ok_dad• 4 years ago

Try telling the authorities you "forgot" your password when they know you use passkeys.

potatoz23• 4 years ago

It’s not that difficult: you use a PIN/passphrase protected hardware token. Done.

thrillgore• 4 years ago

Coming never to Firefox, Edge, and iOS.

madjam0022• 4 years ago

It’s been supported on iOS since iOS 16

stavros15• 4 years ago

Firefox has supported WebAuthn for years.

pabs38• 4 years ago

It doesn't support passkeys though. They are software-only WebAuthn, while Firefox only supports USB device WebAuthn.

postalrat2• 4 years ago

There is so much ignorance and misinformation around webauthn. I don't understand why people aren't jumping on it.

Passwords suck. Password managers make passwords more manageable but they still suck. Why not move on?

genpfault• 4 years ago

Passkeys on users’ phones and computers are backed up and synced through the cloud to prevent lockouts in the case of device loss.

How do you back them up locally?

randyrand• 4 years ago

It seems to be the only question they are unwilling to answer.

Keys for me, but not for thee!

sneak2• 4 years ago

You probably can't use them at all unless you use iCloud Keychain.

politelemon3• 4 years ago

A passkey on a phone can also be used to sign in on a nearby device. For example, an Android user can now sign in to a passkey-enabled website using Safari on a Mac. Similarly, passkey support in Chrome means that a Chrome user, for example on Windows, can do the same using a passkey stored on their iOS device.
Since passkeys are built on industry standards, this works across different platforms and browsers - including Windows, macOS and iOS, and ChromeOS, with a uniform user experience.

I see no mention of Linux in these examples, which tells me that users having access to their keys is not a primary concern for these implementations?

oezi7• 4 years ago

It seems the client side is baked into browsers rather than being something which leverages a local implementation for key storage.

jeroenhd• 4 years ago

Can we have this but self-hostable and open source, please? Something like Bitwarden that you can stuff onto your own device? I know there are hosted services for handling auth on the server backend, but what about the other way around?

I use Krypton but that's not maintained (and already broken on some websites like Github). I trust the secure storage module of my phone and I trust my computer's TPM, unlike many other Linux users; surely it should be possible to integrate with the OS somehow to make it secure, right? The last example I saw used USB over IP to inject a virtual FIDO device, which works great, but the implementation is clearly not ready for prime time.

stavros15• 4 years ago

Yes, you can. It's an open standard. Bitwarden can (and probably will) just support it.

oezi7• 4 years ago

I don't see how that would work without integration into browsers.

mimi899993• 4 years ago

Do you know if it's possible to see a list of stored passkeys in Android? I installed the Play Service beta, managed to create a passkey and sign in, but can't see the list of credentials anywhere in the UI.

arnarbi• 4 years ago

There will be, in the password manager settings on Android (under Settings, "Passwords & Accounts" and "Google"), but it will unfortunately take a couple of more days to roll that out to the beta.

stavros15• 4 years ago

How/where did you create the Passkey? I don't see a UI for it anywhere.

xg156• 4 years ago

Dumb question: what keeps me from spoofing the fingerprint[1] and obtaining all the passcodes at once?

[1] https://phys.org/news/2005-12-biometric-expert-easy-spoof-fi...

chocolatkey• 4 years ago

Note you can't just get the keys even if you have a fingerprint. You would need to maintain continuous access to the device while it is still signed in as the user. It would be pretty easy to the "find my device", if the user didn't already notice you were handling it

acdha5• 4 years ago

First, note that the article you linked is pretty old — the people who build biometric systems have added countermeasures in the last couple decades. They're definitely not perfect but it's not an especially easy attack since it's personalized and doesn't scale.

The first thing to remember is that your fingerprints / face scan are not the identifier for your passkey. They are used by the local device to unlock its secret store but the actual keys are regular crypto keys and the remote website never sees any of them. The interface also does not provide access to the private keys ever, and it should be rate-limited so it's not “get all of the keys” but the much slower “use the phone I stole to hammer out requests to different websites, mashing that sensor every second or two”. That means that whoever stole your phone & forged your biometrics is in a race with you revoking their access, but when you do it won't matter that they have your biometrics unless they can also steal your new phone (stop pissing off the Mossad).

The other thing to consider is what your threat model is. If you're worried about someone stealing your phone and building a realistic model of your fingerprint or scan of your facial structure, you have to ask what the alternatives are. For example, it'd be a LOT easier for an attacker to use a hidden camera or drone to record you entering your password — not using biometrics means you're typing it frequently, for example — and you're also at risk for all of the scenarios which passkeys are immune to (credential reuse, phishing, weak passwords), which happen to be by far the most common way people are compromised. Very few of us have to worry about targeted attacks by skilled adversaries, and if you are worried about that you probably need to move or hire a bodyguard more than anything involving infosec.

xg156• 4 years ago

The interface also does not provide access to the private keys ever

There are both statements all over this thread, "the private key is inextricably bound to the device" and "the private key can be backed up". This seems to be an attempt to declare both the problem with theft and the problem with lost devices as solved. Except, they are mutually exclusive: If the key is bound to the device, I can't back it up. If I can back the key up, it can't be bound to the device and can be stolen.

There is one way to get both, which I assume Google is offering here: Have the key inaccessible to the user of the device, but allow some cloud provider access, so it can be automatically backed up to the cloud.

That's all fine and good, but now you're dependent on the cloud provider not playing games with you. And you still have to authenticate to the cloud provider in some way, e.g. to add a new device. (And have to do that in a way that someone who stole your phone couldn't just do the same)

The other thing to consider is what your threat model is. If you're worried about someone stealing your phone and building a realistic model of your fingerprint or scan of your facial structure, you have to ask what the alternatives are. For example, it'd be a LOT easier for an attacker to use a hidden camera or drone to record you entering your password

You can also view this from a different angle: Phones get lost all the time, sometimes stolen. It's statistically not that unlikely that your phone will get lost at some point and the people who find it may not always have the best intentions.

If a phone is in the wrong hands, it's much easier to gain access to the phone using fingerprints than it is using passwords: There is a good chance some usable fingerprints from you are still on the device cover itself. Sure, an attacker would need some resources to take the fingerprints and build something that can be used with the phone's sensor, but if enough people use fingerprints for auth, attackers will streamline this step quickly.

That's bad enough if it grants "only" access to the phone itself, but now it would also grant the attacker access to each and every online account.

Sure, you could race to deactivate keys - if you remembered to setup alternative login methods before, because otherwise it's you now who cannot login anymore.

dickhardt4• 4 years ago

Q: how many of you will add support to Passkeys to your application? Is it worth the effort of adding yet-another-way-to-login for your users? It will be a long time before you could use it as the ONLY way to login. You will need to figure out how to enable your existing users to convert to Passkeys. Apple has a glide path for converting username password -> but not for other mechanisms.

I believe we in letting the user choose whatever way is best for them to login -- and to take that burden off of the developer. If you want to learn more, check out the Show HN post on Hellō I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

fleddr2• 4 years ago

I'm noticing very little discussion about the user aspect, and I say that with non-savvy users in mind. I run a mid-sized web app/community where I've been supporting such users for a long time.

Right now, I offer a classic login, and a few social providers. You'd think this is straightforward to support, but about 70% of support requests consists of the endless ways in which users can mess this up.

"Can't get in"

Try recover password. Email didn't come. Because they entered the wrong email. Correct email this time. No wait, think I signed up with a social account, not sure which one, have many. Login worked. Wait now it doesn't again (saved browser password did not update).

This is just the tip of the iceberg. This new solution, whatever merit it has, is going to be additive. It won't replace anything, it's yet another way to log in, if at all, as it depends on websites implementing it and about 90% of the web is basically not maintained.

So it's only adding complexity/confusion specifically to these users, which I consider to be the vast majority. In turn leading to more support headaches.

acdha5• 4 years ago

The flip side is that it’s incredibly easy to use, faster, and means you don’t have to worry about forgotten passwords or phishing. It’s like an order of magnitude faster than less secure MFA options, too.

fleddr2• 4 years ago

Well, no, it isn't. Clearly you don't do old people tech support.

Passkey? What's that? New word thus meaning unclear.

Doesn't seem to ask for an actual pass-anything, so more confusion.

No email identifier or thing to remember. How can I know log on at my other device?

With a QR code? What on earth is that?

stavros15• 4 years ago

The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard, so I want to clarify things.

WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issue, because it's unphishable and can be unstealable if it's in hardware.

If you don't like Google or Apple, use your favorite password manager. All it will have to keep is a private key per website, and you're done. No usernames or passwords. You visit a site and are automatically logged in with a browser prompt.

This is amazing, it's the best thing that's ever happened to authentication. It's something the end user cannot have stolen. Can we be a bit more excited about it?

EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.

That means that django-webauthin also works great with Passkeys, for you Django users:

https://pypi.org/project/django-webauthin/

Also, the latest Firefox on Android seems to work great.

Mindless21123• 4 years ago

If you don't like Google or Apple, use your favorite password manager.

Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.

andrewxdiamond• 4 years ago

They can do this with SSO provided by third parties now.

martin_k• 4 years ago

Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.

Android's implementation of passkeys currently does not support attestation. https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/nh...

Neither does Apple's, I believe.

minimaxir• 4 years ago

I recently got hardware TOTP keys and I wanted to use them with my financial accounts but all the banks have their own propritary authenticators :(

oezi7• 4 years ago

Isn't it even worse? Browser vendors don't even offer any way to not use their baked-in authenticator? With WebAuthn they offered at least the options of using a security key via Bluetooth/NFC/Bluetooth as alternatives to the device authenticator. I don't see that option with passkeys.

So, there seems no way to use a password manager with passkeys.

quadrifoliate3• 4 years ago

The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard.

There is a certain fiddling-while-Rome-burns quality to this comment. The blog post is not about the open standard, it explicitly focuses on a specific company's products. People are naturally worried about this even though the standard may be open, because we are at historically high levels of platform lock-in from megacorps. Gmail is the new "Blue E". Getting locked out of your Google account in 2022 is probably much worse than not being able to use a different browser in 2001.

Sure, HTTP is also an "open standard". How many real browsers exist that can play DRM-encumbered media? You'll find that the answer is "very few – basically anything made by Apple, Google, or Mozilla" (perhaps Brave as well, which has an ex-Mozilla founder and uses Google-funded tech).

The best way to get people to adopt the open standard is to actually showcase uses of it that are not just a single company's product, not call them names for being worried about lock-in.

stavros15• 4 years ago

Right, but that's like Gmail coming out and people complaining about another proprietary product locking people in. There are two issues with the current comments:

1. Absolutely nobody currently uses WebAuthn. I'm extremely excited about the popularization, which, unfortunately, requires big players to get behind it.

2. The comments feel very "oh my God this car I'm driving is heading towards the edge of the cliff even faster". Don't use Google, they're unreliable and evil. While I'm very excited about Passkeys popularizing WebAuthn, I don't think anyone should ever rely on Google for authentication, so just don't use them and use Bitwarden instead, if/when it supports Passkeys.

A vendor coming up with an implementation of a great standard isn't the problem, the fact that people use it is the problem.

rzimmerman• 4 years ago

I'm also surprised at how negative the reaction here is to Google embracing an open standard. Both Android and iOS devices keep your passwords/keys encrypted end-to-end between your devices. You can absolutely share passkeys between devices (if you want to) and even make them exportable to another secrets manager (if you want to).

If you ask me what's one thing in 2030 people will look back on and say "I can't believe we did that!" I'd have to say "passwords". Passwords need to die and WebAuthn is a great step forward.

xg156• 4 years ago

There's no lock-in, because the key is portable (unless you don't want it to be).
There's no security issue, because it's unphishable and can be unstealable if it's in hardware.

You mean, you can (in theory) choose whether you'd rather have a lock-in or a security issue. Both options are mutually exclusive, you can't have them both at the same time.

stavros15• 4 years ago

No, I don't. You don't have to use Google's thing, use an open source password manager that syncs via Dropbox or whatever. Same thing, different vendor.

oezi7• 4 years ago

EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.

It does not work with Chrome on Android.

stavros15• 4 years ago

Ah, thanks, I'll look into it.

mimi899993• 4 years ago

Yes, WebAuthn is an open standard, but it seems that Passkeys can only be synced using Google password manager and I don't see any API that would allow the user to use a different password manager as is the case with the auto fill API.

stavros15• 4 years ago

Ah, that's interesting. So if I use Apple keys to log in to sites, I can never log in to them with my Android phone? That's unfortunate, though I don't see this being sustainable for too long, I imagine (and hope) they'll open it up to alternate authenticators soon.

webmobdev7• 4 years ago

There's no privacy issue

There is a real privacy issue if online services will now force you to store your "passwords" on a device - whether it be in your phone or a password manager.

PassageNick2• 4 years ago

The passkeys are stored in a Trusted Platform Module, and as far as I know, it is basically impregnable, even with access to the physical device.

novok• 4 years ago

As long as you don't need master key escrow to essentially be with the vendor (ex google / apple), you can have the master key backed up elsewhere so you can pass the mud puddle test [0], and the vendor has no way to access the master key, I'm ok.

But push google / apple about solving mud puddle problems and it's curiously missing from their wallet implementations and they stutter around it when they give talks about FIDO2 and such and people ask them. It's the lock in direction they see everyone going towards that makes people uncomfortable.

[0] https://blog.cryptographyengineering.com/2012/04/05/icloud-w...

sneak2• 4 years ago

Pretty soon you won't be able to log in to any major website with javascript disabled.

rektide• 4 years ago

It's be a damned good time for someone to start building a competing Google Sync impl & server & passkey implementation into Chromium.

For a while this was largely built around XMPP but now the stock Google implementation is custom.

I'd love a refresher crash course on what's in Chrome that's not in Chromium. It's been a long time since I used Chromium but I think when I did it seemed to have a as-best-I-could-tell working Google Sync implementation.

It's hard to imagine a scarier project to fork. I dont think there's a lot of resources out there for DIY'iny a Chromium fork.

pabs38• 4 years ago

For those of you who want something like this with Firefox on Linux, the virtual-fido project might provide a decent alternative, it uses Linux's USB-over-IP support to provide a fake FIDO device, and Firefox supports FIDO devices for WebAuthn:

https://github.com/bulwarkid/virtual-fido/ https://news.ycombinator.com/item?id=32881956

pabs38• 4 years ago

I wish WebAuthn would have a standardised HTTP header or TLS extension so it would be usable without JavaScript, currently every website has to implement their own login protocol in JavaScript.

https://github.com/w3c/webauthn/issues/1255 https://github.com/w3c/webauthn/issues/1616

pabs38• 4 years ago

Here is the technical side of how passkeys work:

https://www.imperialviolet.org/2022/09/22/passkeys.html https://news.ycombinator.com/item?id=32946750

oezi7• 4 years ago

...a (good) tutorial for website developers

pabs38• 4 years ago

Yes, but it has a lot of info on how they work.

Bringing passkeys to Android and Chrome

Related Stories