Google will now make passkeys the default for personal accounts
arstechnica.com
Passkey is some sort of specific unique key to a device allowing to use a pin on a device instead of the password. But which won't work on another device.
Now I don't know if that key can be stolen or not, or if it's really more secure or not, as people have really unsecure pins.
Man, the amount of fearmongering and anti-Google rhetoric in this thread makes me sad. Passkeys are almost entirely a good thing and are supported by many big and small companies.
No, it won’t lock you into Google, it’s an open web standard. Google will have an Authenticator, Apple will, and third parties will spring up to support it as well. And there’s no lock in, you can get a new passkey when you want to switch devices or providers.
No, someone who gets access to your device can’t get access to everything if you have basic security hygeine. Secure your passkeys with a secondary password or use biometric authentication.
Yes, it’s almost a straight upgrade to text passwords. They are immune to phishing attacks and other social engineering tricks, and you don’t need to remember long strings of numbers and letters anymore.
Do your research people, sheesh.
This is starting to really get on my nerves, and I feel like discourse on the fediverse is worse; basically the attitude is that if it's not FOSS and self-hosted, it's shite. That attitude is fucking grating for the rest of us.
The irony is that it's an open standard. There are FOSS implementations you can self-host. Server side, client side, soft token, hard token. Everything.
https://github.com/herrjemand/awesome-webauthn
People on this thread are just really ignorant, even self-proclaimed security experts.
This and if any business anywhere manages to reache a significant level of success — and has the nerve to charge money for their service — it’s a sign that capitalism doesn’t work and corporations are inherently evil.
I just assume it’s an age thing.
Big tech have done this to themselves
The problem with passkeys is that surrender of a physical key is not protected by the 4th amendment and subject to seizure. From a security perspective, I agree that passkeys are good. But I only use a physical key as a secondary factor. Never a primary.
The courts have ruled that you can't be forced to give up a password or passcode. (We'll have to see if the current court will keep this precedent.)
Until we get better privacy protections, I'm not trusting passkeys whole cloth.
You can protect your passkeys with a knowledge element.
But I don't see your use case. Passkeys are about logging in to webservices, not about protecting devices.
Web service providers can always be ordered to surrender your data by a court. Very few of them even try to encrypt your data. And for those that do, a court order could still force them to intercept your password and decrypt the data.
If you replace passwords with passkeys that must be protected by a password, you haven’t replaced passwords, you’ve just moved where the attack can happen. While I think there’s certainly value in that, it’s very disingenuous to say you’ve replaced passwords.
Passkeys are used for more than web services and have the possibility to replace other security options elsewhere (being something you have, one of the three secrets possible). Their lack of protection, at least in the United States, is a very serious problem. Your points do nothing to address this and highlight just how bad the situation is.
You should really read up on multi-factor authentication and Web-Authn.
Your problem seems more that you don't trust Google to store your private keys in their cloud.
And that's fine. You don't have to do that. But don't be confused to think that's the only option. You can buy a yubikey or a Trezor model T if you prefer.
Passkeys are just a marketing term for Web-Authn. When you use asymmetric keys for other purposes, it's not passkeys.
I missed the part where I said I don’t trust Google. You seemed to have ignored everything of substance in my response, namely putting a password on the passkey doesn’t remove passwords and the extension of things like FIDO2 beyond web auth.
I didn't ignore it, I said you need to read up on the basics.
Protecting a private key with a password is totally different than authenticating with a password and you don't see to understand that difference.
It doesn’t get rid of passwords, which is what I said when I said it was a disingenuous claim. It just moves the attack surface, like I said before. You haven’t bothered to demonstrate even a passable understanding of my original comment and the security issues I raised as a security professional because you appear to want to dunk on me. I’ve been having this conversation for years so sorry not interested.
That suggestion up thread to read up on how webauthn/CTAP2/FIDO2 works?
It’s a good suggestion. I would take it.
I don’t think you know what an attack surface is.
I do. What part in particular worries you?
Sorry, you're just wrong. It does get rid of passwords as the authentication mechanism and replaces it with a private key.
Claiming otherwise is being ignorant on how it works.
Even if someone knows the password to your phone or yubikey, they still need your phone or yubikey. Knowing just the password is useless. If you are a security professional, you would know this is called a possession factor.
If you've been having this conversation for years, you really ought to know better.
I don’t think you understand what an attack surface is.
Lol. I guess you learned a word from the CEH you flunked.
Edit: but yes, passkeys greatly reduce the attack surface compared to a password.
And when using a properly hardened device like a yubikey, you can actually minimize your attack surface to as low as it's ever going to be in a web context.
There is no implementation right now that enables you to own and manage your own passkey backups without Google it icloud.
Additionally, the attestation feature is one step away from banks and other sites mandating specific implementations, preventing people from using software tokens or OSS managers.
Passkeys is great, and I am eager to recommend it to everyone, but without those items addressed, it's a trap door, and one bitflip away from very strong lock in.
I just set my passkey up in Dashlane. It does not require Google or iCloud.
The same webauthn standard allows you to use a security key with PIN luck
My understanding is that, currently, a PIN or password is protected. So if you secure your phone with one of those, access to it is under 4th amendment protection. Given this, I'm curious how passkey legality would work out since it's a physical key, but access to use it would still require a knowledge element.
Passkeys will not protect you against the government.
As I said elsewhere, it's for web services. The web service provider will have to surrender your data on a court order. They can decouple it from the passkey. The passkey doesn't encrypt your data at the provider, it's only used for authentication.
If you really want to protect your data, you will need to use a different encryption solution. Something like full disk encryption with a complex pass phrase.
Google is a lot of things for a lot of reasons. This isn’t one of them. There’s plenty of reasons to bash them without needing to pull shit out of one’s ass
While I would agree this sounds more secure, I'm always worried about people getting further locked in to Google's products.
Hopefully this system won't take accounts "hostage" by requiring you use Chrome to log in to them, but it's Google, so...
EDIT: I'm wrong, passkeys are stored per-device and can be shared between devices using an open standard. Here's a video explaining the basics. It addresses my concern at around the 2:50 mark.
Passkey is an open standard. It's not Google specific.
That's good to hear. I don't know much about passkeys, and I should really spend some time learning about them. Didn't mean to fear-monger, but I guess I'm getting more cynical these days.
Updated my root comment to reflect this.
it's passkeys. they are getting integrated in a lot of stuff right now, including password managers like bitwarden
Use a yubikey, that doesn’t vendor-lock you to an OS ecosystem. They make one with nfc so it’s not a pain to use with your phone.
I'm not sure if this is universal or specific to the last site I tried to use my Yubikey with as a passkey, but it only would allow it to be used as 2FA, not actual passwordless authentication.
I assume this is because Yubikeys don't create a secret for each individual website I suppose? Not exactly sure about that one.
The site likely didn’t support passkeys. But passkeys are basically webauthn passwordless login, and per the yubikey docs they support that.
See https://www.yubico.com/authentication-standards/fido2/ and https://fidoalliance.org/passkeys/#faq for more info. See also https://support.apple.com/guide/iphone/use-passkeys-to-sign-in-to-apps-and-websites-iphf538ea8d0/ios specifically the bit about adding a passkey to a physical key.
Google definitely supports passkeys, and they were one of the sites that did this. I've just replied to another comment regarding this. I wonder if the Yubikey 4 (I'm not sure how to tell which one I have, since they look about the same) just doesn't support passkeys, which would be... unfortunate.
It'll be even more unfortunate if there's a weird mix of sites that support the Yubikey as a passkey and some only support it as a passkey. My Pixel is supported as a passkey, but Firefox on Linux doesn't support this - only on Windows and macOS. I believe Chrome/Chromium does, which is equally as frustrating as my Yubikey possibly not supporting passkeys.
Per Yubico’s specs on the Yubikey 4, it does not support FIDO 2 resident credentials, meaning it does not support Passkeys.
Compare to the specs of the Yubikey 5C NFC or Yubico Security Key C NFC, which both have this section:
See also Yubico blog post with an FAQ about passkeys:
I wouldn’t run out right now and buy a Yubikey to store Passkeys given the 25 key limit and the likelihood that Yubico releases a new key that supports storing far more of them, but if you do, the $25 Security Key series is the cheapest option.
Interesting, I'll probably just have to wait till either Bitwarden supports Passkeys, or wait till Firefox on Linux supports cross-device Passkeys (so, my phone for example) as yeah a 25 key limit is not likely to be worth purchasing an upgrade for just yet.
The credential needs to be set as discoverable and some other stuff to work for passwordless login (the token must store site specific data)
You would need to reregister it as passwordless to not just use it as 2FA after having entered a password (meanwhile standard 2FA with webauthn don't store anything on the token, the website sends encrypted credentials to the token which only the token can decrypt and then authenticate with)
Both the website and your physical security token must support the right type of webauthn credentials (the token has storage for a certain number of slots with "discoverable credentials").
Passkeys is a variant of the same which is bound to your device's own TPM / SE security chip or equivalent, plus a synchronization feature for backups.
You can use Yubico keys as your passwordless logins. Both Google and Microsoft have this option.
Strangely enough, Google lets me "add" my Yubikey as a passkey, but then does not let me sign in with it due to it not being "recognized". If I remove it as a passkey, and only use it as a 2FA token, attempt to sign in and use the "Enter your password" option, it will then let me use the key after I've entered my password as a second factor.
So it seems Google has removed the error (or its not triggering anymore) as they will have been one of the first sites I tried to create a passkey for, but it still does not let you use it as a passkey.
I haven't encountered this issue, yet. I'm using LibreWolf browser (v118.0) and tested logging in my Google and MS account passwordless. BTW, I have Yubico Security Key NFC (the blue one).
Mot likely it won't need to have chrome. However maybe Google services may be required.
However it is also very likely, if a device cannot support such feature, it will only require a password and 2fa.
Nope. Not going to have my entire digital everything depend on me not losing or breaking a single electronic device.
From Ricky Mondello, who works on passkeys at Apple: “If it’s device-bound, it’s not a passkey”:
https://hachyderm.io/@rmondello/111188643228872151
That's a terrible take ... He's confusing "what it does and how it works" with "how you manage it".
It's like saying "don't call it a password if you write it down". It's confusing and unhelpful.
No it's literally in the spec. Passkeys are designed for cross device synchronization. You have to go out of your way to make it local only (or use a different webauthn spec like physical security keys)
They're just private keys. By nature you can copy them wherever you want. I guess I don't know why he's making that distinction at all.
The original spec is resident keys including TPM protected or hardware token protected keys designed to be impossible to copy. That's why there's a distinction.
You won't need to?
The key is for a single device. Logging in on another one is going to generate another key.
They key is secured with the pin of the device, so when you try to log in, you can use the pin to log in, and not the password.
https://youtu.be/6lBixL_qpro?si=wFFQwrfjQBKDHs5B
Would you have to set up multiple devices when making your account then, if you wanted more than just your phone?
Yes. Unless there was a way to share that key between devices. I know Bitwarden is working on a vault for keys but it's not released yet. It was due out now so I assume it's delayed.
Apple is quite dogmatic in that their implementation demands cross device syncing.
It's definitely possible to have such an implementation and those will be the most common. You take a very small security risk for a huge convenience factor.
For the more paranoid, device-bound passkeys do not sync. If you lose the device, you will need to go through a recovery procedure.
Thanks for posting this video. Very good explanation for those unfamiliar with the technology.
Do you not use MFA at all then?
Authy on the phone while also using their desktop app. If you lose the phone you still have options.
Each to their own but cloud syncing and MFA are a bad mix in my eyes. It has a "who watches the watchmen" problem and it somewhat defeats the point of having a trusted factor when you have an untrusted one on "someone else's computer".
Authy have demonstrated why this is a problem (https://techcrunch.com/2022/08/26/twilio-breach-authy/), plus they're closed source, so it's a big no from me.
Vaultwarden, a FOSS Bitwarden server compatible with upstream clients, is able to store TOTP, and when self hosted, you are the watchmen.
Yeah, this is fine. It's closed source, opaque cloud solutions that people should be wary of.
I have the KeepassXC database with the TOTP thoroughly backed up, so nope.
So you are using MFA but for the password manager? (Appreciate that you're not the OP I was asking)
If your MFA is bound to a single device and you have no backup then you're doing it wrong.
You can accuse companies of doing it wrong by often only providing a single additional factor, but I don't see what that has to do with me.
What I'm hearing is that when an authenticator app is the only option, you'll go with nothing over something.
Perfection is the enemy of good after all.
Looks like I replied to the wrong comment.
The person you had replied to originally commented on not wanting to have the possibility of everything being broken by losing a single device. I think that's important that everyone realize that some sort of a backup plan is needed, whether that be back up codes, saving the original QR code, or being able to use multiple devices to authenticate.
At any rate, I should have replied to someone else. Sorry for any confusion.
No harm, no foul.
And you're very much right. There's a growing problem in consumer perceptions of modern security methods and how they should be applied. Much more time is spent justifying the convenience of proposed solutions, and not nearly enough time spent understanding what the scope is of the attack vectors that lead to these things needing to exist in the first place.
And further, why some of these conveniences - much like the reused-everywhere super-long password of yesteryear - are a danger in themselves.
It's definitely more secure, since stealing someone's phone is much more difficult to scale up compared to stealing passwords.
I don't think that access to your personal data/email/files being dependent on a battery-powered electronic device is a great idea, to be honest.
That's why they invented chargers, eh.
But more seriously, there are recovery procedures if you lose a phone with or without a backup and if you are willing to share the keys with a cloud provider, you can also store them there and use them on any of your devices.
Or you can get something like a yubikey if the battery aspect is really that problematic for you.
The fact is that I fail to see something obviously wrong with outrageously long/complicated passwords managed by e.g. Bitwarden or the likes.
Long passwords can still be phished. Passkeys cannot. It's a huge upgrade.
I don't think so, but whatever.
What do you mean? Do you not believe the anti-phishing features will work as described for a reason?
Bitwarden is also supporting passkeys, so it won't make a difference for their users whether they use passwords or passkeys.
And the fact that you don't see anything wrong is more a you problem. Boomer mentality, dude. Don't became one.
It would probably be better for you to explain what's wrong and not just call them a boomer as if that explains it.
If they want to be a Boomer and stick to 20th century solutions, why should I care?
If it works for them, fine. Nothing wrong with that.
It's obviously not working for most people. Most people reuse weak passwords and get their passwords hacked. Passkeys solve that for those users.
That's why the whole industry is shifting to passkeys.
"It's old so it's bad" is not a very convincing argument.
I think he was wondering how technically the new solution is better, especially compared to password database solutions where complex password and password reuse isn't an issue.
Webauthn has domain bindings and single use challenges which prevents MITM credential stealing, etc
I said the exact opposite. If the old thing works for you, go ahead and stay on it, but don't complain about the rest of the world improving and moving forward.
Why put quotes when you are misquoting...
And I answered him, he just doesn't want to know. I can't solve that.
You're mentioning how it's an old solution as if that was some sort of argument. If you're not using it as an argument then it seems kinda pointless to bring it up.
I'm not sure if you even realize you're doing it but you're doing it again, implying that it's better because it's newer. That's not a very solid argument.
I know you've mentioned some aspects but I'm still wondering, in your opinion, what would be the technical reason that the password database model with long and complicated passwords would be worse than the passkey setup. Or is it that they're as good but passkey might be a lot simpler to some folk?
Sorry, your arguing against some strawman here.
Keep using passwords if that's your preferred solution.
Not my beef if you can't see how MFA is stronger than something that can be copy-pasted in a MITM attack.
Would be a lot easier to see it if you tried to actually explain your position tbh
It kinda sounds like you dont actually know whats wrong, and are just blindly following the trends.
Doesnt that make you the boomer?
Sure. I am become the Boomer lol.
oh man. so I am a boomer. good to know.
What do you see that's wrong with it that we don't if I may ask?
Mostly phishing. Passkeys can’t be phished. And really, passwords are awful in general for security purposes. You don’t have to use your phone or google or apple or whatever.
I actually have a physical usb key that I use as a passkey. Its just a more secure login implementation and will likely be the only option in the future.
Passkeys can be phished, it’s just much more difficult than with passwords, TOTP MFA, SMS MFA, other OTPs, or push notification-based MFA (e.g., Duo or the way Microsoft, Apple, and Google push a notification to their app and you confirm and/or enter the key).
Passkey is extremely phishing resistant in the same as Webauthn MFA and U2F MFA are, in that origin checks by the browser prevent attackers from initiating the auth process. But it can still be attacked in these ways:
From memory, passkeys, webauthn, and u2f should prevent over 99% of phishing attacks that are successful without them in place.
There’s also the risk of the passkey itself being compromised, though that level of risk is dependent on your device / how you’re storing your passkeys and isn’t a “phishing” risk.
The main point is all those attacks need to attack the local software or hardware implementation on one of the two ends (or a cert issuer), and even then it's replay protected so for example an XSS attack lasts only for one session, so it's more robust.
Correct, but that doesn’t change the fact that “Passkeys can’t be phished” is not true.
My understanding of Apple Keychain is that every credential is useable from every device, and can be backed up and restored to a new device. Most importantly Apple doesn’t have access, although we have to trust them on that
It's not quite unique to a specific device. You can store your private key in a password manager or something similar, and then access it from other devices
Depends on your personal choice. You can definitely limit them to a single, hardeneddevice if you want the highest level of security.
For most users and most situations, a synced solution will be preferable.
Me, at the bank:
Robbers, as they enter the bank: everybody freeze
Me: ah shit
Robbers: everyone give me your phones
Me: aw hell naw
mission impossible style shootout
But it becomes much easier if you want to compromise a specific target individual
No, not really.
Even if you want to target a specific user, it doesn't become necessarily easier.
Unless you happen to target an individual that combines good password OpSec with shitty phone OpSec.
But I would expect those to be a minority.
Hi, yes, I am that minority
I have a 37 character password with both cases, numbers and special characters to login to my pw vault using long random strings
My phone has a swipe pattern lock since that is the safest lock option it allows in the first place. I wish I could lock it better, but the only other options available to me are a 4 character pin, and fingerprints/facial scan. I hope the problems with those are obvious
Couple that with the fact that I have a daily predictable commute in public transit where I have a habit to put my phone next to me during breakfast and you have a recipe for disaster.
Finger prints on Android stop working after 24 hours, a reboot, and some other cercumstances. I feel pretty OK using fingerprint to unlock my phone, because in about 99% of cases I might be compelled to unlock my phone, I will either be able to restart it first, or that 24 hour timer will have expired.
I may be misunderstanding you, but how does that stop an attacker?
Getting a copy of someone's fingerprint can be done without their knowledge since it is the easiest biometric to accidentally leave behind. Having to restart my phone doesn't suddenly change my fingerprints.
Or, do you have to actually re-register your prints on a daily basis via a different form of authentication? That'd seem inconvenient and like it would just move the problem around
US legal system can compel you to give biometrics, but not password/pin
They won't be able to compel you before the biometric access timer expires.
Tell that to cops at traffic stops
Yes it's a thing
Then you have a nice juicy lawsuit. No legal protection is going to prevent a rogue cop from getting your data. https://xkcd.com/538/
Good luck in court
https://www.computerworld.com/article/2743684/mich--state-police-confiscate-cell-data-at-traffic-stops--won-t-say-when-or-why.html
https://www.vice.com/en/article/aekqkj/us-state-police-have-spent-millions-on-israeli-phone-cracking-tech-cellebrite
They even brag about it
https://cellebrite.com/en/kansas-investigators-use-advanced-analytics-to-speed-their-work-and-reduce-violent-crime/
https://m.slashdot.org/story/418156
Make sure your devices are up to date
You link to articles about law enforcement hacking phones to get data as a reason not to use biometrics? If they are hacking your device it doesn't matter if you use a password or a fingerprint.
After the phone restarts, you must unlock your phone with your PIN(or swipe pattern) before you can use your finger again. The same is true with the 24 hour timer. Android also has a feature that if you hit the power button a set amount of times, it requires the PIN/Pattern too. So if my phone and my finger print have been separate for more than 24 hours, my fingerprint is useless. If I have any warning at all, my fingerprint is useless. Also, after a set number of failed biometric attempts it requires PIN as well. Which means the law better get the finger print right in only a few tries or they lose their chance.
Yes, it is technically possible that law enforcement may steal my phone, duplicate my finger print(in a way that works on my phone's finger print reader), and use that to unlock my phone while they have a chance, then suck everything out of my phone. But for anything government, that's moving pretty swift for anything they might want to book me for.
I'm guessing you could reduce that to a lower number of hours if you really felt the need.
You have to enter your pin/pattern to re-enable biometrics
Also, I'm not sure which phone you're using, but if it's an Android there should be the option for password, some OEMs don't give that option but they're rare and the standard set by Google is to provide that and also the pins to be very long (I haven't personally checked the limit, but you can make them longer than reasonable)
You can still use a 37 character password to protect your passkeys in your pw vault, so it's not like anyone is forcing you to change.
It's still a single factor though. The number of times I have had to lecture IT admins that their 64 character passwords was compromised by a keylogger and that they need to move towards MFA is too damn high.
As for your phone, if that's sufficient for you, go for it.
There are better phones out there.
Even FIDO2 MFA doesn’t protect you from attacks that involve malware running on your machine. If there was a keylogger on their machine then that machine is likely compromised in other ways, and any credentials entered or stored on it should be considered compromised and should be reset.
I have MFA in addition to that pw, yes
That's news to me. Which other mobile authentication is there besides pin, pattern, facial and fingerprint?
My 6 character alphanumeric pin is more secure than your four digit numeric
Most phones allow passwords, or at least longer length pin.
Someone else correct me if I’m wrong but it works similar to PGP.
Background info:
Usage:
Closing:
So, it’s supposed to be more secure because every time you login, you never type in a password that gets transferred to the server for verification. The server is sending your device data to verify so that it can then verify you. This mainly prevents phishing and the reuse of passwords but I suppose if someone hacks into your iCloud account or whatever, they have the keys to the kingdom 🤷♂️
As you point out, the single point of failure is access to the passkey repository. Of course, this will usually be 2FA, so much more secure than simple passwords which people usually employ.
One major issue, IMHO, is vendor lock-in. I’ve no doubt Apple is going to make migration away from iCloud a huge pain in the ass. It’s just another way they’re going to make it difficult to leave their ecosystem.
I’m also worried about backups. People lose access to their Google and Apple accounts routinely for any and no reason at all. Will these keys be stored in the cloud? If so, access to EVERYTHING is just a capricious random algorithm away from being lost.
I wouldn’t touch any passkey system which doesn’t provide a seamless way to migrate away especially if I’ve lost access to my Apple/Google account.
Having a seamless way to migrate away is itself a security risk, since that method could be used by attackers to compromise the key store. The migration path for any of the major players (Apple, Google, Microsoft, Yubikey) involves logging into each site you used a passkey with, adding a new one from your new passkey store, then revoking the old passkey.
Password managers that store Passkeys may handle this differently, though, and are your best bet if you want migration flexibility.
I'm really over people calling backups a security risk.
There's a reason bitwarden, 1password, last pass, etc etc. allow you to export your passwords. They also all allow you to do so in an encrypted file.
Accessible keys are a security risk, regardless of how you feel about it. If a key is accessible on the system then any exploit with elevated read permissions can steal the entire key store. By leveraging hardware features that let you add and use a key but prevent reading it, you mitigate that risk. There’s a reason that on Yubikeys, secrets are write-only.
Bitwarden, 1Password, and other companies who build password managers are able to operate with higher expectations of their users. Their users opted into using a flexible, secure tool, and as such, they can provide riskier options to their customers. They know that providing a TOTP solution in their application doesn’t force their customers to use it when doing so would be outside their risk tolerance.
That said, every password manager that I know of - Apple’s, Google’s, Microsoft’s, Firefox’s, as well as dedicated password managers - has an export tool. But this doesn’t mean that all of those providers value having flexibility. I’d argue that in many cases it just means that they recognize that a password alone isn’t trusted enough to warrant concealing it. Given that you have to know the password to enter it, there’s much less value in concealing it from the end user. Since passkeys don’t work that way and do have that value, it makes sense for providers, if they are opting to prioritize security, would choose a less-flexible solution that most of their users don’t care about.
If the big providers did offer a more flexible alternative, enabling exports, to advanced users, those users would necessarily have reduced security and they would have to opt into that ahead of time, since later the secrets would be inaccessible (theoretically - depending on how the syncing is implemented it might be feasible to intercept them. My assumption, since syncing is within a given ecosystem only, is that when synced they are encrypted with a public key that only their secure hardware can decrypt). Also, having such an option would require a different code pathway when interacting with the secrets store, which would mean more potential code that could have bugs.
The method you describe is untenable for 99.9% of the population. If that is truly the only way to migrate, then this move to passkeys is a catastrophe for security. In the coming years, millions of people are going to be permanently locked out of important accounts. Accounts will be written about the clearly flawed implementation of passkeys by Apple and Google, and a whole generation of people are going to shun passkeys forever. Myself included. This is a nightmare for vendor lock-in. I can see why Apple and Google are so ready to implement this.
How does this work with checking my emails on a public computer in a library, for example? Somehow my private key needs to be shared with the library pc?
Wouldn't the private key stay in your phone and you'd be exchanging a challenge and a response?
Not necessarily. I can’t imagine they’d want you to login to your iCloud or Google account on a public computer. It will probably work how Microsoft “Authenticator” works or how when you try logging in to iCloud or your Google account when you have 2FA turned on:
No sharing of keys necessary
Edit: that was just a guess and there are likely a few ways logging in can be achieved on a public computer without needing the private key on that computer. My knowledge on passkeys is surface level, I haven’t really taken the time to look deeply into them yet
If that's the case, then a bad actor could spam someone's phone with notifications. All they'd need is a username.
Or, like my mum, you don't read what the notification says and just hit 'OK'. Now you've let someone into your account without realising
Shit. Good point. According to this blog at 1Password, Bluetooth can be used to have one device verify another for a service. So I guess if the public device has Bluetooth, it’s possible 🤷♂️
There's more ways such as scanning a Qr code to establish a connection from the app to the computer, or by presenting a number on one device which must be entered on the other
Ok but what's unsecure with '1111' as long as I'm not telling the order of the digits to anybody?
It can be cracked in less than a second?
If someone never loses their phones, laptop... Maybe it's secure.
But if someone steals it, how secure can it be? Is the key protected by the pin encryption? If so the encryption is now useless.
Here is a French video about Micode interviewing the French DGSE : https://youtu.be/g_jEz6aF2b4?si=-sUAIvDf4F7-7kGc
They crack the phone security in 4 seconds with the pin beeing : Mic0rp2022. The software used is hashcat, an open source tool.
Pretty sure he was being sarcastic
Here is an alternative Piped link(s):
https://piped.video/g_jEz6aF2b4?si=-sUAIvDf4F7-7kGc
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Fuck google.
passkeys sounds good on paper and for most users on day to day stuff should improve their security. But the failure path is horrible and it happens at the worst case most of the time. If I have the keychain on the phone and lose it or is out of battery and usually happens that I need to access some service like email, then if the email provider starts forcing people to use passkeys or you only have that method on, then I'm locked out of the account and can't use email. This will happen for all other services that one may need to use on an emergency. Personally I don't like it.
Ummm???? What keychain? Passkeys don't have physical keys. I think you'd better learn more before cursing Google. BTW Apple supports them as well.
“Keychain” is often used colloquially to refer to a piece of software that holds passwords and other secrets, which can include passkeys depending on the implementation.
This video about passkeys is fascinating. They are very secure even if your pin is 1234. The only way for someone to hack your account is if they have your device.
Here is an alternative Piped link(s):
This video
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
How long do you think this will last until they kill it?
Until Google "kills" passkeys as a default for personal accounts? They probably won't. Google can't kill passkeys in general btw, it's an open standard not a Google thing.
They will find a way
Insane take. What other open standards do you believe Google is capable of killing? It's just one company they aren't god.
They kind if killed JPEG-XL
Kinda. Given that nobody else supported it Google dropping it did sort of kill it. Passkeys are very different as they are already supported by Apple, Microsoft, and scads of smaller companies.
a year maybe
This is the best summary I could come up with:
Google is taking a big step toward making passkeys the default login option for its users.
Starting today, users logging in to personal Google accounts will be prompted to create and use passkeys instead of passwords when possible.
They’re both easier to use and more secure than passwords, so users no longer need to rely on the names of pets, birthdays or the infamous “password123.” Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN.
And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
Google has been experimenting with passkeys across numerous products, including Chrome, over the past year.
Users who want to forgo passkeys can uncheck the "skip password when possible" option in their accounts.
The original article contains 289 words, the summary contains 146 words. Saved 49%. I'm a bot and I'm open source!
The problem with Google's passcodes:
In fact, I have not bothered even with 2FA for google accounts. At this point these are just "garbage collection accounts" for spam and youtube subscriptions/playlists, anyway.
i don't own a 'device' to use for this. i don't even want one.