[HN Gopher] Passkeys are now enabled by default for Google users
___________________________________________________________________
Passkeys are now enabled by default for Google users
Author : vdelitz
Score : 190 points
Date : 2023-10-10 14:30 UTC (8 hours ago)
(HTM) web link (blog.google)
(TXT) w3m dump (blog.google)
| hooverd wrote:
| There's nothing about the PKI aspects of passkeys that requires
| you to buy into a vendor ecosystem and have them on device,
| right? They're just key pairs, but I guess it's a good as chance
| as ever to ram through device attestation.
| dilippkumar wrote:
| Hottake here:
|
| The biggest mistake that the passkeys movement did is try to make
| it sound more marketable at the cost of oversimplification.
|
| First up, these aren't really "no password" mechanisms. They're
| closer to ssh certificates. You need to authenticate through some
| other mechanism and then agree to do the equivalent of creating
| and installing ssh certificates on your device.
|
| The ssh certificates get synchronized across your devices
| securely by your cloud provider. But they can never serve as the
| primary authentication mechanism - that will still have to be a
| traditional authentication mechanism.
|
| It's mildly infuriating that someone decided to take this simple
| idea and confuse the fuck out of everyone by positioning it as
| some alternative to a password based authentication mechanism.
| Obviously everyone is going to come and ask a ton of questions
| about how a mechanism without any passwords should work. And then
| the responses further confuse everyone because they don't want to
| admit "no actually you still need passwords"
|
| /rant
| grotorea wrote:
| But do you need passwords? The way things are setup now you do,
| the password is the recovery mechanism. If the recovery
| mechanism was instead something like "photo of face next to
| government ID" then Google could stop using passwords next
| week.
|
| > But they can never serve as the primary authentication
| mechanism - that will still have to be a traditional
| authentication mechanism.
|
| Why not?
| ghaff wrote:
| > If the recovery mechanism was instead something like "photo
| of face next to government ID" then Google could stop using
| passwords next week.
|
| Think about the failure mechanisms. What government ID? Why
| might the face change? Etc. Even if these sound like
| outliers, at scale essentially anything will happen.
| vdelitz wrote:
| what if you sign up a new account somewhere with a passkey?
| Then, it's the primary authentication method, right?
| dilippkumar wrote:
| As far as I understand, this is not a viable mechanism.
|
| Consider a shared computer in a university laboratory or at a
| public library. Or maybe an iPad that is shared by a family.
|
| As a service provider, you usually can not assume that
| someone using your service will log in with a dedicated
| device or with a device that has their primary google or
| apple accounts setup on it. (Some rare exceptions might
| exist).
|
| I don't think anyone wants to deal with customer support
| problems of "oh, I'm stuck in a different country when on a
| holiday and my phone got stolen, can you please recreate this
| key exchange process for me on this untrusted device logged
| in from public wifi at a coffee shop?"
|
| Like with ssh certificates, you create more problems than you
| solve if you use passkeys as the primary authentication
| mechanism.
|
| To answer your question, yes it would be primary
| authentication if you used it that way. But no sane person
| would. Hopefully.
| mxuribe wrote:
| Maybe they could have used more marketable terms like "1-time
| password", or "barely a password", or "mini-password" (to
| denote minimal expected usage of your password), etc.?
| dilippkumar wrote:
| I would prefer something like "secure id".
|
| It reflects that the mechanism is a way to securely store
| some identity related information. It is not a mechanism to
| establish that identity.
|
| The value proposition is still obvious: You need to establish
| your identity once, and then you can securely save it and
| share it across devices and avoid having to reestablish your
| identity every time.
|
| It also removes the "password" confusion entirely.
| Establishing identity could be through a fingerprint or
| verifying a government issued Id card in person etc.
|
| The name also correctly reflects what it is doing while still
| sounding marketable to non technical users. The mental model
| that a non technical user will build more closely reflects
| what is actually happening - which is always helpful to build
| a good user experience.
| mxuribe wrote:
| Yep, 100% this! I vote for "secure id" for all the reasons
| cited.
| r00fus wrote:
| HN crowd understands ssh certs and the difficulty of key
| exchange. Most others simply don't. So they need to simplify.
|
| If the result is that users are not using passwords, then
| aren't passkeys an alternative to passwords?
| sillysaurusx wrote:
| Their point was that at some step along the way, you do need
| to use a password.
|
| Case in point, creating a new google account as a 13yo. If
| you don't have a password and you lose your one device, you
| lose everything. This isn't hypothetical; it just happened to
| a family friend.
|
| Not sure why the discussion got booted to the bottom of the
| thread. Looks like it's a lesson not to label your comment a
| rant.
| [deleted]
| kats wrote:
| Don't quite know how these work yet, but I appreciate how much
| work it took to make something good enough that it was approved.
| Cheers
| jiggawatts wrote:
| As others have pointed out, cryptographic authentication is very
| hard to bootstrap if you simply loose your device.
|
| Just last month my missus cracked the glass of her iPhone. Apple
| repaired it under AppleCare, which is great... _except_ ... that
| they didn't tell her that the "glass repair" entails them
| replacing the guts of the phone and wiping it in the process.
|
| Apple iPhone backups don't contain cryptographic secrets like
| eSIMs!
|
| She got stuck in a loop where she couldn't activate her eSIM
| because that needed her email, but her email needed MS
| Authenticator, which she couldn't activate without an SMS.
|
| She had to drive to the Telco with a pile of photo ID to reissue
| her eSIM. Her bank account got locked in the process despite the
| password being correct because of some sort of phone hardware
| lock.
|
| This took days to fix and multiple in-person visits to various
| organisations. If this had happened while overseas on holiday,
| she would have been _screwed_.
|
| Times have changed.
|
| Your entire digital identity is now a smart card in your phones
|
| That Smart Card is either a SIM card or an onboard TPM chip, but
| in any event if you lose it, you may as well be dead as far as
| anyone else is concerned.
|
| Passkeys make this _much_ worse. At least if you still have a
| physical SIM you can transfer it from any phone to any other
| phone.
|
| Passkeys are not cross-vendor transferable!
|
| Run away screaming. Don't believe the hype. Wait until the
| vendors get their act together and come up with a solution for
| transfer and recovery.
| redrblackr wrote:
| [dead]
| brundolf wrote:
| Honestly, if they'd just give me the option to write it down
| (or take a picture or whatever) and manually restore it by
| typing it in if I need to, that would just about solve the
| issue
| hbt wrote:
| what you are describing is why I use a virtual phone for all
| services.
|
| you can do it on your own with twilio, then create a phone
| number and have a program forward you stuff to your real phone.
|
| the twilio phone is hard to lose as it has an api and you can
| toss it when you want to start over.
|
| except now, you need an entire phone virtualized as your proxy
| instead of just a twilio phone number.
|
| they keep raising the barrier
| ktosobcy wrote:
| For that reason I don't want passkey. Password and regular
| 2fa/totp are fine... when setting 2fa I put it on my phone and
| my computer and another password vault on rpi... granted,
| everything still in same location but still somewhat better.
| I'm not really sold on esim neither - regular sims let you pop
| and swap them easily... why complicate it?
| Shank wrote:
| > Run away screaming. Don't believe the hype. Wait until the
| vendors get their act together and come up with a solution for
| transfer and recovery.
|
| I believe all of the issues you've described, but you can
| usually add multiple passkeys to each service. There is nothing
| stopping you from adding your iPhone and a cheap android phone
| and having redundancy, or using 1Password and storing your
| passkey in there.
|
| iPhone backups _do_ store backups of the media stored in iCloud
| Keychain, if you have another apple device or if you have the
| recovery key, you can get back in. You just need the device
| passcode or recovery key and you can re-bootstrap everything.
| eSIMs are unique because they 're carrier things and those
| things have and always will be a pain and tied to stores and
| phone calls.
| qingcharles wrote:
| Add to that many web sites now make it a point of pride that
| they employ no humans in support and will not do anything to
| help you get back into your account if you are locked out
| (Google, Meta etc).
| briffle wrote:
| that is why its important for 3rd party tools like bitwarden
| and 1password to support passkeys..
| metafunctor wrote:
| Why do you believe that introducing support for passkeys
| inherently makes the situation worse? If you don't trust them,
| you're not forced to use them; traditional methods still exist.
|
| In any case, you should have multiple methods. It could be
| passkeys on multiple devices. It could be TOTP, plus recovery
| codes in a safe. Passkeys are just one more method.
|
| For the longest time, the gold standard for authenticating
| people has been tamperproof hardware with keys that cannot be
| copied. Except iPhones actually have credible biometrics on top
| of that. Much better than Yubikeys, for example. Of course you
| always need to have at least one backup device or other method
| in case your primary device is lost. Now that this is finally
| making it's way to the "normal people", it's suddenly a "run
| away screaming" scenario? Come on.
| garganzol wrote:
| What happens if the phone is lost? A famous Google support, I
| presume?
| pentagrama wrote:
| >To use passkeys, you just use a fingerprint, face scan or pin to
| unlock your device, and they are 40% faster than passwords
|
| >We've found that one of the most immediate benefits of passkeys
| is that they spare people the headache of remembering all those
| numbers and special characters in passwords.
|
| So they aren't considering at all how easy is the autofill
| password feature with a password manager (that they even have
| built in Chrome/Android).
| jesseendahl wrote:
| >So they aren't considering at all how easy is the autofill
| password feature with a password manager
|
| Passwords are a nightmare for both users and service providers
| for a variety of reasons. And password autofill is a bandaid at
| _best_.
|
| If I had a quarter for the number of times I've personally used
| a password manager to auto generate a password which was then
| either reject by the website due to absurd password complexity
| requirements, or had the password seemingly accepted but in
| reality silently truncated behind the scenes....
|
| I know you're commenting on a Google blog post, but FWIW Apple
| acknowledges password managers/autofill in the "Deploy passkeys
| at work" talk from WWDC 2023:
|
| "Let's look at a side-by-side comparison of the experience of
| creating a new password versus creating a new passkey. As you
| can see, creating a passkey is significantly faster and easier
| than creating a password. Just Face ID and you're done. Now
| that we've looked at creation, let's compare the experience of
| signing back in. With a password, the user has to remember and
| type in the password. With a passkey, they just Face ID and
| they're done. A password manager can help improve the
| experience, but even the best password manager can't compete
| with the user experience of passkeys. You are used to having to
| make tradeoffs between better security and a better user
| experience. Passkeys achieve something rare: great security and
| a great user experience."
|
| Source:
| https://developer.apple.com/videos/play/wwdc2023/10263/?time...
| cjcampbell wrote:
| I'm surprised that they're moving forward with this already. As
| of last week, there were still enough rough edges on their
| implementation that I disabled it for my Workspace tenants. The
| two most irritating:
|
| 1. Advanced protection doesn't yet support passkeys. You must
| keep U2F in place for now. 2. If you have a U2F key configured on
| your account, Google will prompt you to use it as a passkey
| before telling you that it's not a passkey and you must login
| with your password. The net result is that anyone using phishing
| resistant MFA loses the ability to have their MFA step
| "remembered" on a device because Google will always prompt for
| the U2F factor before the password.
|
| This aside, I've been doing a lot of testing with FIDO2 flows
| using security keys and passkeys across device types and
| platforms in preparation to roll out passwordless via Okta with a
| couple of smaller clients. Overall, I love the authentication
| flow, but there are a lot of gotchas to keep in mind. We've spent
| a considerable amount of time mapping out the happy path,
| creating onboarding resources, and documenting business
| continuity scenarios. The personal use case is actually more of a
| challenge in some ways, because you need to think about each
| service rather than just one IdP.
|
| FYI, the easy path right now if you need to support multiple
| environments is to invest in 1Password or another password
| manager that supports passkeys. This provides the most consistent
| user experience and works across most platforms, though we're
| still having trouble with Android 14.
|
| We're sticking to hardware keys for highly privileged accounts,
| so admins get a pair of FIDO2 keys. Everyone else gets one
| Yubikey, which serves as a backup if they lose access to their
| devices or need to login on an untrusted device. Android is also
| a problem here. Even in 14, it doesn't seem to support
| passwordless FIDO2 flows.
| wooptoo wrote:
| > Android is also a problem here. Even in 14, it doesn't seem
| to support passwordless FIDO2 flows.
|
| Why would they? When Passkeys provide another opportunity for
| Google to lock-in their customers.
| latchkey wrote:
| Still can't store passkeys in Bitwarden, which is a bummer.
| Should be coming in Oct though per the message at the top of this
| page.
|
| https://bitwarden.com/blog/bitwarden-passkey-management/
| december456 wrote:
| I wont add on to the technical aspect of the discussion, but this
| whole article is "its easier and its faster and its less
| expensive for you!!", a data-harvesting tactic having been done
| for years. Please think, people. I get the security aspect, but
| this technology gives up an astronomic amount of personal freedom
| - even if vendor lock-in is somehow eliminated - and biometric
| data.
| jesseendahl wrote:
| I don't mean this as an attack, just a statement of fact: you
| don't know what you're talking about.
|
| Biometric data is only stored on your device. Logging into an
| app or website with a passkey just uses bog standard asymmetric
| crypto (public/private keypair). Also a lot of thought was put
| into the WebAuthn standard (an open standard) to make sure it
| can't be used as a tracking vector.
| renegat0x0 wrote:
| In one of my groups leaders decided to reuse google suite
| accounts. It was really difficult for me to accept the account
| from a other person. Google sent multiple notification to other
| person phone, had to unlogin, configure two factor
| authentication, the other person had to ignore warnings about
| Linux access. It was nightmare.
| rmellow wrote:
| Simpson's Paradox lives here.
|
| On average, this might increase security (the vast majority of
| users are terrible at using passwords).
|
| For proficient users who use passwords securely, this is an acute
| drop in security (if forced to use).
|
| Forced phone number 2FA has the same effect; in Big G's case
| _forcing_ phone number 2FA is anti-anonymity disguised as
| security. In this case, it 's a bid for biometrics.
| grotorea wrote:
| > For proficient users who use passwords securely, this is an
| acute drop in security (if forced to use).
|
| Why? Because the user can have their device stolen and the PIN
| guessed? Can't you use a long password instead of a PIN if you
| want to?
|
| And this part I'm not sure of, please correct me if you know.
| If I understand it correctly there's one security advantage
| even assuming a sophisticated user who is immune to weak
| passwords, password reuse or phishing. If there's ever a leak
| of Google passkeys, the leak would only get public keys, which
| can't be used for login, making the leak mostly useless.
| forward1 wrote:
| > Forced phone number 2FA has the same effect; in Big G's case
| forcing phone number 2FA is anti-anonymity disguised as
| security.
|
| It can actually be both; in fact it very likely needs to be:
|
| 1. Phone numbers are the best long-term identity most people
| have
|
| 2. Google has billions of users and needs to support account
| recovery at unbelievable scale
|
| 3. Many people lose passwords and devices, but very few lose
| phone numbers
|
| It logically follows google uses phone numbers to assign and
| delegate identity on their platform. Is this bad for privacy?
| Yes, but it's also very good for security because it allows
| users to control their data using a third-party authenticated
| "credential" they don't have to manage.
| rmellow wrote:
| All of this is valid!
|
| But it would be even more secure if there was an opt-in "I
| don't want to use my phone as 2FA".
|
| Phone number authentication creates a weakness for anyone who
| is in a targeted attack.
|
| A motivated attacker can easily bribe/trick a telecom
| employee, or if physically accessible, swipe the phone itself
| to read 2FA texts.
| px43 wrote:
| Sign up for Google's Advanced Protection Program. It's been
| around since 2017, and last I checked, it's the only way to
| fully disable the use of your phone number for
| authentication.
|
| https://landing.google.com/advancedprotection/
| novok wrote:
| Passkey isnt google or apple dependent. You can have holders /
| managers that are your own, which is necessary for corps and
| govt.
| aseipp wrote:
| > In this case, it's a bid for biometrics
|
| Biometrics are used to unlock an local, on-device key storage
| mechanism which contains a private key, and from that you can
| derive a public key, and that's what Passkeys fundamentally
| are, is a public/private keypair you use to validate you are
| logging into a website. If Google were harvesting your
| biometrics they were just doing it already and it has nothing
| to do with this.
|
| This is an extremely basic detail of the security model that
| has been true since long before these were introduced, back
| when the iPhone started using e.g. the secure enclave; I don't
| know why people on this website talk so adamantly about things
| they clearly do not understand at all. It's honestly kind of
| astounding.
|
| > For proficient users who use passwords securely, this is an
| acute drop in security (if forced to use).
|
| No, it isn't, it's the moral equivalent of an SSH key to login
| to a server instead of using SSH password to login to a server,
| but now apply that to a website. And beyond that, it's
| objectively wrong; for instance passkeys are literally phishing
| resistant, and no amount of thinking you can "use passwords
| securely" can change that simple fact.
| nottorp wrote:
| No one has managed yet to explain to me how you recover access to
| an account using these passkeys if you somehow lose access to all
| your devices.
|
| Note that i said "all your devices" so the cloud backup you dream
| of will also be inaccessible because I can't authenticate to that
| either.
|
| And I know about backups... what about your average user who is
| likely to own a single phone and no other device? They lose
| access to everything if they drop it in the toilet?
| jiveturkey wrote:
| https://safety.google/authentication/passkey/
|
| > Yes, you can continue to log in using your traditional log in
| [sic] method, which in most cases would be using your username
| and password.
| secabeen wrote:
| Now extend that; it's not you trying to recover access, it's
| your relatives or heirs trying to do so, because you are
| incapacitated or dead.
| HumblyTossed wrote:
| > What are Passkeys?
|
| > Passkeys are a new way to sign in to apps and websites. 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.
|
| I _HATE_ paragraphs like this. It 's as if you're purposely
| obfuscating what they really are.
| [deleted]
| CosmicShadow wrote:
| Is it hard to remember the one password you use for all Google
| services everyone's already been doing forever and will still
| have to do for every other site? When's the last time anyone even
| had to log into Google on any device? I'm signed in everywhere
| all the time and it almost never seems to expire...
|
| My desktop doesn't have a camera, fingerprint reader or touch
| screen...
| rkagerer wrote:
| If I may, I'll repeat a comment I made a few days ago:
|
| Give me an implementation I can self-host, without Google, Apple,
| etc. having effective control (including claws in my relevant
| software supply chain) and with an easy user experience, where I
| can maintain secure backups (on my own infrastructure, thank you)
| and smooth transition to future devices, and ideally, if needed,
| securely export root keys (cause if I don't control them then
| someone else owns them), and maybe I'll be interested.
|
| In the meantime plain old high-entropy passwords with a good
| manager gives me all those features and a simplicity that's hard
| to beat.
|
| In my 30+ years of computing I've suffered more harm from
| failures of other companies than I have from any failure of my
| own diligence. The whole lesson learned is to reduce trust in
| them and, maybe I'm wrong, but everything I've read about
| passkeys and the like seems to put me at liberty of the companies
| developing and pushing the implementations of them down my
| throat. It will take a lot of trust before I give up my ability
| to copy/paste my credentials.
|
| (https://news.ycombinator.com/item?id=37794379#37796842)
| whartung wrote:
| As I understand it (which mean I can be completely wrong), in
| order to utilize Passkeys, at least at the browser level, you
| need support within the browser.
|
| Firefox has a build that supports passkeys, and I believe
| 1Password has an extension for Firefox that supports passkeys.
|
| If "all you need" for Passkey support is a custom extension, it
| should be straightforward to create one that does whatever you
| want (including storing your private keys in plain text in your
| home directory, which many argue is a bad idea, but that's not
| the point).
|
| Is 1Password a magically signed and authorized extension, or
| can any Joe pound out a quick hack using JS and Firefox?
|
| I appreciate that the client and credential management should
| be sophisticated and secure, etc. But the API is the API, it's
| supposed to be an open API, and I can understand Chrome,
| Safari, and Edge, being closed source browsers, may or may not
| allow anyone to hack their own keystore regimen.
|
| But, I don't think Firefox is doing that (unless the 1Password
| extension is magically blessed by Firefox somehow). At a
| minimum, you can always go the source, and rebuild Firefox to
| do what you want. Involved, to be sure, but possible.
| CharlesW wrote:
| Presumably your current password manager meets those
| requirements. Why not just use it (if it doesn't support
| passkeys today, it surely will) to manage your passkeys as
| well?
| [deleted]
| gumby wrote:
| This may cause me to "up"grade to 1Password 8, which I have been
| dreading.
| LeoPanthera wrote:
| Be aware what you're getting into:
| https://news.ycombinator.com/item?id=37836783
| gumby wrote:
| Ugh.
| efitz wrote:
| There's a good, simplified diagram of how passkeys work here:
| https://github.com/passwordless-id/webauthn#how-does-the-pro...
| aboringusername wrote:
| One question I don't often see asked in regards to passkeys: what
| is the legal standing in regards to law enforcement access to
| 'passkeys' vs passwords?
|
| For example, it is completely valid to say I genuinely do not
| know my 1000 long multiple special character password; it could
| be on a piece of paper, in a file encrypted with multiple layers.
| Essentially, there is no foolproof way to ever prove whether I
| know a given password, or not, especially if the password is only
| ever in my head (assuming the plaintext version is never logged,
| all you would ever have as 'proof' is a hash to compare it to).
|
| Passkeys make it so that, I imagine, there is an element of
| 'proof' at all times; your face, fingerprints (which in some
| countries you are required by law to provide), I can't disprove I
| "own" my fingers so that element is always there, and you can be
| compelled to provide your fingerprints at any time for any reason
| - with a password, it is _impossible_ to know whether I know a
| password.
|
| In that sense, a password is far, far, far stronger than any
| other method of authentication.
|
| Take a scenario: Mr Police wants access to your phone, it's
| protected only by your fingerprint, pretty easy to gain access.
| Now do the same but with a password that's sufficiently complex,
| written on a now shredded piece of paper, and there is genuine
| plausible deniability.
|
| I imagine in a lot of cases this is extremely important and
| passkeys will be shunned altogether.
| zackmorris wrote:
| Will this work for social login, like if I use my iPhone to sign
| into Gmail with a passkey, can I then sign into Reddit with Gmail
| and not have to enter a password? I'm assuming so.
| 1980phipsi wrote:
| Finger prints and face scans are better replacements for user
| names than passwords.
|
| I had read some good things about YubiKey, but I don't think I
| could get it to work on my corporate computerr.
| the_snooze wrote:
| Passkeys aren't "finger prints and face scans." They're dolled-
| up versions of SSH key authentication.
|
| Just as SSH private keys can have passphrases to unlock them,
| passkeys can have passwords, passphrases, PINs, or biometrics
| to unlock them too. Servers don't authenticate you on those
| PINs or biometrics; those merely unlock the associated private
| key.
| nytesky wrote:
| Can you store a passkey on a YubiKey? Or just buy a $100 android
| phone just for passkey backup to keep at home?
| Shank wrote:
| 1. Yes! Using resident keys, yubikeys can store a number of
| them. Not an infinite number. It's 25 resident keys.
|
| 2. Most services let you add more than one passkey. Using
| 1Password, or using iCloud Keychain or similar, you can sync
| passkeys between devices. Even with iCloud Keychain, if you
| have only one device, you're given a recovery code that can
| bootstrap the entire system from zero if your only device is
| stolen.
| reisse wrote:
| Always remember that passwords are protected by Fifth Amendment
| and similiar laws in other countries, but there is no law
| prohibiting officer to put your phone in front of your face to
| unlock it.
| shepherdjerred wrote:
| For iPhone users, you can mash your power button and it'll
| require a PIN to unlock the phone. Biometric auth will be
| disabled.
| fragmede wrote:
| Why make claims for other locations when you don't know about
| them, and it could lead to serious consequences? In particular
| the UK has no such compunction.
| jjgreen wrote:
| Two years in prison for failing to unlock your phone in the
| UK (Section 49 of the Regulation of Investigatory Powers
| Act). Don't forget that password!
| jiveturkey wrote:
| I feel that this is net negative.
|
| You have to meet people where they are at.
|
| per some support document (sorry lost the link), by default,
| Android users will have passkeys synced to their google account.
| So first of all, this is a lock-in play on Google's part. The
| passkey FAQ only mentions iCloud, so second of all it's a duopoly
| reinforcement. (This really needed Apple to first release passkey
| support.)
|
| Beyond that, there are so very many ifs, ands, and buts around
| recovery and third party device usage that a typical user can't
| really keep it straight.
|
| It's more convenient ... until it isn't.
| TMWNN wrote:
| The post mentions eBay as a site using passkeys. eBay's
| implementation on PC accepts Touch ID, while Google's
| implementation did not the last time I tried it.
| vdelitz wrote:
| try this one: https://g.co/passkeys (you need to have set up a
| passkey before though)
| TMWNN wrote:
| Thank you. I am embarrassed to say that using the site
| reminded me that, actually, I had already created Touch ID
| passkeys for my Google accounts. I think what confused me is
| that passkeys were not available for Google Workspace yet, so
| my account there couldn't use passkeys. That has now changed.
| groovybits wrote:
| I see a lot of misinformation, or misunderstanding, of Passkeys
| in this thread.
|
| I highly recommend reading Steve Gibson's notes on Passkeys from
| his Security Now! podcast episode #870:
| https://www.grc.com/sn/sn-870-notes.pdf (p. 10-13)
|
| For context, Gibson developed, and completed, an entirely secure
| and working solution to the problem Passkeys aims to solve,
| called SQRL (which I argue is better than Passkeys in a few
| ways). He is familiar with this problem space, and explains
| Passkeys in a straightforward way.
|
| You can find this full podcast episode on Twit.tv:
| https://twit.tv/shows/security-now/episodes/870
|
| You can also find a full text transcript of the episode,
| transcribed by a human - by hand, here:
| https://www.grc.com/sn/sn-870.htm
| xhkkffbf wrote:
| One of my companies switched to Yubi pass keys. They were super
| cool -- until I tried to log in on a computer with only USB-A
| ports. My key is USB-C. I suppose I need to get an adapter now.
| toomuchtodo wrote:
| Passkeys are stored within your device, iPhone, Android,
| browser, or system keychain.
|
| https://passkeys.directory/
|
| https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
|
| https://support.apple.com/en-us/102195
| jasonjayr wrote:
| Does this work with Linux Desktop ?
| flkenosad wrote:
| What if you use an old-fashioned desktop PC?
| vdelitz wrote:
| if the PC has Bluetooth you could use a passkey from a
| smartphone - besides that, if it's a Windows PC, you could
| use Windows Hello (with a PIN)
| lazide wrote:
| Or yubikey.
| rnijveld wrote:
| They don't have to be though, a yubikey can be used as a
| passkey as well.
| toomuchtodo wrote:
| They can be, but most people will use what is built into
| their mobile ecosystem of choice, with built in
| sync/backup. Physical secure authenticators in general use
| will likely remain rare, but are still useful for use cases
| where passkeys that can be synced or migrated are not
| secure enough (and you want access governed with a simple
| physical device).
| dogleash wrote:
| Does the language on this page set off anyone else's dishonest
| ratfuck scammer detector?
|
| Forget about the auth tech; this could be the cure for cancer and
| still give me "don't look behind the curtain" vibes.
| marcosdumay wrote:
| The title triggers me by itself. The article is actually much
| less problematic.
|
| Anyway, I guess the way people are reacting on the comments is
| overwhelmingly due to the language. And the fact that it
| doesn't even try to explain anything.
|
| IMO, the author didn't really know the things the article is
| about and is writing about some 3rd party information.
| fckgw wrote:
| No? You wanna expand on that?
| px43 wrote:
| Except that Google and everyone else pushing passkeys have been
| publishing massive volumes of highly technical details about
| all of this for years.
|
| You're looking at a non-technical blog post targeted towards
| the general public, and non technical journalists. Any
| technical details you want are just a search away.
| vdelitz wrote:
| I don't think so
| jehb wrote:
| There are a lot of interesting points being made in the
| conversation here.
|
| What I haven't seen yet is a reminder that a Google Account is
| effectively Google's private property that they're letting you
| access in exchange for vacuuming up your personal data.
|
| The only winning move is not to play.
| fortran77 wrote:
| My 90 year old mother saw this change, clicked on something she
| can't remember, and now can't login. She's been able to login
| using the username and password she keeps on a card next to the
| computer just fine up to now.
| shadowgovt wrote:
| Passkeys make accessing all your online services as easy as
| accessing your phone.
|
| ... that is a statement that some people will find convenient and
| some people will find terrifying. As much as I'm excited for the
| convenience, this is my primary concern: how easy is it for a
| stranger to unlock your phone? Most people intentionally keep
| their phones easy to unlock because they're doing that dozens of
| times a day.
| isykt wrote:
| Why is a pin more secure than a password?
| kube-system wrote:
| It isn't, and this isn't authentication with a pin.
|
| Passkeys also requires the device. Using a pin with this is
| 2-factor. Pin + hardware token.
| isykt wrote:
| So why not just have a password that then unlocks the
| passkey? I already have a password manager.
| abhinavk wrote:
| You should be able to use your password manager to handle
| passkeys. Enter your master password in 1Password, use
| passkey. And Bitwarden support is coming.
| tzs wrote:
| You can have that by storing passkeys in your password
| manager, if it has support for that. Currently 1Password
| does, and BitWarden either does or is suppose to soon. I
| haven't looked at any others.
| michaelt wrote:
| The standards group that was behind Fido/U2F has been taken
| over by people who want to push a new product. That new
| product is "Log in with your phone" and phone lock screens
| allow biometrics and pins.
|
| Password managers are not relevant, as you don't use a
| password manager to unlock your phone.
|
| The people behind the takeover don't really give a shit
| about Yubikey-style tokens (which haven't achieved much
| market penetration anyway) but they've left them in to make
| the takeover less blatent.
| kube-system wrote:
| More like the other way around -- the existing FIDO/U2F
| crowd was a bunch of businesses that made money selling
| keys. And that's why adoption was a rounding error, it
| was infinitely more expensive than a free password, so
| few implemented it. This is the obvious solution -- we're
| already carrying devices with a secure enclave, just use
| that, it's free.
| snowwrestler wrote:
| Sure, PINs can be long and alphanumeric on most phones
| these days.
| tuckerman wrote:
| If you already have a password manager it might already or
| might soon natively support passkeys as well (1Password
| already does as an example)
| groovybits wrote:
| The PIN (or biometric) is not used to replace your Google
| account password. The PIN (or biometric) is used to
| authenticate to your device that holds your Passkeys, which in
| turn will authenticate you to your Google account (or any
| account that supports Passkey-based sign-in).
| akerl_ wrote:
| The PIN is checked by the local device. It never goes over the
| network, and the device can limit the number of PIN attempts to
| a very small number, because the only way to try PINs is to
| have access to the device.
| TacticalCoder wrote:
| So what is going to happen to those who were using U2F and then
| later on webauthn?
|
| If you registered, say, a Yubikey, many moons ago, on your Google
| account. Is this Yubikey now automagically going to become a
| "passkey"?
|
| Or will you have to choose between logging in with your Yubikey
| or with a new passkey? (say something Google controls, in your
| phone for example)
| qudat wrote:
| I'm probably wrong but I expected passkey and yubikey to be
| interchangable. So if you are presented with a browser prompt
| for webauthn, you can use yubikey or passkey
| jjoonathan wrote:
| Ugh, is this why my FIDO key started making me enter a redundant
| pin on the company login page (so: enter password, press FIDO
| key, enter PIN, press FIDO key)?
| di4na wrote:
| Yes. That plus the way apple implemented it.
|
| In my case i was already on passkeys and google decided to
| just... forget them all on my other computers. I can't use them
| to get in anymore. Why? Who the heck knows.
|
| This whole passkey shit is going to be a nightmare for UX.
| lazide wrote:
| "Weaponized" 2fa (already very common) is a huge UX fail too.
| In theory this could reduce those terrible flows.
| ghaff wrote:
| In general, the levels of security that people will
| increasingly need going forward, and the increasing
| requirement by companies to use that level of security, will
| be a usability pain for many people and a nightmare for at
| least a subset.
| rurp wrote:
| Is there any evidence that Google needs to mess with
| authentication flows? My mental model of the median Google
| account holder is that they have a bunch of
| photos/emails/docs/etc that are extremely valuable to them
| and their family, but of little value to criminals. With a
| dynamic like that, the security only has to be so high to
| deter random hackers and making it too difficult or
| confusing will ruin a lot of valid accounts and do much
| more harm than the criminals would have.
|
| There are reasons to be skeptical of Google's motives here
| given their history of wanting to create user lock-in in
| various ways, and caring more about shiny new tech than
| general user experience.
| dagoodboy wrote:
| When can we use real crypto on a Smart Card / PIV / CAC without
| relying on Google, MS, or the Government?
| p1mrx wrote:
| What happens if I lose my phone?
| conqrr wrote:
| They are saying losing phone + revealing pin is harder than
| exposing your password/phishing/social engineering/cracking.
| ellisv wrote:
| What happens if you forget your password?
| MrStonedOne wrote:
| [dead]
| fbdab103 wrote:
| A password I can write down. A phone can be lost/stolen/black
| screen.
| qup wrote:
| They let me use my phone to login again
| lopis wrote:
| You recover it?
| zb3 wrote:
| I reset it using my SMS 2FA phone. I can't lose that number
| because in my country I'm legally entitled to it.
| bufferoverflow wrote:
| Isn't it obvious that logging in with your face or your
| fingerprint is less secure? Sure, it's convenient, but any thug
| can just forcefully unlock your device.
| forward1 wrote:
| Most "thugs" interested in data sit in windowless offices in
| Manila or Delhi and effortlessly spam phishing and other
| attacks on weak credentials; they do not roam the streets
| looking for face-unlockable devices to exfiltrate. That is to
| say, almost all attacks are remote. And just because someone
| walking next to you on the street might have a black belt in
| martial arts, does not mean they're going to turn you into a
| pretzel on sight.
|
| The reality is people are not good at creating, managing and
| using credentials well - and this is an existential risk for
| most users not realized until it's possibly too late. Any
| efforts to assist, support and otherwise absolve users of
| credential responsibility is a net win for infosec (though
| likely a loss for privacy).
| grotorea wrote:
| Can't the thug apply the 20$ wrench to your face until you say
| your password?
| bbddg wrote:
| I think for anyone not working in national security, any thug
| could just as easily get your password out of you.
| forward1 wrote:
| Reminds me of this wondeful scene in Ronin:
|
| _Everybody has a limit. I spent some time in
| interrogation... once._
|
| _They make it hard on you ? - They don 't make it easy._
|
| _Yeah, it was unpleasant. I held out as long as I could._
|
| _All the stuff they tried. You just can 't hold out for
| ever._
|
| _How 'd they finally get to you?_
|
| _They gave me a grasshopper. - What 's a grasshopper?_
|
| _That 's two part gin, two part brandy, one part creme de
| menthe..._
| kube-system wrote:
| Most thugs don't have physical access required to exploit this.
| They're on the other side of the world and are doing credential
| stuffing attacks.
| renegat0x0 wrote:
| In case od data leak - you cannot change your face, or
| fingerprints. You can change passwords though.
| ezfe wrote:
| Good news that you can't bring someone's face to google and
| ask for access to their account...
|
| Please don't insert commentary when it's clear you don't know
| what you're talking about
| renegat0x0 wrote:
| Thieves can steal a car using tech magic. That is also true
| about access to accounts. That contradicts your comment.
| Biometrics, if stolen, can be used to access any of
| accounts if one obtains knowledge about how to use it for
| hacking.
|
| Your comment violates HN guidelines, but as guideline says
| I assume good faith therefore I have provided details about
| how you're incorrect on that one.
| Savely wrote:
| Yeah, because good old passwords are safe against thermo-rectal
| cryptoanalysis.
| powera wrote:
| Nope, not signing up.
|
| The trend from Google continues to be towards "if you lose your
| phone with your credentials, you will be unable to log in". And
| Google refuses to create a scalable system that allows you access
| to your account by verifying your identity in person.
|
| This is a recipe for disaster. And, possibly, a warning to move
| off GMail before it gets worse.
| grotorea wrote:
| For now at least, they saying you can still login with
| traditional methods as a backup even if using passkeys.
|
| Is it possible to control the credentials in your phone and
| copy them somewhere else?
| secabeen wrote:
| > And Google refuses to create a scalable system that allows
| you access to your account by verifying your identity in
| person.
|
| People complain about government services, but this is
| something that government is good at. The DMV serves
| _everybody_ , regardless of personal views, criminal records,
| etc. Companies can refuse service to anyone for any reason.
| What happens when you put all your eggs in Google's basket, and
| then they decide to close your account with no recourse.
| ed312 wrote:
| I'm about at the threshold for wanting to de-google my life. Do
| you have an alternative email provide you recommend?
| hooverd wrote:
| I use fastmail.com because I wanted to use my own domain.
| They're not free - make of that what you will.
| queuebert wrote:
| Fastmail rocks. I decided years ago to be the customer not
| the product, so I don't mind paying for services I use.
|
| An added benefit of Fastmail is somehow its calendar is
| able to sync between my Outlook work calendar and some
| shared Google calendars I have, while Google is completely
| unable to reliably sync a shared Outlook calendar for me.
| opan wrote:
| Anything with working IMAP so you can use your own client.
| So, not Protonmail or Tutanota.
| neonnomad wrote:
| I would recommend Protonmail because you can also have a plan
| that allows you to use your own domain. The interface is much
| better than Google IMHO and the spam filtering is up there as
| well.
|
| Other alternatives:
|
| https://www.hey.com
|
| https://www.skiff.com
|
| https://www.fastmail.com
|
| https://www.icloud.com with advanced protection turned on
| edvinbesic wrote:
| Not parent but the more important thing in "de-googling" is
| to move your logins to your own domain. That way you are not
| tied to a single provider and can always switch if your
| current one starts degrading.
|
| After over a decade of @gmail being my primary personal email
| it is pretty painstaking to move all of my logins over, and
| some services do not allow you to change your email at all so
| your mileage may vary.
| vel0city wrote:
| Several months ago I moved my family's email hosting to Zoho.
| Its been pretty solid. The web client is really nice, its got
| pretty good mobile apps, it provides IMAP/Exchange Sync on
| their cheapest paid tier so you don't need their apps. Zoho
| has a 5 user free tier of just email, but you're then limited
| to their apps. I'm using the Mail Lite tier with the larger
| 10GB storage which is $1.25/mo/user billed annually.
|
| They have some tools to migrate email. I was migrating from
| an IMAP source, the migration was pretty quick and painless.
| endisneigh wrote:
| Once this rolls out plus attestation the days of using mainstream
| sites anonymously with an account will come to an end.
| frabcus wrote:
| As a user I still don't understand this.
|
| What happens if there's a house fire or something and all my
| devices where I'm logged in with Google break? How do I log into
| my account again?
| grotorea wrote:
| > What is the account recovery process if I'm locked out and
| don't have my phone, say it's lost or broken and I can't verify
| my identity?
|
| > You can always fall back to legacy authentication options
| such as passwords and traditional 2-step-verification. In a
| case where you can no longer remember your password, you can
| also go through Google's Account recovery flow. We encourage
| you to add your email and phone number to ensure you can always
| access your account.
|
| > https://safety.google/authentication/passkey/
| chupaolo wrote:
| Then what's the point of it all if a hacker can still get
| into my account using the traditional methods? This seems to
| be just opening up another avenue of attack.
| px43 wrote:
| My Google account is set up such that account recovery
| requires me to actually travel to Mountain View and present
| several forms of ID, and that's just how I want it to be.
| lxgr wrote:
| Are you joking or does Google really do in-person
| verification for high-value accounts (e.g. GCP or Play
| Store developer accounts)?
| grotorea wrote:
| If I understand it correctly it will avoid phishing,
| assuming people notice there's something up when they see a
| page asking for a traditional login for no good reason when
| they have passkeys. And it may be a transitionary step
| towards no passwords or something.
| rcarr wrote:
| A lot of services, but not all, will let you add passkeys which
| are tied to a password manager (e.g 1password) and not a
| physical device. If you've got one of those set up, you can
| download it on a new device and then gain access that way. In
| the case of 1password, this means you either have to remember
| your master password and your access key, or you have to have
| this stored somewhere safe. Perhaps choose a memorable
| password[1] and then encrypt an sd card and use one of these[2]
| in your wallet or a keyring usb drive or a yubikey so in the
| event of a fire all you have to do is grab your wallet or keys
| and you're good to go. Alternatively you could store this
| information in a safety deposit box, or with a trusted
| relative, or even your lawyer if they offer such a service.
|
| At the end of the day, it's the individual's responsibility to
| determine how much they value their digital security and take
| what they deem to be the necessary steps, expenses and
| precautions to protect it. The only other alternative would be
| for Big Tech to have some kind of integration with the state,
| so that your digital accounts are tied to something like your
| passport or social security number, so that there are
| procedures available for regaining your digital identities in
| the event of catastrophe, just like you can do with your
| physical identity.
|
| I personally think that the latter is where we are heading, not
| necessarily because of scenarios like you've mentioned, but
| because it's only a matter of time until AI advances to the
| point where it's going to cause a dangerous breakdown in trust
| and the only way it's going to be fixable is with some kind of
| system that is tied to physical reality. The internet will end
| up splitting into two, with the majority spending their time on
| the "verified" web, which will be websites using OAuth that
| will require you to use an account with one of the big
| providers who will have verified with the government or third
| party agency who you actually are. And then any websites that
| don't require this will form a sort of new, more accessible
| "dark web". I honestly think the majority of people are feeling
| that wary and weary of the internet at this point that they
| will happily choose the verified web, regardless of the
| surveillance implications.
|
| [1] https://xkcd.com/936/
|
| [2] https://amzn.eu/d/ia3kFeJ
| kseifried wrote:
| Updated my paper:
|
| https://news.ycombinator.com/item?id=37833390
|
| Scenarios dealing with the loss of Passkeys:
|
| The scenarios for dealing with the loss of Passkeys are
| effectively the same as dealing with the loss of your Password
| Manager (if you use one) or otherwise stored passwords.
|
| Dealing with the loss of all your devices that use Passkeys If
| you manage to lose access to all your devices that are used to
| authenticate via Passkeys (e.g., a house fire), then there are
| two main outcomes: either you have your Passkeys synchronized
| to a cloud provider or other external entity that still has a
| copy of all your Passkeys, or you do not. If you do not have a
| backup of all your Passkeys, they are gone, and you will need
| to fall back to account recovery for each affected account. If
| you have a backup of your Passkeys, you would need to regain
| access to it on a new device and then synchronize the Passkeys
| to it and use them as normal.
|
| Dealing with the loss of your accounts that synchronize and
| store Passkeys If you use a synchronization service attached to
| an account, it is possible that the account can be deleted or
| access to it otherwise lost. In this event, you would most
| likely still have a working copy of your Passkeys on your
| devices, and depending on whether or not you can export them or
| reconfigure synchronization with a new account, you would be
| able to add them to a new account, effectively creating a new
| account to store and synchronize your Passkeys.
|
| Dealing with the loss of all your Passkeys
|
| If your Passkey account is not only deleted but also tells all
| your devices to delete the Passkeys, or you lose all your
| devices and the accounts are deleted due to inactivity then you
| are basically in the same situation as having lost all your
| devices and not having a backup. You will need to fall back to
| account recovery for each affected account.
| secabeen wrote:
| This is accurate, but by putting your passkey backup with
| that external entity, you are putting all your keys in that
| basket. Passwords have an obvious, backup option with zero
| dependencies on third-parties: A printed list in a fire safe.
| I would not advise users go heavily with any passkey provider
| that does not provide a physical backup of a similar form
| that can be secured through non-technical means, and that can
| be used by an heir or attorney to act as you when you are
| unable to do so.
| the_snooze wrote:
| Passkeys aren't inherently un-backup-able. I do agree
| though that the most common forms of it (e.g.,
| Android/iOS/Windows secure enclave passkeys) need better
| ways of recovery and remediation.
|
| That said, what you describe is easily doable in other
| forms. For hardware tokens, you can have a spare Yubikey
| that's authorized on your accounts and keep that in a fire
| safe with its unlock PIN. For something like 1Password, you
| can print out a recovery kit [1] with the secret key and
| unlock password.
|
| [1] https://support.1password.com/emergency-kit/
| secabeen wrote:
| > Passkeys aren't inherently un-backup-able
|
| Agreed, I'm just not willing to endorse their use until
| there are robust recovery and remediation processes.
|
| > For something like 1Password, you can print out a
| recovery kit [1] with the secret key and unlock password.
|
| Yeah, this is what I want Google/Appleto provide as it is
| robust to both user incapacity and provider refusal-of-
| service.
| kseifried wrote:
| The problem with that is people don't have fire safes. Or
| homes in some cases (e.g. many unhoused people have
| smartphones now). Also people need to travel and do
| recovery without having to fly home to their safe.
|
| The idea that printing a backup is easy and an option for
| many people is often not the case.
| secabeen wrote:
| > The idea that printing a backup is easy and an option
| for many people is often not the case.
|
| Fair enough, but that is an argument for multiple durable
| recovery and remediation solutions, which few of the
| current providers have.
| rtsil wrote:
| And that is why most people use a single, easy to
| remember password for everything: even if their house
| burns, their devices are gone and they no longer have
| their phone number, they can still remember their
| password.
|
| For all of its many weaknesses, a password has that one
| major advantage over all the other authentication
| methods, and unless a new method provides a similar
| advantage, most people will keep using a password, just
| like they did even with the appearance of private keys,
| biometrics, USB tokens, SMS or TOTP.
| dsego wrote:
| And it's a hassle to keep it in sync. If you decide to
| update your password you need to remember to print out a
| copy and store it in the safe, oh and throw out the old
| one.
| konschubert wrote:
| And what if somebody breaks into my google/iCloud account and
| syncs all my passkeys to their machines?
| px43 wrote:
| If they're in your Google/iCloud, you're already in a game
| over scenario. The point of all this is to prevent that from
| happening.
|
| You can try to recover by revoking all your passkeys and
| starting over with hardware tokens, but that's likely what a
| sophisticated attacker is going to try as well, and they're
| probably faster than you.
|
| Still way way better than passwords.
| 13415 wrote:
| How is that better than passwords? I backup my encrypted
| passphrase database to a cloud provider. When my house
| burns down and all my devices are lost, I get a new device,
| download my own passphrase manager app, download the
| passphrase document, and continue as before.
|
| If someone breaks into the cloud provider and downloads my
| passphrase document, nothing happens.
| konschubert wrote:
| If they break into my iCloud then they're in my iCloud.
| They're not in all my other accounts, because I use an
| encrypted password manager that isn't iCloud.
| skarra wrote:
| Think of it as using iCloud as your password manager and
| storing your OTPs - someone breaks into your iCloud, they
| get access to all the passwords and OTPs to login to any
| service in iCloud.
|
| Always take the security of your password manager / sync
| accounts seriously. Use hardwre security keys if needed
| on the "root accounts".
| lxgr wrote:
| iCloud is unfortunately impossible to adequately secure
| for that use case.
|
| If you shoulder-surf somebody's phone unlock PIN and grab
| their phone, you have everything you need to take over
| their iCloud account, including their passkeys and the
| capability of locking out all of the victim's other
| trusted Apple devices and changing their iCloud password.
|
| This was very surprising for me to witness first hand -
| fortunately not in the identity theft scenario, but only
| when observing a relative regaining access to their
| iCloud account using only their iPad they were logged in
| on.
| skarra wrote:
| It is a fair observation. And I can see why users tend to
| be alarmed about this. Although in my experience users
| tend to significantly underestimate the real risks of
| online attacks relative to these more visceral threats.
|
| Let met ask you: has that discovery made you stop using
| your iPhone, or storing passwords or other critical data
| in your iCloud? If the answer is "No", then you're
| strictly better off moving to passkeys stored on iCloud
| as well.
| lxgr wrote:
| > Let met ask you: has that discovery made you stop using
| your iPhone, or storing passwords or other critical data
| in your iCloud?
|
| Yes, it has (the latter). I was a big fan of (non-
| synchronized) on-device passkeys, but this has
| significantly changed the threat model for me.
|
| I use a third-party password manager exclusively now, and
| I'll probably be using its synchronized Passkey
| implementation too if it turns out to be any good.
|
| As soon as Apple starts offering a different set of
| security trade-offs (e.g. make usage of the recovery key
| mandatory when resetting my iCloud password, or at least
| implement a timed lockout), I'd gladly start using iCloud
| Passkeys and maybe also its password manager.
| ngrilly wrote:
| The passkeys are encrypted before leaving your machine and
| Google/iCloud are only storing the encrypted passkeys and
| can't decrypt them.
| konschubert wrote:
| Presumably encrypted with e.g. my iCloud password ?
| ngrilly wrote:
| Kind of, but it's more complicated than that. Details
| there (and in the link at then bottom of the page):
| https://support.apple.com/en-us/102195
| Anduia wrote:
| When you get a duplicate of your SIM card you can then verify
| it is you with a SMS code. There are also security questions
| and alternate email you can configure just in case.
| havnagiggle wrote:
| Just happened to my in-law. She dropped her phone on the
| stairs, screen cracked, and became unresponsive. I gave her an
| older phone I had and swapped the sim fine. But she couldn't
| figure out how to log in to Google account because it was so
| adamant telling her to use her phone. Her laptop was logged out
| of her email, etc. Fortunately I have backup tokens for her
| from a previous incident heh. I have no idea what other folks
| will do.
| hansvm wrote:
| A few months ago Google wouldn't even accept backup tokens
| for me. I was on vacation, and that tripped enough fraud
| detectors to cause problems. I couldn't log back in till I
| got on my home network and changed my password.
| Msw242 wrote:
| Get a lockbox at the bank
| hn_throwaway_99 wrote:
| I'm don't know the specifics of how passkeys with Google
| work, but don't they usually require multiple synced devices?
| amf12 wrote:
| Passkeys are instead of the password. You can still login using
| your password. This way, you don't have to keep entering your
| password if you have access to a device with a passkey and can
| access that device.
| fatfingerd wrote:
| Sure, but is that adequate? Not having people practice their
| passwords seems to be an anti-pattern for selling premium
| support in password managers, while many other apps ask with
| planned frequency.
| lxgr wrote:
| Passkeys don't (only) replace passwords - they usually also
| replace another authentication factor as well.
|
| That other factor might still be available for account
| recoveries (together with a password or recovery email etc.),
| but if either are not regularly exercised, users might forget
| them or lose access to them and not notice until they also
| lose access to their passkey(s).
|
| That said, Google's and Apple's passkey solutions themselves
| are cloud-synced (with no way to opt out), so as long as
| users of either can still access their Google or Apple
| account, they would not be totally locked out.
| teeray wrote:
| Well you just get in touch with a friendly Google customer
| support representative /s
| [deleted]
| shinycode wrote:
| And if I loose for some reason access to my phone number,
| termination of current number to create a new line with a new
| phone, I loose access to Gmail forever ?
| init2null wrote:
| Possibly. Security has made internet enabled accounts
| outright user hostile. Try helping a 70 year old guy get into
| his Gmail again. I despair over the disrespect Google and the
| other major internet corps show their tech-naive users.
|
| I've heard "I'll call them" far too often, and am perpetually
| forced to share the bad news.
| qingcharles wrote:
| I had a fire. I lost every single thing I own, except my
| landlord grabbed my phone, bless him. Otherwise I would have
| been totally stuck as all my TOTP apps are on there.
|
| Also, never lose your phone number. I can't get back into my
| Google account even though I have the username, password and
| recovery email because I can never get the SMS code.
| zb3 wrote:
| In my country my phone number is linked to my government
| issued ID so I don't need any physical properties to recover
| it (this might take some time though but for me it's still
| the best option).
| TheNewsIsHere wrote:
| > Also, never lose your phone number. I can't get back into
| my Google account even though I have the username, password
| and recovery email because I can never get the SMS code.
|
| This is an excellent point. Google seems to be uninterested
| in addressing this transparently, but despite their push for
| phishing-resistant MFA and first factor sign-in options, they
| still consider a phone number to be golden evidence.
|
| My father changed his phone number last year and never
| updated his Google account. Despite having a recovery email
| address he could access, TOTP, and printed backup codes, it
| was not enough. Google wanted to "verify it really was him"
| after a move (and IP address change) and it doesn't even
| allow a password reset to be authenticated with any other
| recovery option. Phone number or bust.
| rurp wrote:
| I have heard and read about a number of similar cases where
| people can get completely locked out of their account
| despite being able to authenticate correctly, because they
| lost access to some _other_ required resource that Google
| decided is essential. I 'm very skeptical about the utility
| of these types of security policies. I'm sure they prevent
| hacking in some cases, but they also greatly increase the
| chance of a legit user permanently losing their account
| which is a pretty freaking bad outcome for someone who has
| all of their email, messages, photos, documents and more
| stored in their Google account.
|
| Given the importance of these digital services I expect
| that refusing to provide support to users in this
| situation, as Google is well known to do, won't be legally
| tolerated at some point in the future. Unfortunately this
| won't be changing anytime soon, so the best we can do is
| inform others about the risks of relying solely on Google
| for anything important and hope people backup what they
| can.
| LegitShady wrote:
| Getting locked out of a Google account because I didn't have
| the number anymore happened to me too. Even though I had
| everything else even backup email verification, password,
| etc. Was a massive hassle.
| latchkey wrote:
| Don't tie your google account recovery to SMS. I left that
| option blank.
| nicolaslem wrote:
| All the Google accounts I had to use for work eventually
| required a phone number.
| latchkey wrote:
| Google Workspace is different than a private account,
| which is what we are talking about here.
|
| With Google Workspace an admin can reset / disable your
| 2FA, so that part is out of your hands anyway.
|
| Finally, I don't see anything in Google Workspace that
| requires a phone number. Someone can correct me if I'm
| wrong there.
| Macha wrote:
| If google thinks your login is suspicious, it will look
| for 2FA. If you don't have a phone number tied to that
| account at that time, it will insist you add one.
|
| Discord does the same.
| latchkey wrote:
| That is not true. There is no requirement for a phone
| number.
| Macha wrote:
| https://www.reddit.com/r/GMail/comments/zegzh6/to_help_ke
| ep_...
|
| I'm not the only one to have encountered this
| latchkey wrote:
| Again, that's not a requirement for a phone number.
|
| That's asking a user to verify themselves with a
| _provided number_.
|
| Likely because the user doesn't have anything else set up
| for 2FA.
| Macha wrote:
| This is not true. It will ask for a provided number if
| you've already provided one, but if you've never provided
| one, it'll ask for any number and treat that as the
| provided number for future reference.
| latchkey wrote:
| > This is not true.
|
| What is not true?
|
| > if you've never provided one
|
| I started this thread off with don't provide a number.
|
| Again, set up a alternate 2FA with them and you won't
| have to deal with a phone number at all.
|
| > and treat that as the provided number for future
| reference
|
| Even if they did add it in, you could remove it later.
| GeoAtreides wrote:
| The solution would be to have a separate phone and phone
| number used solely for authenticating. It will never leave
| home, and never be used except to authenticate. Still
| vulnerable to home fire, however.
| qingcharles wrote:
| And what do you do when you go abroad and a web site says
| "Oh, looks like you are logging in from a new location -
| please check your SMS for a PIN now" :(
| Macha wrote:
| Have had to recover from 0 pretty similarly. My backup
| approach basically started with the fact that I knew the
| password to a cloud storage account that I had uploaded a
| keepass vault to, and that keepass vault had the password to
| my primary backup provider. In a full no passwords world, I
| would have had no chance to do so.
| qingcharles wrote:
| Lucky break there! It makes you re-work your entire
| security setup though, I tell you. I'm a bit smarter now
| for having that happen to me.
| crooked-v wrote:
| > never lose your phone number
|
| The forced SMS 2FA that banks and credit card companies have
| started implementing infuriates me for exactly this reason.
| hansvm wrote:
| Especially when they migrate previously password-only
| accounts to requiring what they think your phone number
| might be, and especially given that it costs under $15 to
| borrow somebody's phone number for the day without their
| knowledge.
| qingcharles wrote:
| I need to find one of these services so I can borrow my
| old phone number for a few minutes to get back into my
| Google account before it is erased at the end of the year
| in Google's oncoming purge.
| NorwegianDude wrote:
| You get a new device, load your keys from the cloud and use the
| same screen lock key to decrypt the downloaded keys.
|
| Even if it's passwordless by default doesn't mean there is no
| passwords for recovery.
| segmondy wrote:
| I don't know how Google solved this, but it's an old solution.
| Shamir secret sharing. You break apart your keys into M pieces,
| where you need N pieces to reconstruct the key, so let's say
| 3/8. Then you need 3 pieces out of the 8 pieces it's broken
| into to recover your key. You take each of those 8 pieces and
| give to trusted sources. When you need to reconstruct your key,
| you have at least 3 of those give you the key and you recover.
|
| How does this look in implementation. When I Implemented this
| in multipasskey (YC demo). It would ask you to select contacts
| you trusted. Then it would send the sharded parts of the key in
| the background to them. If you need to recover, you make a
| request to them. It would reconstruct your device key when you
| got enough pieces. Once you have your device key, it would
| download your encrypted backup of keys from the remove server
| and you are back as new.
|
| I called my project multipasskey in 2017/2018 and applied to YC
| with a working demo and they said nope. I'm going to assume
| that I sucked at selling it. ;-)
| bojo wrote:
| I had the same idea about a decade ago but never bothered to
| try to implement it. I felt like it would have suffered from
| the same problem all other technologies have in security:
| overly complex user interactions. The concept makes sense,
| but getting N other people to commit is overhead the average
| user probably doesn't want to deal with.
| segmondy wrote:
| So I preferred the idea of regular folks for backup, for
| security reasons. I thought of the idea of professional
| users like say your bank or 3rd party. The issue is that
| it's far easier for the govt to subpoena those pro 3rd
| parties and recover your key. Whereas, they would have to
| know which of your friends you used for key recovery to be
| able to do that. The idea was to make it tough for a
| bad/powerful actor to steal your key. Of course, the
| challenge is that a non social person would need friends or
| to depend on ISPs, banks (pro 3rd party providers). My goal
| besides security when building this project was to break
| the chain of 3rd party auths (Google, MS, Github, etc) :-(.
| They use their auth as a way to lock folks into their
| ecosystem and if you offend them in anyway, you could lose
| access to everything. Offend Google on adsense and lose
| your personal photos/email. Offend Amazon on sales and lose
| your prime streaming/AWS access. Hopefully as the idea
| picks up, the monopolistic corps can be tackled again to
| remove such power.
| compiler-guy wrote:
| Now there is a technically savvy solution that is a technical
| tour-de-force.
|
| Very very cool.
|
| But also completely unrealistic for the average person to
| use.
| segmondy wrote:
| How? The usage was very easy. You select a contact and add
| them as your recovery contact (by selecting contact from
| your contact list) The system adds the key in the
| background. If they don't have the app, the app asks you to
| tell them to install the app (viral growth?). The users
| didn't need to know any thing technical. But install app,
| and click yes/no like they do with a 2FA app.
| doublerabbit wrote:
| I don't have eight people, what then?
| drdaeman wrote:
| You use different numbers, for example 3/5 or 2/3.
|
| You have to have at least 3 peers, though (IIRC, 2/3 is
| the minimum split possible that would provide fault
| tolerance).
| jsperx wrote:
| I think the challenge is more coordinating the 8 people
| who will be a trusted part of your life long-term. Also
| they'd have to be sure to keep their fragments of the key
| intact through replacing devices, etc, no? Seems like
| just keeping a Yubikey in a safe deposit box would be
| simpler.
| wutwutwat wrote:
| Added bonus you can't die unless someone locates each piece
| and destroys them all
| progmetaldev wrote:
| Sounds like a great idea. Sometimes it's hard to be so in
| tune with the technology, and also be the salesperson!
| wutwutwat wrote:
| I'm not in the crypto world to know why this is the way it
| is, but if you only need 3 pieces out of the 8 to reconstruct
| the key, why split it into 8? Is it to have a larger pool
| should you need it/higher odds of being able to gather 3
| should some pieces be lost?
| betaby wrote:
| You don't.
| hooverd wrote:
| That's the great part.
| [deleted]
| skarra wrote:
| Passkeys are a new technology and everyone - including users,
| service providers, and organizations - will take time to learn
| and adapt. In this interim period the recommended approach is
| to provide passkeys as an alternative to whatever is already
| offered. This is the approach that Google and many other
| service providers are taking.
|
| That said, you are bringing up the right questions on the
| general topic of account recovery that everyone should be
| asking even without passkeys: "How would I login if I forget my
| password / lose access to my password manager / lose my second
| factor devices" and have a plan. Introduction and adoption of
| passkeys do not completely eliminate the need for thinking
| about your account recovery situation.
|
| However, there is one special case where using passkeys is
| actually better for account recovery. If you create passkeys
| for your Google account on an Apple device with iCloud
| keychain, the passkeys are synched to your iCloud, so now even
| if you lose all your devices because your house burned down, as
| long as you have access to your iCloud account, you can just
| get all the passkeys for your Google accounts(and other
| websites).
|
| Now, you may ask: 'what if I lose access to my Apple iCloud
| account" -> that's a fair question! Which is why I said Account
| Recovery concerns do not completely go away - but they can be
| significantly reduced with passkeys in many cases.
| vorpalhex wrote:
| Rearranging deck chairs on the titantic.
|
| This whole scheme depends on either users being savvy enough
| to do vault backups or depending on service providers being
| functional.
|
| Both are quite doomed.
|
| Users have a path for passwords - they can write them down on
| paper and keep them with their important things. This tends
| to work for most folks.
|
| The backup story for passkeys is horrible. There is no path
| for my elderly relatives who don't use cloud services.
|
| Until that is fixed, passkeys will never replace passwords.
|
| Don't forget password sharing! That is a whole screwed up
| story with passkeys too.
| skarra wrote:
| Passkeys represent the cumulative wisdom and experience
| (and compromises!) of the whole industry on how to keep
| users safe online. Appreciate your opinions that these
| efforts are doomed. It is safe to say, "We'll surely find
| out!"
| vorpalhex wrote:
| "The Industry" also has interests like making password
| sharing impossible, uniquely tracking users and _doesn't
| care_ if users get locked out.
|
| The industry does not put users first. It puts it's own
| risk reduction first.
| skarra wrote:
| Did you know that Apple allows sharing passkeys via
| Airdrop?
| kiwijamo wrote:
| Doesn't that give access to everything you've signed in
| using that passkey? Rather than e.g. Sharing the password
| for the family Netflix account.
| jasonjayr wrote:
| How can a user, right now, take control + ownership of
| backing up their own pass keys, without iCloud or Google?
|
| This is a privilege I currently enjoy right now, and one I am
| not really eager to give up.
| blitzar wrote:
| I use passkeys everywhere I find them. I do not take
| control or ownership of backing up - instead I have
| alternative 2fa or hardware key authentication with all
| those accounts.
|
| For every account I have a hardware key for, there are 3
| hardware keys associated with that account - 2 on-site, 1
| off-site.
| rssoconnor wrote:
| How do you register your off-site hardware key. Did you
| have to go retrieve it each time you wanted to make an
| account?
|
| I suppose every time one makes an account one can
| register the two on-site keys, and then rotate one of
| your on-site key to off-site and take the off-site key
| home with you, and then finally register it.
|
| Maybe I should get a third key...
| blitzar wrote:
| I think you answered your own question! The three key is
| optimum for ease of rotating (or so you can carry one on
| person) - but if your house burns down with your phone in
| it - you will lose anything set up since your last
| offsite rotation.
|
| Sounds paranoid / crazy - but I have 0 anxiety about
| being locked out of an account that matters.
| jasonjayr wrote:
| Which hardware keys are you using? And have you found any
| difficulty in adding multiple keys to a web site?
| blitzar wrote:
| Yubikey keys - zero difficulty adding multiple - if a
| site doesn't allow multiple I wouldn't lock my account
| down to a single point of failure. All the big players
| seem to offer it, and I can not recall any that didn't.
| Google in the "advanced protection" days forced you to
| have more than 2 keys for this reason.
|
| By count of sites, most sites don't appear to take
| security _that_ seriously so anything more than a
| password is off the cards, but the big ones - the ones
| that actually matter; email, cloud, etc. should all be
| able to be secured.
| shepherdjerred wrote:
| I use 1Password [0] for syncing passkeys, and it works
| quite well. I would imagine other password managers are
| building similar features.
|
| [0]: https://support.1password.com/save-use-passkeys/
| skarra wrote:
| Password managers like Dashlane and 1Password have
| announced support for storing and synching passkeys. As
| passkeys becomes more popular I expect more providers to
| step up as well.
|
| Ecosystem lockin is not how we make a new technology like
| this successful. And all players in the game understand
| that.
| jasonjayr wrote:
| Appreciate the response. And I wish this message was
| front and center. The Attestation feature is what worries
| me, when, say, the bank turns it on for a few 'blessed'
| providers, or mandate a hardware implementation.
|
| Watching
| https://github.com/keepassxreboot/keepassxc/issues/1870
| with baited breath... :)
| awegio wrote:
| It depends on your web browser. Just see what happens here
| https://webauthn.io/
|
| Firefox on Desktop tells me to "touch my security key". Not
| sure how that works. Firefox Android gives me a few
| hardware options to store my passkey to. Chrome Desktop
| asks me to enable Bluetooth. Chrome Android asks which
| Google Account to use.
| drdaeman wrote:
| All those issues were obvious from the day zero, and raised
| multiple times by many people. They're deliberately ignored
| by the stakeholders.
|
| They strongly want to lock you in to their own authentication
| platforms (iCloud Keychain, Windows Hello, 1Password*),
| that's why they don't want to address this.
|
| It's impossible they're not aware about those issues. Anyone
| with a brain and some technical expertise would come up with
| those questions in an evening or two, and Passkeys were
| worked on for months. To best of my awareness, there is no
| official acknowledgement (support replies "no, you can't do
| this" doesn't count, that's just restating facts, not
| acknowledging an issue).
|
| *) Ok, 1Password says they're all about user freedoms and
| that it's up to user to decide where they store their
| passkeys - but that's what they say, not what they do. What
| they do is indistinguishable from Apple and Microsoft.
| jesseendahl wrote:
| You can recover access to your iCloud Keychain even if
| you've lost 100% of your devices.
|
| See the section titled "Recovery security" in this article:
|
| https://support.apple.com/en-us/102195
|
| Relevant excerpt for those too lazy to click through:
|
| "However, it's also important that passkeys be recoverable
| even in the event that all associated devices are lost.
| Passkeys can be recovered through iCloud keychain escrow,
| which is also protected against brute-force attacks, even
| by Apple."
| frabcus wrote:
| To add, it is pretty poor there is no FAQ linked to from that
| post to answer basic non-technical questions as to how this is
| intended to be used.
|
| I _assume_ as a technical person, the answer is I should have a
| backup device with a friend and /or store my passkeys somehow
| on my Apple or Microsoft or password manager account as well.
|
| But it needs more explanation in detail from Google!
| dotancohen wrote:
| So now that "friend" has access to your account? How is that
| more secure than my 32 random character password I store in
| an encrypted Keepass database that I back up offline?
| [deleted]
| evanjrowley wrote:
| You have a valid concern, but I'm curious how many
| sufficiently non-technical users would be reading Google's
| blog. Practically speaking, it could be a moot point.
| skarra wrote:
| You can try this:
| https://support.google.com/accounts/answer/13548313?hl=en,
| this help center page is linked to from various parts of the
| product experience for regular users to get a better idea
| about passkeys if they are interseted.
| growse wrote:
| You go through.... account recovery?
|
| Like if you lose your password today?
| lopis wrote:
| Ah right, account recovery. The one that tells me the only
| way to sign in to my old Google account is to use a phone
| that no longer exists.
| jasonjayr wrote:
| or to fax/email/send in government identity documents.
| lxgr wrote:
| Despite what many companies seem to believe, looking at
| _a copy of_ somebody 's identification _presented
| remotely_ documents does not constitute identity
| verification.
|
| Photo ID is (relatively) secure in exactly one use case:
| Verifying that a person standing in front of you is who
| they claim to be. Everything else is inane pseudo-
| security.
| tshaddox wrote:
| What's the standard then? Should it be possible to recover
| your account without possessing any evidence whatsoever
| that you are the person you say you are?
| kube-system wrote:
| Other businesses have humans on staff which will verify
| your identity documents. Google simply chooses not to do
| this, because it is expensive, and their "users" are not
| their customers.
| lxgr wrote:
| That is not without risk either:
|
| Many more people have a copy of my passport than have
| access to my Yubikey or recovery phone number.
| threatofrain wrote:
| Right, then you can just pay for Google's rather
| affordable non-free business version. _Then_ you 'll get
| reasonable support, well-reputed support.
| px43 wrote:
| They have offered this since 2017, in response to the
| Podesta email hack. It's free, but it's not the default,
| because traveling to a Google site is prohibitively
| expensive for the vast majority of their users.
|
| https://landing.google.com/advancedprotection
| kube-system wrote:
| Is there something there that explains how the recovery
| process is different? The only thing I see in the FAQ is
| somewhere that they link to the normal account recovery
| page, and say that you'd have to order another hardware
| token.
| soulofmischief wrote:
| I'm willing to bet Google already has a frighteningly
| accurate ability to determine whether I am associated
| with or own a particular account.
| Macha wrote:
| I've been locked permanently out of a (thankfully
| tertiary) Gmail account because their ML didn't like that
| I logged in from my new house. The option was to accept a
| push notification to a long dead and wiped phone.
| TheNewsIsHere wrote:
| Their state handling for the push notification based MFA
| factors is _atrocious_. I have had to "re-delete" a long
| wiped phone (or two) multiple times from more than one
| account. It seems to have finally stuck in the past year,
| but I'm suspicious that one day it could bite me in the
| ass.
| shinycode wrote:
| If you travel in an other country and loose your phone or
| the phone gets stolen. How can you log into Gmail from
| anything else if you need access to travel or anything
| else ? Like receiving a confirmation of identity by email
| from the bank or another service ?
| mr_mitm wrote:
| You can't, that's the point.
| Eumenes wrote:
| Google has notoriously horrible customer service, or none
| at all ... A Google Domains issue took me months to
| resolve, I couldn't contact a human.
| throwawayqqq11 wrote:
| And then? get asked for a unique pw that you havent typed for
| ages or a duplicate pw that you use for everything?
| ses1984 wrote:
| If you can recover an account without the passkey, how much
| security is it really adding?
| toomuchtodo wrote:
| Depends on the recovery mechanism. Providing a government
| credential with a live selfie is the gold standard. If a
| company doesn't support that, they're being cheap at the
| cost of security (you can perform such an identity proof
| for ~$1-2/per successful proof through a vendor like Stripe
| Identity or ID.me).
|
| Passkeys solves for digital identity compromise (credential
| theft or stuffing/spraying), but you must rely on other
| mechanisms (such as a I mention above) if you want to
| elevate identity assurance higher in the event of
| credential loss.
|
| (consumer IAM is a component of my work at a fintech;
| auth/creds security, passkey rollout, high identity
| confidence when an account is recovered, etc)
| grotorea wrote:
| It at least avoids the user being phished or being
| compromised by reusing passwords.
|
| But it seems in this case the account recovery is just
| using the password so the passkey is mostly convenience and
| maybe Google trying to move things away from passwords more
| than a complete change.
| echelon wrote:
| > maybe Google trying to move things away from passwords
| more than a complete change
|
| Google wants to be a gateway to everything else you do.
|
| The next step is to get other platforms to accept Google
| passwordless auth.
| kube-system wrote:
| That depends entirely on how rigorous the recovery process
| is.
| toomuchtodo wrote:
| Passkeys are typically synced to cloud storage.
| [deleted]
| grotorea wrote:
| That does seem circular in Google's case, no? _What_ cloud
| storage?
| skarra wrote:
| If you are on Apple ecosystem, iCloud can sync. Other
| password managers like 1Password can also be used to store
| your passkeys. If none of the above, you can always set up
| a physical security key and leave it at home.
|
| IMO if you're reading hacker news, you're fully capable of
| setting one up and leaving it in a safe locale for
| recovery.
| toomuchtodo wrote:
| Google Password Manager.
|
| https://developers.google.com/identity/passkeys/supported-
| en...
| soco wrote:
| Which I cannot access because I lost my passkey device.
| beej71 wrote:
| Will I still have access to that if Google decides
| randomly to lock me out of my account?
| rkagerer wrote:
| Given their awesome track record, Google is the LAST
| company I'd trust not to shut down or lock me out of such
| a critical tool.
| sneak wrote:
| Not just typically - on iOS, you cannot use them at all
| without iCloud enabled.
| fh9302 wrote:
| On iOS you can use third party software to manage passkeys,
| there is no inherent cloud requirement.
| sneak wrote:
| Can you? If so, this is great news.
|
| What apps support this?
| fh9302 wrote:
| Third-party passkey providers got added with iOS 17. I
| don't know which apps apart from 1Password support it yet
| but the API is there.
| gruez wrote:
| Source?
|
| >Note: To use passkeys, iOS 16, iPadOS 16, macOS 13, or
| tvOS 16 (or later) is required. iCloud Keychain and two-
| factor authentication must also be turned on.
|
| https://support.apple.com/guide/iphone/use-passkeys-to-
| sign-...
| fh9302 wrote:
| Third-party passkey providers got added with iOS 17.
|
| https://www.corbado.com/blog/apple-passkeys-integration
| fbdab103 wrote:
| Perfect! I keep iCloud off, so this is one "improvement" I
| can continue to sidestep for a while.
| jkaplowitz wrote:
| I think you'll still need a password on your account for cases
| where no passkey is available, and possibly for other scenarios
| of heightened fraud risk. That's why the setting they're
| describing in the blog post is named "Skip password when
| possible".
|
| Disclaimer: although I worked for Google many years ago in a
| role entirely unrelated to Google account authentication, I
| have no inside info on this announcement, could be wrong about
| what I say in the first sentence of this comment, and am not
| speaking for Google here.
| goosedragons wrote:
| I think there's going to be an issue with people forgetting
| passwords they lasted used 5 years ago. Recovery needs to be
| much better thought out.
| jkaplowitz wrote:
| I agree that recovery is an important question. Maybe they
| will make sure to prompt for a password at least every N
| months? I have no idea what their answer for this may be,
| but they probably have one.
| vdelitz wrote:
| I also think that for sign-ups you still need a password for
| a while (simply as a fallback)
| skarra wrote:
| You're spot on. And I work on the Google authentication team
| right now :)
| kseifried wrote:
| I might regret this but I have an (almost finished) draft of a
| paper on Passkeys, it is available, with comments enabled (which
| will be turned off if vandalism becomes a problem) at:
|
| https://docs.google.com/document/d/1eBjQDWkbqXJSL4GRrAdTUcAx...
|
| TL;DR:
|
| ============
|
| Major insights in this paper:
|
| Passkeys level up security, and while Passkeys make some
| tradeoffs concerning security vs. usability, they do not
| introduce any new attacks and make many existing attacks much
| harder or impossible (e.g. brute forcing attacks or credential
| stuffing) Passkeys will bypass the hurdle of getting people to
| start using password managers, and will likely result in the
| widespread use of biometrics to secure Passkeys Passkeys can
| potentially make account sharing harder once attestation is
| supported, something a lot of service vendors are in favor of.
| Passkeys are also easier to deploy and reliable due to optional
| device synchronization, which should reduce the need for account
| recoveries and lower support costs Passkey client support in both
| software and secure hardware tokens is widespread and available
| now on most platforms, browsers and most third-party password
| managers Passkeys are being deployed by major vendors (e.g.
| Google https://blog.google/technology/safety-security/passkeys-
| defa...)
|
| ============
|
| Conclusion:
|
| No new significant risks or attacks are introduced from the
| threat model perspective. From a usability and reliability
| perspective, Passkeys are infinitely better than passwords.
| Finally, from a support perspective, chances are that if you
| currently use a system to manage your passwords, it already has
| Passkey support. For high-security applications, you can also
| choose to use your hardware token.
|
| Web applications and websites are becoming increasingly critical
| to everyday life (banking, healthcare, education, shopping,
| etc.). We must improve security across the board and get rid of
| old and insecure things like usernames and passwords. The world
| has also changed, and virtually everyone has a smartphone,
| something unimaginable even ten years ago, let alone twenty.
|
| Simply put, in every situation where you use a password, you
| should upgrade to a Passkey if possible.
| mission_failed wrote:
| Most accounts with passwords have the fail-safe method of 'prove
| my identity to company, they reset'. I.e if you can't remember
| your bank password, there are paths for the bank to reset for
| you.
|
| Anything that Google controls you have absolutely no way to get
| in contact to resolve issues. This is _already_ a problem with
| all of their products. Locking all of your access behind a Google
| controlled door is just setting yourself up for a future
| nightmare.
| theyknowitsxmas wrote:
| It's stupid these are required just to enable TOTP.
| Bluecobra wrote:
| So what happens when I die and my spouse or next of kin has to
| deal with this stuff? As the executor of my father's estate, he
| kept a physical password book that was instrumental in making it
| easy for me to settle his affairs.
| rawgabbit wrote:
| While I believe this is a step in the right direction. I have
| read too many horror stories of people who were locked out of
| their Google and iCloud accounts with no real possibility of
| getting back in.
|
| I don't think I am alone in thinking I am on borrowed time.
| Someday, probably due to my own fault I will be locked out of
| Google and my digital life will be over.
|
| If a private company can offer a similar login method like
| login.gov and let me talk to a real person when I am locked out
| like the USPS, I will be screaming shut up and take my money.
| verytrivial wrote:
| Disaster recovery. This is 100% my biggest worry with 2FA/MFA.
| I also think this is one of the reasons stuff like PGP never
| took off (don't @ me regarding perfect forward secrecy): the
| problem has always been managing some little, precious _thing_
| and the ramifications of what happens if it put beyond use or
| is used by some bad actor.
| fmobus wrote:
| Gopass is my current solution. Easy to sync and move around
| (it's just git), supports OTP generation, everything is
| encrypted by GPG. I have at least three devices in separate
| locations with it, so my DR is covered (and I exercise it
| frequently).
| rkagerer wrote:
| There are some Google Authenticator replacements that have an
| export function (eg. Authenticator+ on Android, although I'm
| not sure if it's still maintained). You give up a bit of
| [theoretical] security for a whole lot of DR insurance.
| llui85 wrote:
| Google Authenticator now has an "Export QR code" function
| that allows exporting the 2FA secrets.
| eep_social wrote:
| FYI the authenticator app itself has this now.
| syntaxing wrote:
| 100% agreed. I'm excited about the passwordless future but one
| unexplained ban from them and it's like losing your physical
| wallet.
| compiler-guy wrote:
| "You might get locked out of your account" is the updated
| version of the old "Your hard drive will crash."
|
| It isn't a matter of if, it's just a matter of when. Backups
| and a thorough disaster recovery plan is absolutely mandatory
| for anyone who cares about their data. Some company is going to
| mess something up due to no fault of your own. It is
| inevitable.
|
| Unfortunately, there aren't good disaster recovery options for
| some aspects of lost accounts, but having multiple accounts and
| avoiding single-points of failure help some.
| Gibbon1 wrote:
| My thought on this is to involve notaries. As in you can get
| a notorised account. And if something goes wrong you can get
| a notary in the loop and by law the providers have to fix
| what ever has gone wrong or they are liable for actual and
| statutory damages.
| leotravis10 wrote:
| Especially for normal and older folks and Google's history of
| very non-existent support. Not to mention that passkeys is a
| flawed system as well. [1] [2]
|
| [1]
| https://mastodon.laurenweinstein.org/@lauren/111103819626952...
| [2]
| https://mastodon.laurenweinstein.org/@lauren/111211366080459...
| gowld wrote:
| What is the flaw?
| gcr wrote:
| AFAICT, the flaw is that passkeys are tied to device
| security. If I steal a naive person's phone at the bar, and
| if I can guess that their PIN is 1234, then I can get into
| their Google account.
|
| The criticism is based on the idea that most non-techie
| folks are unlikely to use a strong PIN and are unlikely to
| set up strong biometrics. There's a related criticism about
| malware being able to steal passkeys on PC-based systems.
| jackson1442 wrote:
| What are the odds that someone with a passcode 1234 is 1/
| already signed into Google on their phone or 2/ has their
| Google password already saved in the device password
| manager (since it asks you to save it every time you sign
| in) which is also protected by the device pin?
|
| At least in this case the thief has to steal the physical
| phone instead of guessing "password123" on the google
| signin prompt from the comfort of their home.
|
| Also- how many non-techy people do you know that avoid
| using on-device biometrics? On my end, the number is
| approximately 0.
| chownie wrote:
| > What are the odds that someone with a passcode 1234 is
| 1/ already signed into Google on their phone
|
| ...very high? I don't understand how this is unlikely,
| pretty much every phone owner with a google account is
| signed into that account on their phone.
| joshspankit wrote:
| Don't try to argue that on-device biometrics are a
| foolproof solution to this. Even at it's best you can
| unlock a device from a sleeping (or drunk or naive) user
| which just brings us back to the same issue: already
| being logged in to a passkey service.
| charcircuit wrote:
| If someone steals my phone and guesses my pin they
| already have access to my Google account because I'm
| signed in. To look at my email they just have to click on
| the gmail app. This "flaw" exists regrardless of password
| or passkeys
| true_religion wrote:
| Won't most people be logged into their Google account
| anyways? So if you steal their phone, and guess their PIN
| then you can just use the already logged in account.
|
| What does this change?
| netsec_burn wrote:
| This is an interesting direction. It's worth noting that
| biometrics, like fingerprints or facial recognition, aren't
| really 'secrets'. They can be observed or leveraged without a
| users knowledge or consent, and in many ways function more like a
| username than a password.
| csjh wrote:
| Don't they need both physical access to device +
| fingerprints/face?
| px43 wrote:
| Yes.
| the_snooze wrote:
| Passkeys really aren't biometric authentication per se. If you
| use TouchID, for instance, Google isn't authenticating you
| based on your fingerprint. Rather, the fingerprint merely
| unlocks the cryptographic key pair that's then used to
| authenticate you.
|
| I use Yubico Security Keys myself as passkeys. They're
| protected by a 6-digit PIN. But that PIN is strictly local to
| the device, meant to prevent snoops from logging in just by
| having physical access to the device (the keys get blown away
| after 10 consecutive unsuccessful PIN attempts). When I enter
| the PIN, the keys unlock, and it's those keys that get me into
| my Google account.
| kube-system wrote:
| Passwords are also not entirely secret, as they're _shared_ by
| definition. Passkeys use public-private key crypto, which is
| more secure in every way.
| iand wrote:
| "To use passkeys, you just use a fingerprint, face scan or pin to
| unlock your device, and they are 40% faster than passwords -- and
| rely on a type of cryptography that makes them more secure. "
|
| Who wrote this sentence? It's just a mess.
| TheRealPomax wrote:
| also, "ah yes, a several digit pin, famously more secure than a
| same-length password that adds even as little as letters".
| progbits wrote:
| PIN for secure module with throttling and max wrong attempt
| count is indeed safer than a password you can brute force
| offline.
| andrewstuart2 wrote:
| Brute forcing offline kinda only works if you have a stolen
| hash or artifact like that. For a service like Google, they
| definitely have rate limits on password attempts.
|
| I'm not saying I prefer either one here, just that password
| authentication doesn't automatically mean you can brute
| force offline.
| postalrat wrote:
| The real key is stored in a chip. Your pin unlocks the
| real key. The chip has hardware to rate limit pin
| attempts.
|
| These types of chips tend to have many layers of physical
| security to protect the real key.
| wrs wrote:
| You have to possess the device _and_ the PIN, so yes, it is
| quite a bit more secure.
| Macha wrote:
| The point is more so that the pin unlocks a key on your local
| device and that key is much stronger than the password the
| typical user would select. Plus it is site specific in a way
| that your typical user does not do with passwords.
|
| So it's making a system weaker against offline attacks if
| someone steals your hardware in exchange for making it
| stronger against phishing. This is probably the correct
| tradeoff for most people.
| avianlyric wrote:
| A PIN associated with a specific device that been
| cryptographically linked to your account. So while a seven
| digit PIN is easier to guess than a password, the physical
| device is much harder to steal over the internet. It's
| defacto 2FA authentication.
| wkat4242 wrote:
| A pin is pretty safe when it unlocks a hardware token that
| limits the amount of attempts.
|
| It's basically like a chip & pin bank card.
| kube-system wrote:
| Yes, a several digit pin that unlocks a long private key is
| more secure than a shared secret with eight characters on its
| own.
| JaneLovesDotNet wrote:
| Correct me if I'm wrong but isn't it fair to say that passkeys
| secured on your phone are more secure than 1FA (password) but
| less secure than "traditional" 2FA? Passkey 2FA:
| unlock your phone and the passkey on your phone can log you in.
| Traditional 2FA: remember a password AND unlock your phone (where
| your TOTP is stored) and you can login
|
| If I were to rate all 3 methods on a scale of 1 to 10, for
| convenience and security, I'd say: Method
| Convenience Security Password only: 4/10
| 2/10 Passkey 2FA: 9/10 8/10
| Traditional 2FA: 6/10 9/10
|
| Fair?
| px43 wrote:
| No, if you break into a site using passkeys, it gives you
| literally zero information that can be used to authenticate as
| any of the users. Think about the prevalence of data breaches
| in the past decade, and the sharp rise in the effectiveness of
| password stuffing, and think about why this change might be a
| good idea.
|
| Also even with traditional 2FA, TOTP can be phished. See
| https://github.com/kgretzky/evilginx2
|
| WebAuthn almost entirely eliminates phishing risk (at least
| with respect to credential harvesting), and Passkeys are a
| really nice, clean UX for using WebAuthn.
| the_snooze wrote:
| >No, if you break into a site using passkeys, it gives you
| literally zero information that can be used to authenticate
| as any of the users. Think about the prevalence of data
| breaches in the past decade, and the sharp rise in the
| effectiveness of password stuffing, and think about why this
| change might be a good idea.
|
| An implication of that is passkeys let you use the same
| authenticators across multiple services safely. Instead of
| keeping track of unique passwords across all those services
| (or worse, reusing passwords), you can just have a passkey-
| registered phone and one or two Yubikeys for
| backups/convenience. You'd be a _very_ hard target for
| account compromise. That setup is highly phishing-resistant
| and immune to credential-stuffing, without the cognitive load
| of passwords.
| orev wrote:
| Nobody should be using a remembered password anymore. Most
| people are likely using the phone for both the password and the
| MFA code.
| [deleted]
| vdelitz wrote:
| Agree
| doublerabbit wrote:
| > Nobody should be using a remembered password anymore.
|
| Nobody is a strong number, why?
|
| I don't want to use biometrics for logging in to my SSH
| terminal. I dislike having to use my phone for authentication
| methods.
|
| I go many places without my phone. Even tempted to gon on
| holiday without it. Maybe I'm just one of the few who
| actually enjoys turning it off when coding, developing or
| whatever.
| JaneLovesDotNet wrote:
| Right, in which case passkeys would be equally secure. But if
| you DO memorize the password (for example for your most
| sensitive account), then it feels like traditional 2FA is
| more secure.
|
| That being said passkeys win if you also take convenience
| into account. I've updated my original comment with
| convenience scores to reflect that.
| forward1 wrote:
| Passwordless authentication > hardware-backed MFA > TOTP/HOTP
| MFA > SMS MFA > no MFA
|
| The reason being is the secret used to authenticate you is non-
| portable (since it's based on asymmetric crypto, it doesn't
| need to be shared). On the other hand, portable credentials,
| like TOTP/HOTP code AND passwords are responsible for almost
| all compromise today.
|
| Bearer token based authentication will always be inferior to
| FIDO/U2F - it's not even the same ballgame.
| TheBlight wrote:
| Probably a stupid question but why can't photos of my face be
| used to defeat this?
| adzm wrote:
| It would have to be scanned by a device that has already logged
| in, basically.
| kube-system wrote:
| The biometrics aren't authenticating you. They only unlock your
| phone, which stores the private key used to authenticate you.
| stalfosknight wrote:
| Also a photo of your face wouldn't be sufficient for FaceID.
| TheBlight wrote:
| I see. So really this is public/private key authentication
| and the face/pin/fingerprint etc is just the typical device
| unlock stuff.
| grotorea wrote:
| Yes, that's mostly it.
| ezfe wrote:
| This has nothing to do with your face is the simple answer.
|
| If your platform uses face scanning, you can read how it
| protects you from that.
|
| For FaceID on iOS, it uses additional sensors beyond just a
| camera.
| PreInternet01 wrote:
| G: Here's a _cool_ new security feature!
|
| HN: Yeah, but what if _disaster scenario_?
|
| A1: If you're authenticating to Google because your $DAYJOB
| mandates it, contact your Enterprise Administrator. As part of
| their multi-gazillion deal with the dark side, I'm sure there is
| some kind of support for a recovery mechanism, and if there
| isn't: _yeah_ paid holiday until they figure it out!
|
| A2: If you rely on Google for personal-slash-small-business
| reasons, please refer to the previous writing on the wall, and
| accept that _all_ is probably lost...
| Macha wrote:
| I mean, A2 is a problem. I'd wager that more people are
| selecting how to manage their personal accounts than selecting
| how to manage accounts for an enterprise.
| [deleted]
| jval43 wrote:
| Never. You can pry my passwords from my cold, dead hands.
| 0cf8612b2e1e wrote:
| Entirely this. I do not trust devices to always be working or
| on my person. I will only use this if I can generate an
| offline, perfect fidelity backup of my codes.
|
| "But it's safe in the Google/Apple/Microsoft cloud" is not an
| acceptable answer.
| grotorea wrote:
| Someday, we will have brain reading technology to extract
| information from a newly dead brain, like we have to extract it
| from a RAM that was just turned off
| https://en.wikipedia.org/wiki/Cold_boot_attack
| tempest_ wrote:
| Lol just saw the creator I assume.
| jawns wrote:
| Coincidentally, we can also pry fingerprints from your cold,
| dead hands.
| leotravis10 wrote:
| Lauren Weinstein is sounding the alarm on passkeys which is
| flawed and that it would make a huge headache for a lot of people
| especilly normal folks.
| https://mastodon.laurenweinstein.org/@lauren/111103819626952...
| https://mastodon.laurenweinstein.org/@lauren/111211366080459...
| gowld wrote:
| Does he explain the flaw anywhere?
|
| He says it's "easy to find" but apaprently he can't find it.
| https://mastodon.laurenweinstein.org/@lauren/111211489395997...
|
| Why is "weak device password" a reason to avoid passkeys, when
| those users presumably have weak service passwords as well?
| panarky wrote:
| It seems like his argument is that putting access to valuable
| accounts on your phone is a bad practice, because if your
| phone is stolen at the club after the thief watched you enter
| your code, then the thief can get at your banking, brokerage,
| crypto, password manager, etc.
|
| But that argument doesn't address how passkeys somehow make
| that worse.
|
| Sure, if you don't want your valuable stuff stolen, don't put
| it on your phone. But that's a problem whether you use
| passkeys or passwords or passwordless links sent to your
| email or SMS.
| passkeyspoor wrote:
| The point is that the phone with a crappy 4 digit pin can
| be used to authenticate everything on every device the user
| owns that uses passkeys. It's a one stop shop of failure.
| donmcronald wrote:
| It's not about security. It's about having a system for digital
| signatures that acts against the interests of the user.
| crote wrote:
| Yup! I've had similar complaints for years now.
|
| Modulo the whole privacy/vendor lockin issue, passkeys are not
| a terrible alternative to people without 2FA reusing the same
| basic password on every single website.
|
| However, when you actually rely on it to _secure things_ , it
| quickly becomes a massive nightmare - made even worse by it
| being treated as equivalent to password+2FA.
| leotravis10 wrote:
| Coupled with Google's very shaky support track record and you
| have a very dangerous combination. This will surely get ugly.
| jesseendahl wrote:
| > made even worse by it being treated as equivalent to
| password+2FA.
|
| passkeys are _significantly_ more secure than the most
| widely-used /most popular forms of 2FA, because the most
| popular forms of 2FA are TOTP and SMS, and both are subject
| to phishing attacks. A passkey alone is much more secure than
| the vast majority of password + 2FA combinations.
|
| The only thing stronger than a passkey standing alone is a
| Security Key, but Security Keys come with a _lot_ of
| usability downsides that can easily bite the average user,
| including:
|
| - inconvenience: you have to remember to carry it around with
| you everywhere (and not lose it!)
|
| - recoverability: you're completely screwed if you lose it
| and don't have extras that you already previously added to
| your accounts. (this also means that you need to buy at least
| two security keys to have a _decent_ recovery story.)
|
| - rotation (have to log in to every single service, one by
| one, to re-add new key if you change keys)
|
| And if you really want the extra security that a Security Key
| provides, you can use a Security Key as a passkey.
| k8svet wrote:
| Oh I'm seething. Screw google, so god damn much.
|
| They've been accidentally enabling it for nearly a month if not
| more. And the UX has been infinitely confusing. I've been using
| 2fa for a decade (not an exaggeration, an understatement). I've
| been using u2f since the first month it was available and FUCK
| Google for this blog post.
|
| A month ago I logged in and tried to check on my security tokens.
| Their UI was silently upconverting them. Without telling me. And
| the flow made it look like it was just deleting them. Hours later
| I realize it had re-enrolled them AND IT LOST THE DESCRIPTION I
| GAVE TO THEM. To be clear, it trashedt the decription I gave them
| during (what I didn't know at the time) was re-enrolling them as
| passkeys, because i sure as hell wansnt in the passkeys area. So
| not only did I inadvertently change them, they're now
| indistinguishable and unidentifiable to me. So if I want to
| ensure my primary and backup tokens are enrolled properly , I
| have to do it all over again, with all of them in my possession
|
| Seriously, I have defended google against all sort of claims with
| respect to their 2FA and they can absolutely _get up their own_
| after what they pulled, and now this blog post.
|
| Do some god damn basic (user) testing FFS. I would literally pay
| $1000usd right this second to scream at the people who green-lit
| and implemented this. And another $1000usd to ensure to people
| here that I know _DAMN WELL_ what I 'm talking about here. It's
| not like I don't have video evidence of exactly what I'm stating
| here on an unlisted YT video tweeted at Google Security.
|
| Edit2: to be VERY clear, I have a video I reviewed, just now,
| that shows me trying to enroll an existing Security Token with a
| description, it _disappearing_ , it then appearing as a Passkey
| with no description.
| sillysaurusx wrote:
| Your comment would be more impactful if it explained clearly
| what the problem is. What does it mean to upconvert a security
| token? In fact, what's a security token?
|
| (I ask mainly so that I can watch out for whatever bit you. On
| the face of it, the blog post seems pretty anodyne. The
| screenshot shows that it's optional, not forced, since there's
| a "not now" button.)
|
| EDIT: oh, they auto converted your security keys to passkeys?
| With no option to roll back? Yeah, that's not great.
| https://support.google.com/accounts/answer/6103523?hl=en&co=...
| rzzzt wrote:
| "Not forced" would mean the dialog has a "Nope", "Not" or
| "Nuh uh" button instead of "Not now" and permanently goes
| away when clicked, never to return.
| k8svet wrote:
| I'm sorry, I'm not laughing at you, I'm laughing at the
| premise of Google acknowledging this, let alone fixing it
| properly enough to have a "rollback".
|
| As far as I call tell, my physical yubikeys that went though
| this process have continued working with the same ultimate
| user experience, thank God. Minus the 45 minutes where I
| thought I was locking myself out _due to them disappearing
| from the ending landing page that listed my enrolled Security
| Tokens, due to the buggy upgrade UX flow_ or the fact that I
| have no way of confirming which of my primary /secondary
| tokens are now actually enrolled _because it trashed my
| descriptions during this upgrade_.
|
| I am actually infinitely sorry at the times I openly
| questioned user error when people expressed Kafka-esque
| nightmares wrt to google auth. I'm actually quite annoyed at
| myself for ever doubting them.
| nicman23 wrote:
| but i cannot just use a password for IMAP ffs
| LeoPanthera wrote:
| 1Password enabled PassKey support recently and I was "surprised"
| to learn that there is no way of exporting them out of 1Password.
| They're not included in the 1PUX format export, nor in the CSV.
|
| That means that they're literally impossible to back up. If
| 1Password goes down, or the company stops operating, or anything
| else like that, your Passkeys are just... gone. Absolutely no way
| to recover them.
| maxwellg wrote:
| 1Password's Passkey support feels very aggressively growth-
| hacky to me. They intercept calls to `window.credentials` and
| if you want to use 1Password along side other verifiers like
| Yubikey, you need to go into your settings and disable their
| passkeys offering entirely. It's similar to how they also
| intercept (and globally disable!) Google One Tap prompts in
| order to show their own OAuth prompt. I only use their Chrome
| extension so I'm not sure if the native app experience is
| significantly different.
| gumby wrote:
| Is version 8 reasonably mac-like? On 7 it's still a mac
| application that acts like a true mac application (drag/drop
| works properly everywhere, expansion, properly keyboard-
| enabled, etc) which is well nigh impossible when running inside
| a chrome box.
|
| Agile Bits support kept insisting it was the same as the old
| native app and people kept complaining about bugs until I
| stopped following it.
| tomduncalf wrote:
| It's so rare that I use anything other than the 1Password
| Chrome extension that I couldn't really tell you! The main
| app seems.. fine? But like I say, I hardly use it, so I
| probably wouldn't notice details like you mention.
|
| Do you have a different workflow where you use the main app a
| lot?
| gumby wrote:
| I keep a lot (including images) in the main app as an
| ecrypted shared resource for IDs and various other secure
| info. If I suddenly need my insurance card I can quickly
| grab it out of the app rather than rummage through the
| (unencrypted) icloud or dropbox filesystem on ios. And I
| can cut/past text out of the images. I also use it for
| logging into apps, dragging credentials into remote
| machines over ssh etc.
|
| With 1password 7 whe safari plug in is more conveniently
| integrated than the chrome one which is pretty clunkly by
| comparison, though this is true of other chrome plug ins
| too. But that's not a big deal as I rarely use chrome
| anyway, just for google docs which don't need 1password.
| LeoPanthera wrote:
| It's as Mac-like as any other Electron app. Which is to say,
| it does a pretty good impression of a Mac app, but the bundle
| is 345M, with another 244M hiding in your Library directory.
| jxcl wrote:
| Currently, none of the big players in the passkey space support
| exporting or importing of passkeys, because the spec for doing
| this securely has not been agreed upon, and nobody wants to
| allow plaintext export of passkeys.
|
| See a recent post in the 1Password passkey AMA about this
| subject:
| https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
|
| Re. your point about 1Password going down: Your passwords and
| passkeys are all stored locally when they sync to your devices.
| If 1Password becomes unreachable for any reason, you still have
| access to everything in your vaults, you just can't sync
| between devices any more.
| LeoPanthera wrote:
| It's difficult not to see the "it's for your own security"
| argument as a cynical lock-in ploy.
|
| Because you can export plain-text passwords just fine, and
| they give you exactly the same access as a PassKey does.
| XorNot wrote:
| And what a surprise that is, the one feature necessary to
| ensure vendor lock in doesn't happen was at 0 priority before
| they rolled it out.
| SheinhardtWigCo wrote:
| The whole point is vendor lock-in.
| sbuk wrote:
| How does that work if you can register multiple different
| keys using different devices from different vendors on an
| account?
|
| Edit: I took the last sentence out, it was childish on my
| part.
| darknavi wrote:
| > nobody wants to allow plaintext export of passkeys.
|
| While noble, why? 1Password exports a plaintext file that has
| all of the credentials in plaintext already.
| mplewis wrote:
| Because passkeys are supposed to be a bit more secure than
| plaintext passwords.
| wutwutwat wrote:
| Passkeys are supposed to eliminate the need for companies
| to store a password so we no longer have to deal with the
| fallout of 40 breaches a year. In order to export
| passkeys it has to be in plaintext at some point, even if
| encrypted once again into the export file. Point is, one
| of the huge selling points of pushing people to use
| passkeys is the portability and lack of vendor lock in
| yet here we are with choices that are all currently
| vendor lock in.
| afiori wrote:
| This sounds a bit like "a turned off computer is the only
| secure computer"
| droopyEyelids wrote:
| This is a quibble, but if 1password goes down, your vaults
| still exist on all your devices and the app will keep working,
| it's only the syncing of modifications between devices that
| won't work.
| shepherdjerred wrote:
| It's a feature that came out just last month. Give them some
| time.
| numpad0 wrote:
| Can't you enroll a Yubikey and keep it in a safe?
| rkagerer wrote:
| Do any of the third-party, self-hosted password managers
| provide a compatible passkey implementation that can actually
| be exported and backed up in a secure manner?
| idle_zealot wrote:
| Isn't that the point of Passkeys? The user isn't allowed to
| interface with them directly, so social engineering can't
| compromise them [1]. Rather than move your passkey between
| devices, you're meant to generate a different passkey for each
| device, then register all of them with the relevant service,
| like SSH keys.
|
| 1: of course, a user could still be tricked into adding an
| attacker's passkey to their account or something
| LeoPanthera wrote:
| But 1Password syncs your passkey to all your devices, so you
| only have one.
| efitz wrote:
| Don't worry, if you lose your passkey all you need is
| access to your email to receive a password reset link.
| </sarcasm>
| CharlesW wrote:
| That's literally the solution to "What if I lose all the
| passkeys associated with my account _and_ I 've also
| forgotten my password?"
| afiori wrote:
| Except for when it happens to your email account.
| drdaeman wrote:
| The major problem with passkeys is that first they were
| poorly designed so there's no portability or ability to
| enroll an offline (or worse, physically unavailable, like
| stored in a safe) authenticator, then there's this kludge
| to work around the limitation.
|
| It was obvious from day 0 (to anyone except for Apple and
| Microsoft) that people do have multiple devices and not
| all of them are from a single vendor. My only explanation
| is that they deliberately decided to ignore this aspect,
| because it wasn't in corporate interests.
|
| They made it significantly easier to lose all the
| passkeys, because they made it very hard to add multiple
| passkeys (you literally have to walk/run/drive/fly and
| grab every different device you have, get it online and
| register - or get properly locked in with a single vendor
| and pray they work for you, forever).
|
| Carrying a Yubikey does not work (you can lose it).
| iCloud/Windows Hello does not work (you can be on a non-
| Apple/Microsoft device). 1Password is better but still
| does not really work (you can lose access to your
| account). They're all SPOFs, and avoiding SPOF was
| _deliberately_ made hard (you can 't easily enroll a
| "backup" Yubikey that you don't have at hand, and if you
| have it at hand it's not a backup anymore).
|
| Heck, "official" demo at passkeys.io doesn't even bother
| to showcase how multiple passkeys are going to be a thing
| at all, which is an obvious red flag.
|
| That is, not to mention that a growing number of vendors
| contributed to the crappiness by limiting what kind of
| authenticators and which platforms one can use (BestBuy,
| PayPal and so on), contributing to decreased security and
| increased headaches.
| [deleted]
| Yeul wrote:
| I had a discussion with my mother advising her to switch: she
| is afraid of changing ISP because her email is tied to her
| provider.
|
| We fixed this on mobile years ago but email is still a goddamn
| mess. Moral of the story: never get locked in.
| CharlesW wrote:
| You're not locked in. Want to switch? Add a passkey. Lose all
| your passkeys? Do the "forgot password" thing just like
| you've done forever.
| kibwen wrote:
| The "forgot password" flow involves accessing your email.
| And accessing your email without having access to your
| passkey requires a device that has previously logged in to
| your email. And the device that has previously logged in to
| your email is the same device where your passkeys are
| stored, which is to say, the same device that is now lost
| or bricked, which is the reason your passkeys are lost in
| the first place.
|
| And sure, you and I have multiple devices. We're in the
| minority. Most people just have the one. Without another
| way in, they're irrevocably fucked.
| sbuk wrote:
| You only use your passkey when logging in to your email
| account if you use a web-based client exclusivley.
| yieldcrv wrote:
| does this work in conjunction with multifactor authentication?
|
| like biometric + one time passcode?
| kube-system wrote:
| It _is_ multifactor authentication. The second factor is a
| private key stored in your device.
| rcarmo wrote:
| As usual, the multi-device/multi-OS and recovery scenarios are
| simply just glossed over. I'll stick with a password vault I can
| sync to multiple OSes, thanks.
| Flimm wrote:
| You can associate multiple passkeys with your account. Your
| account can have a passkey that is synced across
| Android/Chrome, and another passkey that is synced across Apple
| devices and browsers.
| lazide wrote:
| The vaults have been adding passkey support (1Password already
| has it, for instance).
| rcarmo wrote:
| I will never willingly go back to using 1Password.
| wkat4242 wrote:
| Hmmm. I don't want to be dependent on any cloud provider for my
| logins. Any passkey solution must be fully self hosted for me to
| accept it. Is there such a thing yet?
| the_snooze wrote:
| I use Yubico Security Keys as passkeys. One at home, one in my
| office, one on my person. All with a local PIN lock (and
| 10-failure-device-reset) so simply having the hardware is
| insufficient to log in.
|
| The only annoying thing about this setup is having to manually
| add each key to each new passkey-enabled account I have.
| wkat4242 wrote:
| Yeah I have yubikeys, the problem is that most of the
| services I use don't offer to enroll more than one. Also
| there's the issue of limited slots on each key for
| passwordless.
|
| I like the whole idea of syncing a single key. But the whole
| chain must be owned by me and me alone.
| grotorea wrote:
| A FAQ at the bottom answers some questions
| https://safety.google/authentication/passkey/ .
|
| Seems that the recovery if you lose the devices with stored
| passkeys is still using a password.
|
| And will it be possible to use software keys and backup them to
| wherever I want and use them with Google or is it going to demand
| TPMs or that I keep the key in a secure vault in my phone or
| something or the sort?
|
| There still isn't a way to use this on desktop Linux right?
___________________________________________________________________
(page generated 2023-10-10 23:01 UTC)