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:
> 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.
> 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.
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.
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.
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.
> 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.
> 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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."
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.
> 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.
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...
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.
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?
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.
> 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?
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:
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.
"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.
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.
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.
At the very minimum, one undeniable technical advantage Passkeys have -- that they share with their foundation, WebAuthn -- is that Passkeys are unphishable.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
stavros|3 years ago
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.
quadrifoliate|3 years ago
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.
Mindless2112|3 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.
rzimmerman|3 years ago
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.
mimi89999|3 years ago
novok|3 years ago
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...
xg15|3 years ago
> 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.
oezi|3 years ago
It does not work with Chrome on Android.
webmobdev|3 years ago
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.
cglong|3 years ago
Someone1234|3 years ago
> 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
quadrifoliate|3 years ago
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.
pGuitar|3 years ago
wnevets|3 years ago
mooreds|3 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. 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...
skybrian|3 years ago
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.
api|3 years ago
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.
unknown|3 years ago
[deleted]
webmobdev|3 years ago
redandblack|3 years ago
account-5|3 years ago
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.
forty|3 years ago
alyandon|3 years ago
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.
KronisLV|3 years ago
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.
40four|3 years ago
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.
yalogin|3 years ago
pabs3|3 years ago
jasonjayr|3 years ago
ezfe|3 years ago
sowbug|3 years ago
googlryas|3 years ago
insane_dreamer|3 years ago
jrm4|3 years ago
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.
mindslight|3 years ago
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.
jackson1442|3 years ago
madjam002|3 years ago
colordrops|3 years ago
selykg|3 years ago
jeroenhd|3 years ago
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.
stavros|3 years ago
fotta|3 years ago
htrp|3 years ago
genpfault|3 years ago
How do you back them up locally?
randyrand|3 years ago
Keys for me, but not for thee!
sneak|3 years ago
okhuman|3 years ago
aseipp|3 years ago
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.
politelemon|3 years ago
> 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?
oezi|3 years ago
pabs3|3 years ago
https://github.com/bulwarkid/virtual-fido/ https://news.ycombinator.com/item?id=32881956
LibertyBeta|3 years ago
selykg|3 years ago
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.
sowbug|3 years ago
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.
runako|3 years ago
mpalmer|3 years ago
Yubikeys are great but they're super niche. Among Android users alone there might be a billion people who will never buy one.
aseipp|3 years ago
eli|3 years ago
jrm4|3 years ago
ok_dad|3 years ago
potatoz2|3 years ago
fleddr|3 years ago
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.
acdha|3 years ago
dickhardt|3 years ago
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
rektide|3 years ago
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.
pabs3|3 years ago
https://github.com/w3c/webauthn/issues/1255 https://github.com/w3c/webauthn/issues/1616
pabs3|3 years ago
https://www.imperialviolet.org/2022/09/22/passkeys.html https://news.ycombinator.com/item?id=32946750
oezi|3 years ago
xg15|3 years ago
[1] https://phys.org/news/2005-12-biometric-expert-easy-spoof-fi...
acdha|3 years ago
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.
chocolatkey|3 years ago
mimi89999|3 years ago
arnarbi|3 years ago
stavros|3 years ago
sneak|3 years ago
greatgib|3 years ago
selykg|3 years ago
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.
thrillgore|3 years ago
stavros|3 years ago
madjam002|3 years ago
postalrat|3 years ago
Passwords suck. Password managers make passwords more manageable but they still suck. Why not move on?