[HN Gopher] Passkeys: The beginning of the end of the password
___________________________________________________________________
Passkeys: The beginning of the end of the password
Author : donohoe
Score : 380 points
Date : 2023-05-03 12:13 UTC (10 hours ago)
(HTM) web link (blog.google)
(TXT) w3m dump (blog.google)
| TheChaplain wrote:
| And if you have your google account banned/disabled for whatever
| reason, then what?
| toomuchtodo wrote:
| Passkeys should still be on your local device. Account recovery
| should fall back to e-mail magic link or government credential
| proofing (depending on data sensitivity and threat model).
|
| (manages customer IAM for a FinTech)
| garganzol wrote:
| And when that last device dies in an accident or force major,
| what's next? Proofing won't work because if the solution is
| really as secure as it should be then neither party can have
| access in an unencrypted form.
| [deleted]
| [deleted]
| jahnu wrote:
| Indeed I wouldn't trust Google or Apple to be the only place my
| passkeys are stored. I'm currently a 1Password user and their
| upcoming support looks like it could address this issue (I'm
| not in any way affiliated with them)
|
| https://www.future.1password.com/passkeys/
| sebk wrote:
| Sure but this currently means a virtual authenticator that
| puts unwrapped passkeys in the same memory as other
| applications, leaving only the OS and no other physical
| measures to protect a direct-memory read. That might be
| acceptable for your threat model, but no other currently
| adopted WebAuthn authenticators work this way other than
| password managers that don't want to be left out.
|
| Hopefully in the future OSs will have better APIs to allow
| third-party tools like 1Password to leverage hardware
| components like TPMs and Secure Enclaves to build a sync
| fabric that's not tied to the hardware vendor, but this does
| not currently exist and is not trivial to implement without
| significant consideration about phishing.
|
| I think YubiCo and password managers have a tremendous
| opportunity here to partner up to build sync fabrics
| bypassing OS vendors that might not be as incentivized to
| provide these APIs now, but I don't believe it's moving,
| currently.
|
| Additionally, when you say you wouldn't trust Google or Apple
| to be the _only_ place your passkeys are stored, it's likely
| that even if we can have third-party sync fabrics, that these
| will never be interoperable. I don't believe you'll be able
| to "export" a Passkey from your iCloud ecosystem and import
| it into the 1Password ecosystem as you can do today with
| passwords. Doing so would break assumptions about the
| strength of the authenticator as far as WebAuthn is
| concerned, and would weaken Apple's security posture as well.
| Instead you'd probably have to maintain _both_ sync fabrics
| independently with every service you sign up for.
| jahnu wrote:
| Thanks for that info! Still just learning about this stuff.
| discerning_ wrote:
| Doesn't support yubikey even though yubikey supports fido2 and
| passkeys.
| hanniabu wrote:
| Sign in with ethereum is my preference
|
| https://login.xyz/
| garganzol wrote:
| Please don't. In case of emergency, all that fancy stuff is
| unrecoverable - while passwords continue to work.
| uni_baconcat wrote:
| Passkey is convenient and safer than password, but all of that is
| based on the trust of 'trusted device'.
| SadWebDeveloper wrote:
| This looks and feels like passwords with extra steps...
|
| I mean now i need to "store, manage and secure" my per-user-
| certificate sorry "my passkey" myself and if its get compromised
| its my fault, how are passkeys more "secure" than enforcing a
| secure long password that the user can't change unless he met
| certain conditions and its conveniently stored inside the
| password manager i just built.
|
| What happens if i lost all my devices due to a fire? at least a
| password let me still access things we these i might need to
| prove again that i am me, it might even be more easy to steal
| accounts because i can ask google to change it because i lost my
| passkey.
| dcow wrote:
| The solution, for you, is a cloud synced passkey manager,
| possibly a custodial one.
|
| A password manager with strong passwords is weaker than a
| password manager with passkeys, because passkeys use asymmetric
| crypto and passwords+2fa involve exchanging a shared secret
| over an insecure channel at some point (yes I'm considering
| 1-sided TLS an "insecure" channel here).
|
| Trust the security experts when they say passkeys are more
| secure. Now, solving the UX to make it match that of passwords
| plus managers today _is the_ problem, agree.
| lxgr wrote:
| > The solution, for you, is a cloud synced passkey manager
|
| This is in fact the only possible solution you get on iOS,
| and the default solution on Android.
| compiler-guy wrote:
| > Trust the security experts when they say passkeys are more
| secure.
|
| I trust the security experts when they say passkeys resist
| various attacks better than current systems...
|
| > Now, solving the UX to make it match that of passwords plus
| managers today is the problem, agree.
|
| ... but poor UX makes it likely the users will end up doing
| things that are less secure, not adopting them at all, or
| messing things up themselves in such a way that they lock
| themselves out of their accounts.
|
| So until the UX issues are fixed, "more secure" only in the
| narrow definitions that sophisticated security folks worry
| about. If the folks I support blow it, it doesn't matter that
| some mostly theoretical MITM attack was prevented.
| dcow wrote:
| Understood completely. I was only trying to articulate that
| there _are_ tangible security benefits to using passkeys
| over passwords and no /zero theoretical downsides. A 32byte
| random password is just an edDSA private key that's not
| private, after all, and the two can be managed the exact
| same way with none of the device-bound woes. That is, all
| assuming that platform vendors commit to providing the same
| affordances for passkeys as they do for passwords in terms
| of allowing users to delegate to 3rd parties to complete
| signing of the WebAuthN challenge.
|
| I also believe that Apple/Google/Microsoft understand the
| importance of not having a "I lost my device all my stuff
| is toast" UX, which is why Apple requires iCloud keychain
| to enable passkeys. They are making a pretty strong
| statement that the UX they imagine working for the masses
| is not some rigid "no cloud no syncing not here not ever"
| stance. So I think they realize it has to be a solution
| that doesn't have that failure mode. They're okay with soft
| keys, which is at least a relief.
| lxgr wrote:
| Passwords can be both stolen (they are valid for multiple
| authentications) and are susceptible to phishing/MITM attacks.
|
| TOTP/HOTP solves the first problem by making the credential
| provided during authentications single-use, but they're still
| susceptible to phishing/MITMs (since you don't know where
| you're entering your OTP).
|
| WebAuthN solves both.
|
| > What happens if i lost all my devices due to a fire?
|
| Passkeys are synchronized to your device ecosystem vendor by
| default (i.e. Google or Apple, and soon also third-party
| password maangers on Android), for better or worse.
| JohnFen wrote:
| > Passkeys are synchronized to your device ecosystem vendor
| by default (i.e. Google or Apple, and soon also third-party
| password maangers on Android)
|
| That's a showstopper for me, personally. Not saying the idea
| is a bad one (at all!), but I won't be using it for myself.
| lxgr wrote:
| Me too - I'd much rather trust my password manager, so I'm
| hoping that platform/browser APIs will eventually become
| available that will allow such third-party implementations.
| (Android is planning to; iOS hasn't stated anything yet.)
|
| Even then I would probably not add my bank credentials or
| other high-sensitivity things there.
| garganzol wrote:
| > Passkeys are synchronized to your device ecosystem ... and
| soon also third-party password maangers on Android
|
| And at that point they make a full circle becoming just
| passwords with a master password. Essentially what password
| managers already do. You already can tie a master password to
| a biometric or another factor.
| lxgr wrote:
| Not quite: Passwords are long-lived bearer tokens, which
| can be phished/MITMed (exclusively using auto-fill helps,
| but non-technical users are still prone to be phished) and
| are administratively harder to securely manage on the
| backend of the relying party.
| alkonaut wrote:
| Did anyone else get an email from Google about this, with a link
| I'm supposed to click on iOS, but which is broken? Did Google
| really email all their iOS+Google users a broken link?
| kroeckx wrote:
| Is a passkey a software implementation of a FIDO key? Where the
| implementation could use something like the TPM to protect the
| key.
| eviks wrote:
| Since you lose the "something you know" factor with passkey-only
| authentication (e.g., with face scans), would it not be better to
| allow to add a (much shorter due to the passkey) password as well
| as an optional extra factor?
| cbeach wrote:
| Anyone know if it's possible to use this with Google Workspace
| accounts yet?
|
| From the Google Blog I clicked on "Today, passkeys for Google
| Accounts are available. You can try them out here"
|
| However, I got: "Passkeys aren't allowed on this account. Contact
| your admin for help"
|
| And the Workspace admin page doesn't seem to include any options
| for Passkeys.
| dhess wrote:
| Same here, but note that in this post on the Google Security
| Blog:
|
| https://security.googleblog.com/2023/05/so-long-passwords-th...
|
| the first sentence reads, "Starting today, you can create and
| use passkeys on your _personal_ Google Account. " (Emphasis
| mine.)
| tytso wrote:
| Disclaimer: I work for Google but nothing I say here is
| Google's opinion or relies on any Google internal
| information.
|
| I'm not surprised that Workspace accounts weren't included in
| the initial rollout. Workspace setups have interesting
| requirements that aren't necessarily there for personal
| accounts. For example, under some circumstances, if an
| employee gets hit by a bus, and there is critical business
| data which is stored in the employee's account, an
| appropriately authorized Workspace admin is supposed to be
| able to gain access to the employee's account. But what is
| the right thing to do for passkey access? Especially if the
| user uses passkey to authenticate to some non-:Google
| resource like, say, Slack which has been set up for corporate
| use? Should the workspace admin be able to impersonate the
| corporate employee in order to gain access to non-Google
| resources via passkey? What about if the employee
| (accidentally) uses their corporate account to set up a
| passkey to a personal account, such as for example E*Trade?
| Maybe the Workspace admin should have a setting where passkey
| creation is disabled except for an allowlist of domains that
| are allowed for corporate workflows? It's complicated, and if
| I were the product manager, I'd want to take my time,
| understand all of the different customer requirements (where
| customer === the Workspace administrator who is paying the
| bills) before rolling out support for Workspace accounts.
| falcolas wrote:
| Auth is as secure as the weakest link - in the case of this it's
| your email and/or customer service
|
| To put it another way, it's not really any more secure than
| passwords.
|
| Sure, there's a lower risk of password breaches, but if you're
| the target audience for passkeys, you probably also use a
| password manager with unique passwords per site (even if that
| manager is the one built into your browser and synced across your
| devices).
| judge2020 wrote:
| > but if you're the target audience for passkeys
|
| This is the difference. With the big players pushing it,
| including Apple instructing developers on the best way to
| integrate passkeys in their apps[0], it's going to overall
| shift more people from passwords to passkeys (especially when
| developers prioritize passkeys during signup).
|
| 0:
| https://developer.apple.com/documentation/authenticationserv...
| falcolas wrote:
| I have... doubts. Already webauthn isn't prompting for
| passkeys on Apple. Chrome wants a bluetooth connection out of
| the box, and firefox does its own internal auth path that
| doesn't involve the OS.
|
| Chrome and Edge on Windows are the only ones that prompt me
| for passkeys today (Firefox tries to use Windows for auth,
| which throws up a scary prompt).
| judge2020 wrote:
| I don't follow for these
|
| > Already webauthn isn't prompting for passkeys on Apple.
|
| It does for me on iOS, at least (and Safari on MacOS; other
| browsers don't use the native icloud passkeys, chrome has
| its own secret store).
|
| > Chrome wants a bluetooth connection out of the box,
|
| IIRC it works without it for on-device passkeys, but caBLE
| requires Bluetooth to facilitate proximity passkey
| connections if you want to use wireless webauthn.
| falcolas wrote:
| > other browsers don't use the native icloud passkeys,
| chrome has its own secret store
|
| > but caBLE requires Bluetooth to facilitate proximity
| passkey connections if you want to use wireless webauthn.
|
| And that's the problem. The lack of a cross
| browser/device/os standard. You can't create a secure
| authentication chain - let alone replace passwords -
| without standards that are broadly accepted; without
| broadly _accepted_ standards. To do otherwise means you
| have to train your average Jack on 4 (or more) different
| ways to authenticate to one service.
|
| And the way they'll pick? Passwords. Because they know
| how to use passwords.
| seti0Cha wrote:
| > Auth is as secure as the weakest link
|
| True if you are being specifically targeted, but there are
| whole classes of vulnerability that you are better off not
| having even if you have less than perfect opsec. To take an
| extreme example, my personal server may have an unpatched
| vulnerability that a determined attacker might exploit, but
| that doesn't imply I might as well share the same password
| across all my accounts.
| falcolas wrote:
| > that doesn't imply I might as well share the same password
| across all my accounts
|
| Irrelevant to the argument I made. My argument already
| assumes you're using unique passwords, since it's made quite
| simple these days.
| seti0Cha wrote:
| My example appears to have distracted you from the point I
| was making. Let me make the point again without an example:
| being vulnerable to one attack does not mean there's no
| value in not being vulnerable to another attack when the
| attacks require different strategies and levels of effort.
| Or again: making breeching security more difficult does in
| fact reduce your risk of random security breeches. Or to
| put it another way, a determined attacker will search for
| an opening, an opportunistic attacker will move on. There's
| value in protecting yourself from opportunistic attacks.
| falcolas wrote:
| Changing out passwords for passkeys does not improve
| security in anything but a theoretical manner.
|
| Good passwords (stored on the backend with a password-
| optimized hash) are pretty close to bulletproof, and all
| browsers that I've used in the last few years prompt you
| with very good passwords.
|
| Again, the key is that people who would use passkeys are
| the same ones who will be using good, non-reused
| passwords in the first case. We've taught non-technical
| users too well that they should not pay attention to out-
| of-browser prompts, so they're not going to be able to
| use passkeys without significant and broad re-training.
| okhuman wrote:
| run your own passkey server with
| https://github.com/authcompanion/authcompanion2
| gst wrote:
| Just a heads-up if you're planning to use passkeys with
| iOS/macOS: Might be fixed already, but last time I tried it out
| it seemed like iOS only stored a single passkey per domain. If
| you first store a passkey for a@domain and then later on store a
| passkey for a different user b@domain the a@domain passkey is
| overwritten without any warning. Or at least this seemed to be
| the case a couple of months ago when I tried it out.
| ezfe wrote:
| That would only happen if the site isn't properly giving the
| passkeys identifiers. Having single passkey/username combo is
| working as intended, but it shouldn't be overwriting different
| usernames.
| judge2020 wrote:
| All the way back in iOS 15, when getting passkeys meant
| building an xcode app to access the developer menu and enable
| passkeys, I had no trouble storing multiple per domain when
| adding passkeys to GitHub. Maybe the site you were trying to
| use sent the same `user.id` for both requests? /shrug
| asimpletune wrote:
| For me at least it works. I have multiple accounts for the same
| domain and iOS/macOS prompt me to choose from the last one
| used, or I can choose to pick from a collection.
| tommiegannert wrote:
| I just started looking into WebAuthn this week, and was annoyed
| that there is no simple way to begin: Chrome (on Ubuntu) doesn't
| provide a local authenticator, unless you use an emulated one.
| This means any site that wishes to use WebAuthn can't just say
| "let's do it for everyone," because not everyone might have a
| phone they want to use, or a security key.
|
| I found out [1] that WebCrypto + IndexedDB is pretty much the
| missing piece, where you can store/retrieve a generated CryptoKey
| without having access to the private data. I wish the WebAuthn
| API would handle that for me...
|
| The end-result is likely that everyone is using WebAuthn as a
| 2FA, rather than a password replacement, because on-boarding
| seems to suck right now.
|
| [1] https://stackoverflow.com/a/49479890
| ilyt wrote:
| That kinda looks like vendor-locked equivalent of pub/privkey
| auth ?
| rgrmrts wrote:
| My understanding of passkeys was that they replace passwords, but
| a few places where I've seen them implemented just use passkeys
| as a second factor, NOT a replacement for passwords themselves.
|
| Can anyone who knows more about passkeys explain why this is the
| case? Are service providers just misusing passkeys as the second
| factor, or do I misunderstand passkeys?
| mark242 wrote:
| I don't know if this is the correct tactical implementation,
| relies upon having a cloud-based account that never goes away or
| gets disrupted in any fashion etc etc etc etc.
|
| However! If you have built any product which has gotten traction,
| you know just how much of a pain auth still is in 2023. It will
| always be your number one customer service pain point -- either
| unable to remember the email address your users signed up with so
| they can't initiate a reset password flow, or not getting an OOB
| email to start said flow, and so on. Auth in its current state is
| a complete drain on company time, resources, and money.
| Extrapolating out, I really wonder what a raw cost of the world's
| total GDP is taken up by dealing with auth issues.
|
| Any kind of breakthrough here would be such a net benefit to the
| human race as a whole. Even the half step of OAuth, even with all
| of its complexity and "did I use Google or Facebook or Apple to
| sign into this site?", even that reduced friction enough to be
| such a material benefit to customer service. If we can make
| signing into a service as easy as unlocking your phone, there
| would be a huge productivity jump.
| karaterobot wrote:
| > the same way they unlock their devices: with a fingerprint, a
| face scan or a screen lock PIN
|
| I am not a cryptographer: why would a 6-digit screen lock PIN
| with this system be any safer than a 6-digit numeric password on
| the web (i.e. not very)?
| Scion9066 wrote:
| Generally, most devices don't encrypt/protect your data with
| that 6-digit PIN directly. They store the important secrets
| like device encryption keys in some kind of secure
| enclave/processor that does things like rate limit the PIN
| attempts to prevent brute-forcing. What the fingerprint or face
| scan is doing is just unlocking that secured data a different
| way.
| seti0Cha wrote:
| If your physical device can be unlocked remotely with a 6 digit
| number, not much, but that's not generally the case.
| croes wrote:
| Many phones block access after too many false PINs, if the web
| password has the same feature there is no difference.
| alwaysbeconsing wrote:
| In order to exploit the 6-digit password across the web, the
| attacker needs 1) the password, 2) web access from anywhere in
| the world. To exploit the PIN guarding your phone, the attacker
| needs 1) the PIN, 2) your phone. You can't prevent the attacker
| from having access to the internet, but you are probably
| reasonably good at protecting your phone physically.
| hk1337 wrote:
| I don't mean this to be negative as much as an observation but it
| seems like it's Google's version of "Sign in with Apple ID"?
| Apple ID only works with Apple devices though, so I wonder if
| will work for any device? Perhaps it will work better on Android
| but can be implemented for other devices?
| judge2020 wrote:
| No. This is the fido2 / webauthn standard, where the device
| itself generates new keys for each website and the device uses
| these stored keys to perform public key authentication to log
| into websites. For some ecosystems (namely iCloud Keychain) it
| syncs these key pairs between devices.
|
| They already have "sign in with google" which directly links
| sites to your Google account. This is not that.
| mdtancsa wrote:
| It seems awfully trivial but in the context of a positive
| security announcement
|
| g.co/passkeys (my gut says, "what is this scam? I am not clicking
| on that") https://myaccount.google.com/signinoptions/passkeys (my
| gut says, "interesting, let me take a look")
| nashashmi wrote:
| So yahoo has had this for a while. yes ... Yahoo. What's wrong
| with Google these days? They seem to be too focused.
|
| BTW, passkey is the name for a password that is made using word
| keys.
| barkerja wrote:
| Google has actually had this rolled out for some time. I've
| been using a Passkey on my account for the better part of a
| year. For whatever reason, they're just now announcing it.
| nashashmi wrote:
| Thanks for the info. I am upset I missed out on this.
| insane_dreamer wrote:
| the "end of the password" is like the "year of linux on the
| desktop"
| bwanab wrote:
| And once again, with a Google Workspace (or whatever they call it
| these days) account, "Passkeys aren't allowed on this account.
| Contact your admin for help".
|
| I am the admin. Doesn't appear there's any way to help.
| arunc wrote:
| It seems like passkey isn't available for Google Workspace yet.
| (I'm a Google Workspace admin as well).
| galaxyLogic wrote:
| Does this basically means there is one "master password"?
| segmondy wrote:
| I'm still salty about this. Called it passkey too.
| http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and
| applied to YC. Crickets. Hope to see this take off, with my
| approach I made it where you don't even need to "register", you
| can go to a site and just have an account. I did the fingerprint,
| face scan, PIN approach for more security, but my favorite was
| NFC ring. Basically you have an NFC ring you wear on your finger.
| That way if someone steals your phone or takes it, you are
| protected. The entire thing uses a unique pub/pri keys for each
| site. Keys are backed up by shamir secret sharing distributed
| across your friends or providers you select. 100% of your keys
| are encrypted so I the provider can't see it, recover it or be
| forced to reveal it. Since each site has a key, one could do
| interesting things. E2E encryption for apps where they can't be
| forced to reveal a key. If you are using an App and want to send
| someone a message, the app can fetch the person's pub key, then
| an inbuilt editor outside of the App in our app will be used to
| compose the message and encrypt it. That way the App provider
| can't be forced to reveal the message, and they don't have keys
| either. Pretty much control in the hands of the user. The same
| approach can be used for a storage pod where you have a pod that
| stores your data that you encrypt and control. This is a good
| start, hopefully we can see the good ideas of this, AT protocol
| (account portability), keybase, etc all start to bear fruit.
|
| What I don't like bout Google doing this is that the big
| providers use this to tether and lock you in to their platform.
| The power of this shines when it's federated. So if you run a
| site, you can provide security to your users without them needing
| Google, FB, etc.
| lxgr wrote:
| > use this to tether and lock you in to their platform.
|
| You could say this about Google's proprietary authenticator app
| in the past, but now that they support Passkeys, arguably the
| opposite is true.
|
| Importantly, you can now (with FIDO CTAP 2.2 and tunnel
| services [1]) use an out-of-platform Passkey to log into your
| account cross-device, e.g. you can use an iOS Passkey to log
| into an account on a Windows Chrome instance via QR/Bluetooth.
|
| There's absolutely nothing stopping you from providing your own
| implementation as long as it complies with the "hybrid
| transports" part of FIDO CTAP 2.2.
|
| [1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-
| cl...
| sdfghswe wrote:
| > You could say this about Google's proprietary authenticator
| app in the past
|
| There's many implementations of OTP. I've never used google's
| and I've been fine.
| michaelt wrote:
| The article says "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."
|
| Does that not rather imply that, if I log in with faceid on
| an iphone, my login will be tied to my ability to faceid on
| an iphone, and hence only available on iphones and macs?
|
| As a user, that's sounding a lot like platform lock-in to me.
|
| And as a developer, if I want a way for users to log in
| without a password, and I don't mind that login mechanism
| being reliant on the user's account with apple / google /
| microsoft - wouldn't I just add a 'log in with apple / google
| / microsoft' button to my login page?
| kstrauser wrote:
| Ever site I've accessed with a passkey lets you tie it to
| an existing account with a username/password, Google login,
| Apple login, iPhone, YubiKey, etc. I've not used a passkey
| where that was the _only_ auth I could create on an
| account.
| lxgr wrote:
| You can use your device passcode instead of FaceID.
| howinteresting wrote:
| What it _does_ imply is that if you store your passkeys on
| Apple 's keychain, migrating to Android becomes that much
| harder. (I assume that Google will provide an
| implementation of passkeys on iOS when that becomes
| available as an API, but it will be a cold day in hell
| before Apple provides access to its keychain on Android.)
|
| The solution is to not use Apple's keychain for passkeys
| (and really not use Apple's proprietary services for
| anything at all), but we can't depend on people to have
| that foresight.
| [deleted]
| voxic11 wrote:
| No passkeys are just normal private keys. You can store
| those private keys in a particular platform's secure key
| store which on phones can be decrypted/made usable when you
| unlock the device. But there is nothing stopping you from
| transferring these keys to a different device if you wish.
| michaelt wrote:
| So if I transfer a passkey to my Yubikey, which has a
| single button and no pin, thus achieving 1-factor
| authentication - is that undetectable to the website?
|
| Because sources like [1] say that "A passkey can replace
| a password and a second factor in a single step" and "a
| biometric sensor (such as a fingerprint or facial
| recognition), PIN, or pattern" - isn't there something in
| the standard that ensures the second factor is
| maintained?
|
| [1] https://developers.google.com/identity/passkeys
| Veliladon wrote:
| You wouldn't transfer a passkey to your YubiKey. You
| would enroll it as another device that can be used to
| login. Like right now on my Google account I have an
| iCloud passkey and a Windows Hello passkey since iCloud
| can't sync a passkey to Windows (yet).
| cookiengineer wrote:
| So this is basically the same thing like ssh keys?
| Veliladon wrote:
| Exactly. But with some added security.
| dotancohen wrote:
| Hypothetical political journalist just lost both his
| Yubikeys when his office and home were both targeted. He
| still has an off-site backup of his passkey. How would
| you envision this working?
| dwattttt wrote:
| I'm unfamiliar with the particulars of passkeys, but with
| hardware tokens I've used before, you'd log in ASAP and
| unenroll the keys you've lost custody of.
|
| edit: spelling
| tialaramex wrote:
| _If_ the site insists on UV (User Verification) rather
| than UP (User Presence) a device which has no way to
| verify the user should reject that.
|
| _If_ your site insists on the device providing a broad
| identifying signature (the specification says devices
| classes identified this way ought to consist of 10k+
| devices, and in most cases a manufacturer will just
| identify particular models, like OK, this the model we
| made in 2019-2021, now we 're re-tooling to make the
| newer model lets give it a new identifier) _and_ the user
| agrees (I always refuse if asked, the documentation
| advises you just don 't bother asking) to provide this,
| then you can see OK, it's a Yubikey Model 6J, I think
| that's (delete as appropriate) fine / not fine. This is
| obviously a large piece of extra maintenance work, hence
| it's advised you should not do it.
| lxgr wrote:
| True, Passkeys are private keys at heart, but relying
| parties can verify whether they are stored in software or
| hardware by requesting/requiring authenticator
| attestation when they are created.
| dcow wrote:
| And certain hardware from certain platform vendors
| doesn't allow exfiltration of private key material.
| Though I don't think _this_ can be specified by the
| relying party so that 's how Apple stores all keys in
| keychai. I sincerely hope it remains best practice for
| relying parties to not require/use the platform
| attestation feature to lock users onto "trusted"
| platforms.
| lxgr wrote:
| Device binding can be required by relying parties! They
| can just refuse to accept credentials without attestation
| statements signed by a trusted party.
|
| My government e-signature service does that: I can't even
| use a Yubikey, ironically, because that's not "FIDO level
| 2 certified". I had to buy a more or less completely
| unknown brand instead (of which a government affiliate is
| apparently the exclusive reseller in my country...)
| howinteresting wrote:
| How exactly would you transfer your iOS passkeys to
| Android? Please provide an enumerated list of steps.
| dcow wrote:
| You're suggesting that using a tunnel service is the
| recommended way to be a platform agnostic backend. But that
| doesn't cover the scenario where your password manager is
| running on the same device as the one where the user is
| performing the login, and all the UX/UI refers to using a
| phone to scan the QR code. I guess you could snag the QR code
| using platform accessibility features, but that's a real
| silly hack. Just let me advertise some mDNS service record
| for "authenticator" and require me to advertise a pubkey and
| let the user select/allow me once and remember the decision
| until the pubkey changes so that I'm trusted backend without
| the QR scanning rigamarole.
| lxgr wrote:
| > the scenario where your password manager is running on
| the same device as the one where the user is performing the
| login
|
| Android will provide an API for that scenario (i.e. on-
| device third-party authenticators) in the near future [1].
|
| Hopefully, iOS will do the same.
|
| [1]
| https://developers.google.com/identity/passkeys/supported-
| en...
| dcow wrote:
| Yes, I'm waiting patiently in the wings. Sadly when I
| asked Apple's Passkey team about supporting this, they
| said it wasn't on the roadmap (though they carefully
| didn't say never, it still doesn't instill much hope).
| Once this missing piece becomes a required part of the
| standard, I'll stop holding my breath and get super
| excited about passkeys.
| onlypositive wrote:
| Can I store the keys in bitwarden or am I stuck using google
| chrome to access this or whatever Mozilla cooks up?
|
| I can't rely on retaining access to my Google account for
| logging into things.
| lxgr wrote:
| On Android, there will supposedly be an API for third-party
| Passkey implementations soon:
| https://developers.google.com/identity/passkeys/supported-
| en...
|
| 1Password has already announced their intention to use this
| once ready. I really hope iOS will provide something
| similar soon.
| yepguy wrote:
| Not now, but soon. Bitwarden's public statements over the
| past year, and their acquisition of passwordless.dev, would
| seem to indicate that they're working very hard on adding
| passkey support.
| Moneyyyyy wrote:
| At least Google does those things as an open standard.
|
| So it should be easy for everyone else to do their own.
| CharlesW wrote:
| > _What I don 't like bout Google doing this is that the big
| providers use this to tether and lock you in to their
| platform._
|
| How so? I just created two passkeys for my Google account --
| one for Chrome, and one for my Apple Keychain.
| rdsnsca wrote:
| Apple, Google and Microsoft are all supporting passkeys
|
| https://developer.apple.com/passkeys/
|
| https://arstechnica.com/information-technology/2022/10/passk...
| blackhaz wrote:
| class
| ASAuthorizationSecurityKeyPublicKeyCredentialAssertionRequest
|
| Now I'm wondering what's the longest class name out there...
| guessmyname wrote:
| > _Now I 'm wondering what's the longest class name out
| there..._
|
| The longest class names I remember are in the Java
| Development Kit (JDK) version 1.6, under the Swing+Nimbus
| namespace: com +-sun +-java
| +-swing +-plaf +-nimbus
| +-... +-InternalFrameInternalFrameTitlePane
| InternalFrameTitlePaneCloseButtonPainter.java
| +-InternalFrameInternalFrameTitlePaneInternalFrameTitlePane
| CloseButtonWindowNotFocusedState.java +-Int
| ernalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconi
| fyButtonPainter.java +-InternalFrameInterna
| lFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNot
| FocusedState.java +-InternalFrameInternalFr
| ameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.jav
| a +-InternalFrameInternalFrameTitlePaneInte
| rnalFrameTitlePaneMaximizeButtonWindowMaximizedState.java
| +-InternalFrameInternalFrameTitlePaneInternalFrameTitlePane
| MaximizeButtonWindowNotFocusedState.java +-
| InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMe
| nuButtonPainter.java +-InternalFrameInterna
| lFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFoc
| usedState.java
| +-InternalFrameInternalFrameTitlePanePainter.java
| +-InternalFrameInternalFrameTitlePaneWindowFocusedState.jav
| a +-...
|
| There were threads in 2012 about them:
|
| * https://news.ycombinator.com/item?id=4549685
|
| * https://news.ycombinator.com/item?id=4770861
|
| Someone copied the code in this repository: https://github.
| com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...
| judge2020 wrote:
| > What I don't like bout Google doing this is that the big
| providers use this to tether and lock you in to their platform.
|
| This is the concern, but exporting passkeys to other ecosystems
| seems like it'll come with time, even if via third-party tools
| or like how browsers will prompt you to "import your
| <passwords|passkeys>" upon setup.
| krono wrote:
| Call me a cynic but I'm convinced that won't be happening
| anytime before critical mass adoption of these companies' own
| solutions, and either defeated acceptance of this new norm or
| abject incomprehension by whomever remains.
|
| "All your base are belong to us"
| dcow wrote:
| I'm a cynic too, but I'll also be optimistic about
| published statements. Goggle said they're committed to
| supporting 3rd party passkeys when they announced android
| support. Apple, not so much though. I am hoping Google just
| does the right thing and makes this table stakes.
| booi wrote:
| Yeah I fail to see why google would be incentivized to
| provide this functionality.
| gowld wrote:
| EU provides incentive.
| [deleted]
| dotancohen wrote:
| To which law are you referring?
| tick_tock_tick wrote:
| I think they are referring to the EU's aggressive data
| surveillance and zero expectation of privacy to
| government organizations. While the EU has been very pro
| customer to business privacy they are vehemently against
| anything that lets anyone hid anything them the
| government.
| EthanHeilman wrote:
| MPK is really cool.
|
| > What I don't like bout Google doing this is that the big
| providers use this to tether and lock you in to their platform.
| The power of this shines when it's federated. So if you run a
| site, you can provide security to your users without them
| needing Google, FB, etc.
|
| The value of many of these schemes is authenticating under your
| google/FB identity (email, phone number, org affiliations). It
| makes a lot of sense for centralized identity providers to do
| this because they already know who you are and how to
| authenticate you.
|
| There is a growing untapped market for the authentication and
| secure use of of pseudonyms. For instance people that want to
| run a blog and interact in social media under a name that is
| not connected to their true name. Or some Senator wants to play
| video games but might be worried that it looks frivolous. This
| is a setting where something like MPK really shines. I believe
| over the next five years we will see an ecosystem around a
| pseudonymous web. MPK might have just been too early as that
| ecosystem isn't quite here yet.
| djbusby wrote:
| I love this approach.
| mawise wrote:
| What you describe sounds awesome. Is it still something people
| could use? If the WebAuthn protocol gains broader support
| because Google/Apple are pushing passkeys then anything that
| speaks WebAuthn should be a viable option, right?
|
| Disclaimer: I own 2 NFC rings :)
| EGreg wrote:
| Contact me and let's add it to https://qbix.com/platform and
| ecosystem so it is not captured by Big Tech corporations.
|
| We have a lot to talk about and exchange information.
|
| greg at the domain qbix.com
| gowld wrote:
| > greg at the domain qbix.com
|
| I regret to inform you that someone has carelessly or
| maliciously leaked your deobfuscated email address, on the
| site
|
| https://qbix.com/resume.html
| hdiehdis wrote:
| i say this every time this is mentioned... all these thing are
| mostly to help advertisers and fight spam and reduce cost on
| their servers.
|
| theres a million ways to provide this functionality without
| relying on vendor lock in. they are pretty much working as a
| mini certificate authority/vendor.
|
| instead of vetting clients and giving them CAs, they just run
| your credit card for some hardware or subscription, and
| validate your login.
| pphysch wrote:
| > theres a million ways to provide this functionality without
| relying on vendor lock in. they are pretty much working as a
| mini certificate authority/vendor.
|
| Identity systems aren't too technically difficult, the
| challenge is properly rolling them out and getting mass
| adoption. Which means getting vendors/users on board. It's a
| problem solved by power and politics, not technological
| innovation.
| sparkie wrote:
| I recall Mozilla tried something similar around a decade
| ago, which was a good solution but didn't get any adoption.
| There's also been approaches like OpenID which were once
| popular, where you can have a single login, but they have
| the problem of third-parties aggregating the sites you
| visit. Who uses OpenID today? It's all been replaced by
| facebook or google login.
|
| Part of the difficulty of using secure credentials is
| sharing them between devices. It's easier to involve a
| third-party like Google who can do this for you. The big-
| tech doesn't actually want to solve the problem entirely
| because they want some form of control: Either locking you
| into their service, or aggregating the sites you log into,
| or both.
|
| They also want your biometrics, and keep pushing the
| narrative that biometrics are for authentication, but
| biometrics should only represent identity, not authority.
| pphysch wrote:
| > They also want your biometrics, and keep pushing the
| narrative that biometrics are for authentication, but
| biometrics should only represent identity, not authority.
|
| What does "authority" mean here?
| fersarr wrote:
| Cool idea about the NFC ring. Is there anything like that now?
| Any application?
| witcH wrote:
| https://www.tokenring.com/
| r00fus wrote:
| > What I don't like bout Google doing this is that the big
| providers use this to tether and lock you in to their platform.
|
| This is not what they want. They want to a) ensure
| passwords/accounts aren't being shared to ensure a single
| account is tied to a single user. They want this for all apps
| so they can recognize revenue for every user. b) They want more
| information on you as a user (as opposed to your family member
| on the same account). The wet dream is per-device, per-user
| profiles. Possibly even different [additional] costs for each
| attached device.
|
| That is their goal. Big Tech all want this. That it increase
| friction to migrate is a side benefit (honestly not so much
| more than with passwords now). That it happens to benefit users
| is the lure to draw you in.
| donalhunt wrote:
| I think it's simpler than that. Expenditure is linked to
| trust. Companies and platforms that erode trust, make less
| money in the long run - they have to continually exert energy
| to attract customers. Companies / platforms that focus on
| building and retaining your trust have to work less hard to
| have you part with your money.
| waboremo wrote:
| Can you explain how passkeys explicitly reaches that end
| goal, when all of that is already currently possible without
| passkeys?
| jamilton wrote:
| You can share passwords easily, I don't think you can
| trivially share passkeys.
| NikolaNovak wrote:
| Ignorant question:
|
| Are Passkeys, at some level of abstraction, permanently replacing
| "something you know" (password) with "something you have"?
|
| If I am in some kind of calamity (dropped my phone, got robbed,
| etc), and I come to a friendly person's house, it sounds to me
| like I simply would not be able to login to potentially critical
| services, no matter how much I _know_ , because I don't _have_
| anything (the device that passkeys are tied to / on).
|
| Is that true?
|
| And... am I the only person completely dreading this system?
|
| I don't live on my one and only phone; I have two phones, 3-4
| tablets, 4-5 computers I use regularly. Of various operating
| systems, browsers, manufacturers, etc.
|
| I can create a password of arbitrary complexity and security and
| comfortably use all my devices as well as any new device that
| comes my way.
|
| Passkeys sound... like a nightmare?
|
| (they also sound AMAZING to my wife and family... woohoo no
| passwords, I just have to use my phone... until they _INEVITABLY_
| lose or break their phone... and then they 'll come to me and I
| have no idea what to tell them anymore -- all your passkeys were
| on your device and now they're gone forever because Google &
| Apple decided it was better for you, and you did not follow
| obscure methods I frankly cannot help or explain to you to maybe
| possibly back them up, one day, when method exists, to some other
| device)
| dcow wrote:
| I like to explain it like this:
|
| If you use a password manager today, then you're already
| essentially using something you have, because you need to be in
| possession of your login database to retrieve passwords, and
| nobody can remember that in their head.
|
| Passkeys is a formalization of the idea that you should be
| using a password manager where all the passwords are random
| uncrackable 32 character strings, and if we add this constraint
| then we can crazy secure things like employ _asymmetric crypto_
| to prevent phishing and MITM attacks, so woO!.
|
| You are right to be concerned about the whole device thing
| though. Apple addresses this by requiring that you use/enable
| iCloud keychain in order to use passkeys. The generalized
| solution to this is allowing 3rd parties to be your passkey
| provider, so that you can choose how your passkeys are stored
| (cloud synced vs device bound) and e.g. whether you want an
| implementation where you can unlock them with one strong
| something you know, something you are, something your have, or
| any combination thereof, the only limit being the
| features/options the different 3rd party products will offer,
| depending on their target market, etc.
| JohnFen wrote:
| > The generalized solution to this is allowing 3rd parties to
| be your passkey provider, so that you can choose how your
| passkeys are stored
|
| The password manager I use has no cloud component (which is
| why I chose it), and addresses this by allowing me to export
| my password collection to an encrypted backup file.
|
| Would this be a thing that the passkey folks would be OK
| with? That would ease a lot of my hesitation.
| lll-o-lll wrote:
| Yes, it replaces something you know with something you have and
| something you are. The hypothetical scenario you describe is a
| downside.
|
| As to your other concerns. Registering a passkey from each of
| your devices should be a trivial exercise. If you want to play
| with this now, GitHub has good integration (you can keep your
| password, the passkeys you register are just alternative ways
| to access).
|
| For your family, your concerns are not warranted because the
| "cloud backup" is part of the integration. With Apple, as an
| example, the passkeys are tied to your keychain, and changing
| devices/disaster recovery is relatively trivial. The passkeys
| are also accessible from all your Apple devices, so you don't
| have to create separate ones.
| aimor wrote:
| "And... am I the only person completely dreading this system?
| Passkeys sound... like a nightmare?"
|
| It's already a bad dream for me. I can't stand all the 6-digit
| code I have to fetch to do things like: check email, schedule
| appointments, pay bills, just plain buy stuff. I'm glad we're
| long past the days of emailing users forgotten passwords in
| plaintext, but I'd prefer to accept less security for the
| convenience of being able to log into an account without
| proving my identity via phone.
| tomrod wrote:
| Biometrics are not passwords. They are user IDs. I have concerns
| with this approach.
|
| EDIT: Looks like support will be coming to NordPass and other
| password managers soon - https://support.nordpass.com/hc/en-
| us/articles/1298467820264...
| mdswanson wrote:
| Is it just me, or does every "what is a passkey" definition never
| actually define what passkeys are?
| Nextgrid wrote:
| How do you handle delegation in this case? Let's say I want to
| delegate access to my account to a partner/friend/employee on a
| service that doesn't support multiple users per account, charges
| extra for it or outright doesn't want me to delegate access to
| someone else (so it's not always possible to rely on the
| website's cooperation).
|
| Currently I can just message them the password or even write it
| down on a post-it note and they'll have everything they need to
| complete the task as me. How does it work with passkeys? Does the
| spec allow my passkey HSM to securely share the secret by
| encrypting it against the recipient's passkey HSM? Can it use the
| concept of leaf certificates to sign a short-lived certificate
| allowing access to that credential without sharing the
| credential's secret itself?
|
| I can't advocate for passkeys until the concerns above are
| resolved. The push for passkeys seems like yet another attempt to
| remove control from the user.
| arnarbi wrote:
| You can create a passkey for your account on their device, e.g.
| by selecting "Use another device" when creating it, and
| scanning the QR with their phone (their phone does not need to
| be signed in to your account).
|
| And if you both use iOS, you can Airdrop a passkey:
| https://support.apple.com/guide/iphone/share-passkeys-passwo...
| jmbwell wrote:
| The accounts and services I use that support passkeys also
| support some form of account delegation, recovery contacts,
| legacy contacts, or family sharing. This includes Apple,
| Google, Microsoft, and self-hosted services through Authentik,
| Authelia, and Keycloak.
|
| My experience is not necessarily representative, but I am not
| sure how big the issue you describe would be, in practice, for
| the majority of users, who will be, by and large, using one of
| these services.
|
| What is clearly a major issue for the majority of users is
| unauthorized account access and resource theft through the use
| of easily-phished account credentials protected by nothing more
| than a character string being passed around in text messages
| and sticky notes.
| riversflow wrote:
| > What is clearly a major issue for the majority of users is
| unauthorized account access and resource theft through the
| use of easily-phished account credentials protected by
| nothing more than a character string
|
| Is this a major issue though? I think it's pretty minor, not
| being able to share or backup my passwords is a pretty huge
| issue in my books.
| kevincox wrote:
| This is what I love about passwords. They are tangable and
| understandable. I would have loved if we could move towards a
| solution that has the benefits of passkeys (prevents phishing,
| strong secret, doesn't seen the secret to the server) without
| ditching the underlying secret being a somewhat human-readable
| password. It seems that in-browser password-managers get us 99%
| of the way there. I would have loved to do something like
| adding a PAKE system to regular passwords rather than a new
| system built on top of non-human readable keys.
|
| I'm sure we will gain the ability to dump the key to a file or
| write down onto paper at some point but it seems that we are
| starting from the wrong end.
| jmbwell wrote:
| Also tangible and understandable is a registry of users who
| have access to your accounts, that allows you to grant and
| revoke access (at possibly different levels), without having
| to reset all your own credentials.
|
| I've got to quit commenting, but humans are undeniably the
| weakest link in security. While I understand the perceptions
| and even share some of the concerns expressed in this thread
| about the loss of control, reverting to a human-readable
| string as a key would only regress the whole scheme to
| something that is, once again, as easily compromised as a
| system protected only by any other human readable string.
|
| We just have to cultivate new habits. Enroll multiple keys or
| devices. Print the backup codes and put them in the fire safe
| with your birth certificate. Give trusted friends and family
| access to recover your account in the event you lose the
| credentials or get hit by a bus. It's a few extra steps up
| front, but once it's working, it's so much easier.
|
| Honestly, there are so many people who never have any idea
| what their password is, so they end up resetting it all the
| time... passkeys is a net-positive. Now they don't even have
| to remember anything.
| kevincox wrote:
| > It's a few extra steps up front, but once it's working,
| it's so much easier.
|
| It's a few extra steps _per site_. Every time you get a new
| device you need to go back to every site you 've ever
| visited and update the credentials. It is maybe feasible
| for a few important accounts but it doesn't scale.
|
| Whatever solution we have needs to be syncable and able to
| be exported to a safe _once_ and continue to be usable by
| new sites and devices into the future. People aren 't going
| to print out their credential list every month to update
| the fire safe.
| jmbwell wrote:
| The now-unfortunately-named "Password managers" help with
| this by providing various mechanisms to sync keys with
| multiple devices, so that every time you get a new
| device, you simply need to authenticate and transfer the
| key store to the new device.
|
| The device's hardware security facilities are there to
| protect the keystore. They aren't /the/ keystore.
|
| Find a key manager. iCloud Keychain, Microsoft
| Authenticator, Bitwarden, something. Use that. Concerns
| about migrating devices dissolve away.
| JoshTko wrote:
| One weakness with passkeys is that a person can't login to an
| account with just information that they know. I.e. they need a
| authorised device. Given that devices can be lost, it seems that
| folks that only own one device should not use Passkeys. Most
| passkey users should probably have a minimum of three biometric
| enabled - authorized personal devices if they want to use
| passkeys. This might be the biggest roadblock to adoption as few
| have this many personal devices.
| shortcake27 wrote:
| The goal from all vendors is absolutely to have passkeys backed
| up to the cloud. In fact, passkeys on iOS required iCloud
| Keychain to be enabled. Then the only issue is reauthorisation
| with the vendor when the only trusted device is lost. It would
| be surprising if vendors didn't cater for this scenario.
| Lacerda69 wrote:
| passkeys wont be the end of passwords:
| https://www.ory.sh/overview-login-password-passkey-webauthn-...
| red_trumpet wrote:
| > passkeys are resistant to online attacks like phishing, making
| them more secure than things like SMS one-time codes.
|
| What is the scenario in which SMS one-time codes are prone to
| fishing, but passkeys are not?
| neilalexander wrote:
| https://en.wikipedia.org/wiki/SIM_swap_scam
| red_trumpet wrote:
| Yeah okay, but then just don't do 2fa via SMS. How are
| passkeys better than a 2fa app on my smartphone?
| jefftk wrote:
| That is also an issue with 2fa sms, but it's not phishing.
| neilalexander wrote:
| Phishing is quite often how a SIM swap attack starts.
| wepple wrote:
| Passkeys sign a web origin. If you try to phish one, the token
| you get won't be valid for the origin you're trying to
| authenticate to.
|
| Eg you'll get:
|
| Token{domain:hax0r.net username:bob}
| jefftk wrote:
| 1. You're tricked into visiting evil.example and don't realize
| it.
|
| 2. evil.example: confirm 2fa code to log in.
|
| 3. evil.example starts logging into good.example as you,
| triggering good.example to send the 2fa code.
|
| 4. You see the 2fa code and enter it into evil.example.
|
| 5. evil.example has phished your 2fa code.
|
| This doesn't work with passkeys (or 2fa tokens) because those
| verify the domain matches.
| red_trumpet wrote:
| Yes, I understand how phishing with 2fa works. But to me,
| passkeys sound like 2fa with your fingerprint/smartphone PIN?
| What's actually different there?
| jefftk wrote:
| The difference is in step 4. With SMS or one-time code 2FA
| (or passwords) you're just entering text into a website,
| and nothing verifies you're interacting with the right
| website. With passkeys or FIDO tokens, though, there's a
| cryptographic protocol that considers the domain: your
| fingerprint/PIN isn't sent to the website.
| red_trumpet wrote:
| So, evil.example tries to log in and triggers the passkey
| thing on my smartphone. My smartphone asks "Do you want
| to log in to good.example?" Because I'm currently being
| phished and didn't pay attention to the URL
| "evil.example" anyway, I will confirm this on my
| smartphone and evil.example is granted access to my
| account. I don't see how this is more phishing resistant
| than current 2fa. How can my smartphone know whether I'm
| interacting with the correct website on my laptop?
| jefftk wrote:
| This is maybe an oversimplification, but the token that
| your phone gives your laptop includes "only valid for
| good.example". Your browser on your laptop then knows not
| to send it to evil.example.
| friedhelm2000 wrote:
| [dead]
| waldemar69 wrote:
| [dead]
| vorfahrt74 wrote:
| [dead]
| canislupus wrote:
| [dead]
| iLoveOncall wrote:
| > 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.
|
| So, for the vast majority that does not have hardware that
| supports fingerprint reading or face-scanning, this grand new
| alternative to passwords is... passwords?
|
| I get that it's nice for phones, but that's only about 50% of the
| web's traffic.
| Scion9066 wrote:
| If you don't use biometrics then it's passwords or passcodes to
| authenticate to the local device or a secondary device to
| unlock it. After that it uses public key cryptography to do the
| actual authentication with the site you're trying to log into.
| At no point does the site need to have access to anything
| secret, unlike traditional passwords.
| ssss11 wrote:
| If I choose the screen lock PIN example (instead of face scan or
| finger print) why/how is that more secure and less resistant to
| attack than a password?
|
| It's a 4 digit number. What am I missing behind the scenes that
| makes it more secure?
| albybisy wrote:
| the only thing that i don't like about login with passkeys is
| that i need to turn on the bluetooth.
| rainworld wrote:
| See also https://passkeys.directory
| 0xbadcafebee wrote:
| This is a good start, but like everything Google introduces, it's
| only designed to be useful to Google, and has a number of flaws:
|
| - syncs to the cloud without E2E encrypted. there's no reason any
| person should ever put all their private keys somewhere they can
| be stolen without at least a secret master password protecting
| them.
|
| - they're not one standard. web apps will use WebAuthN, non-web
| apps will use a FIDO API. Passkeys are a mix of different
| technologies that is more complex than needed.
|
| - they aren't interoperable with different software and devices.
| Currently, if you make a passkey, it can only work with whatever
| you used to make it. trying to use a passkey on different
| operating systems or apps etc requires manual workarounds,
| exporting/importing, etc.
|
| - different providers have different levels of support. some
| support sign-in, some support MFA, some support both.
|
| - the choice of only being able to use biometrics or a pin to
| protect the passkey store is stupid. you should be able to enter
| in text as well, so you can use a long and complex key to protect
| it, if you want. instead your options are 3 incredibly easy to
| crack methods.
|
| - there isn't an easy way to back up everything offline in case
| your devices get lost.
|
| - all this doesn't address attacks on account recovery, which is
| the most common way to compromise an account (nobody brute-forces
| passwords anymore, with the exception of giant password
| compromises which are used for lateral attacks against other
| services)
| nilsbunger wrote:
| How do you do account recovery if you run a service using
| passkeys?
|
| 1. email-based "reset passkey" flow -- only as secure as the
| email it's sent to, and you need to make sure the email is still
| valid since the user isn't using it regularly as part of their
| auth.
|
| 2. multi-factor "reset passkey" flow -- you have to make sure the
| user has kept multiple factors (eg backup codes) which they're
| mostly not using.
|
| Is there something better? Anyone have a good resource?
| dblitt wrote:
| I still don't understand how the QR code flow works with
| using/creating passkeys on other devices. It seems it uses a
| bluetooth connection to your phone, but I can't find much
| documentation about the exact protocol
| sebk wrote:
| It's called hybrid transport, and the old name for it was
| caBLE. Yubico has a nice explainer here:
| https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows...
| It's not fundamentally different than other transports for
| other roaming authenticators like a USB key; the QR code sets
| up a BLE connection between both devices and presents the
| authenticator with a challenge for it to sign and log in the
| originating device.
| ghancock wrote:
| I wrote about my experience with passkey support on other
| services here: https://news.ycombinator.com/item?id=35758918.
| That experience was mostly negative. For anyone implementing
| this, the user experience matters and requires usability testing
| of a lot of combinations.
|
| In comparison to those, Google's support seems better. It worked,
| was transparent about what was going on, and gave me the option
| to create the key on either the device I was using or another one
| if I wanted. The one hitch was that when I already had a 2FA key
| on the same platform authenticator, it just said I already had a
| registered key on this device and didn't do anything. I would
| have expected some sort of upgrade flow for people who previously
| registered their devices for 2FA, or at least to more directly
| tell me to delete the existing security key on the device (which
| is what I did, and which worked).
| judge2020 wrote:
| > it just said I already had a registered key on this device
|
| Is this Android? Because, before this change, there was no way
| to register a real WebAuthn-based passkey with Google, at least
| when I was trying with chrome (it did not prompt the webauthn
| popup, just the OS-native security key popup).
| ghancock wrote:
| This was on an iPad. My experience before had been that I was
| able to register an iCloud passkey for Google 2SV when using
| Safari on iOS/iPadOS, but I was unable with Chrome.
|
| At that time, I inspected the registration request Google
| sent to Chrome and found it was passing a private option that
| Chrome recognized. According to what I found in web searches
| for it, the option created a legacy U2F key, and they needed
| to do that because there were existing Android devices that
| they could not upgrade and that would not support log-in with
| WebAuthn keys.
| dpedu wrote:
| No thanks. I trust google to a degree, but not that far.
| TulliusCicero wrote:
| Hmm, can I use these passkeys with Brave or other Chromium-based
| browsers?
| eikenberry wrote:
| I'm curious how free software users will be able to take
| advantage of this improved security. Seems tied pretty tightly to
| proprietary systems and I wonder if, as a free software user,
| I'll eventually be locked out of the Google ecosystem.
| 015a wrote:
| I'm curious to get a take on Apple's documentation for passkeys
| and iCloud Keychain Recovery Escrow system [1] [2]
|
| There's multiple references in this documentation to phrases like
| "To sign in for the first time on any new device, two pieces of
| information are required--the Apple ID password and a six-digit
| verification code" or in the no-device-recovery escrow
| documentation: "users must authenticate with their iCloud account
| and password"
|
| I can imagine a world where Apple replaces sign-in passwords with
| passkeys; your devices form a ring of trust which "sponsor" new
| devices into your end-to-end-encrypted iCloud Keychain. But I'm
| having a hard time imagining how zero-device escrow recovery can
| work without a thing-you-know password.
|
| Has Apple spoken specifically on this at all? Do they intend to
| follow the same route as Google and get rid of passwords
| entirely, and if so how are they securing zero-device iCloud
| Keychain recovery? Or will they probably just keep passwords
| around, if only for this specific use-case; and if so, what are
| the implications for functional user security? If I have an Apple
| Password I don't use for ten years, then have to use it that one
| time to complete zero-device recovery, many users won't remember
| it.
|
| [1] https://support.apple.com/en-us/HT213305
|
| [2] https://support.apple.com/guide/security/escrow-security-
| for...
| philistine wrote:
| My presumption has been that they will force a long recovery
| key to be printed by you for recovery OR the enrollment of
| designated trusted users that can approve an account recovery.
|
| They already force you to do either of those things if you want
| end-to-end encryption for all content types (which they called
| increased data protection).
| zug_zug wrote:
| What are the privacy implications for this? Are companies that
| see my passkey going to be able to link it to all my other
| accounts, or will each passkey be completely anonymous?
| echeese wrote:
| Passkeys are unique per Relying Party, in this case, google.com
| can only access passkeys for google.com. They can't even
| enumerate them, all they can do is pop up a dialog and wait for
| the user to select one.
| lxgr wrote:
| WebAuthN is great, but I can't help but feel that Passkeys are
| actually a step backwards.
|
| At least on iOS, there is no way of preventing them from being
| synced to iCloud, which is the opposite of what I want for high-
| stakes credentials like bank accounts or government e-signatures.
|
| I've tried to raise [1] a related issue (i.e. the inability for
| relying parties to opt out of credential syncing, if not an
| explicit requirement to opt in to it) to the W3C WebAuthN working
| group, but it seems like the working group itself is strongly pro
| cloud synchronization as well.
|
| Today, Google has sent me an email about their intention to
| deprecate their (device-bound) iOS authenticator in favor of
| (iCloud-synchronized) Passkeys, and I guess I'll begrudgingly
| have to switch to using an external FIDO authenticator instead.
|
| [1] https://github.com/w3c/webauthn/issues/1714
| sneak wrote:
| You can't even use Passkeys on iOS without using iCloud; if you
| opt out of iCloud, Passkeys are disabled.
| lxgr wrote:
| Apparently so; I just saw that as well (and edited my post).
| Bizarre.
|
| Between that and completely removing anonymous attestation
| (i.e. implicit device binding), it makes me wonder what
| Apple's motives here really are...
| signal11 wrote:
| My cynical assessment of Passkeys is:
|
| If Google/Amazon/Apple/Meta/whoever locks your account out, you
| now lose access everywhere.
|
| This isn't a theoretical risk. You'll see lots of people
| complain about this online.
|
| Also, Passkey providers now get sweet sweet metadata about your
| accounts around the web.
|
| But yeah, authn is hard to do right. Equally, asking your users
| to fall into $BIG_PROVIDER's arms seems wrong.
|
| My personal hope is that various _accountable_ nonprofits will
| begin to offer passkeys.
| [deleted]
| skybrian wrote:
| I don't know about privacy, but the lockout risk doesn't seem
| worse than losing your phone or Yubikey. You should have
| multiple independent ways to log in for any account you care
| about. Passkey will be one way.
|
| Possibly two ways, if you have both Android and iOS devices
| and you register both? (I assume Android and iOS remain
| independent.)
| clnq wrote:
| What if one loses all their devices in a natural disaster,
| a house fire, or burglary, or lost baggage while traveling?
|
| A password is in your head. If you lose that, there's not
| much use for the said password. But otherwise, it's secure.
| And it's pretty secure from an infosec perspective if it's
| a passphrase.
| dotancohen wrote:
| So if passkey is just yet another way to log in, then all
| the security aspects are moot, no? The attacker could still
| attack the other login methods. E.g., even if the passkey
| is a secure surface, it does not replace the insecure
| attack surfaces.
| pas wrote:
| ideally the site requires 2FA for those, or sends a
| confirmation email and makes you wait a few hours, etc.
| hedora wrote:
| Agreed. This whole thing seems incredibly user hostile. At
| the very least, there should be severe legal recourse
| (criminal liability and also large, material-to-earnings
| statutory damages) if one of these providers intentionally
| locks you out of a third-party account.
|
| That third party account should be treated like your personal
| property, and them denying you access to it should be treated
| like their CEO breaking into your house and stealing your
| stuff.
|
| If they don't want to take on the liability, and it kills the
| passkey spec, that's fine with me. The current system avoids
| the issue by allowing people to store credentials in a
| decentralized way.
| lxgr wrote:
| > If Google/Amazon/Apple/Meta/whoever locks your account out,
| you now lose access everywhere.
|
| Fortunately, both iOS and Android also support "detachable
| passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in
| WebAuthN/FIDO parlance).
|
| Unfortunately, only Android is planning to offer [1] a first-
| party Passkey provider API, because that's what I'll probably
| be using 99% of the time (finding my external authenticator
| for every login is frustrating).
|
| > Also, Passkey providers now get sweet sweet metadata about
| your accounts around the web.
|
| To my knowledge, both Google's (for Android) and Apple's sync
| backends are end-to-end encrypted. I'm not sure if that
| includes the metadata as well as the private keys, though.
|
| [1]
| https://developers.google.com/identity/passkeys/supported-
| en...
| signal11 wrote:
| > Fortunately, both iOS and Android also support
| "detachable passkeys" a.k.a. Yubikey and co
|
| That's good to know.
|
| Although my concern would be, that's really good for people
| who use YubiKeys, but regular people won't, and they can
| then get bitten by account lockouts.
|
| Is there something regular users can do to use Passkeys
| (let's say they use Google) _and_ have some recourse if
| Google locks them out?
|
| Also, what happens if they use Android, have no other
| computing device (this is fairly common in some parts of
| the world), and their phone gets stolen?
| waboremo wrote:
| Passkeys don't negate regular account recovery processes.
| Just as if you were to lose your password, you would have
| to talk to support.
| clnq wrote:
| Giving your passwords to a company that cares about money
| more than you is risky. But losing devices with passkeys is a
| big problem too. Even if passkeys are saved to your Google,
| Apple, or Microsoft account, if that account itself is behind
| a passkey, how do you access it if your phone holding the key
| breaks? If a disaster or fire happens, all your devices could
| be gone.
|
| Passwords are good because you remember them in your head, so
| long as the head works, so do the passwords. This might be an
| obvious statement, but it's clear passkey providers kind of
| glance over it.
| wkat4242 wrote:
| Personally I don't want to be dependent on a third party like
| Google or Apple for my identity. That's never going to be
| acceptable.
|
| If they just accept normal Yubikeys (and multiple at a time for
| redundancy) that'd work for me but this passkey stuff where the
| vendor gets to decide things and I don't fully own my
| credentials is just wrong IMO.
|
| I wonder if there's a fully self hosted passkeys option?
|
| I'm also opposed to attestation. With TOTP I can use any app I
| want and back up my keys however I like. But Fido gives a lot
| of control to websites, they can choose what kind of
| authenticators or apps to accept. This can make it too easy to
| get locked into vendor solutions because they are the only ones
| every website trusts.
| lxgr wrote:
| > I wonder if there's a fully self hosted passkeys option?
|
| If external authenticators work for you, physical keys (like
| Yubikey, Solokey etc.) are arguably self-hosted!
|
| For on-device passkeys, at least Android is preparing an API
| for this [1]. I hope that iOS will follow at some point, as
| well as Firefox (which unfortunately has been quite slow to
| adopt all aspects of WebAuthN).
|
| > I'm also opposed to attestation. With TOTP I can use any
| app I want and back up my keys however I like.
|
| In principle I agree, but some service providers like banks
| are legally liable for fraud losses (at least in some
| jurisdictions). I'd say they do have a legitimate interest of
| being able to verify which authenticators they trust.
|
| Of course, it's being already exploited in a pretty much
| expected way: My government offers a (free to end-users, tax
| paid) e-signature solution. They support, among other
| authentication methods, FIDO - but only a very specific
| authenticator, of which the e-signature service provider is
| the exclusive reseller in the country...
|
| [1]
| https://developers.google.com/identity/passkeys/supported-
| en...
| wkat4242 wrote:
| > If external authenticators work for you, physical keys
| (like Yubikey, Solokey etc.) are arguably self-hosted!
|
| Yes. And this is what I do with all my personal stuff
| (though I use the GPG mode on the yubikey, not Fido2). But,
| because a passkey can be backed up, websites targeting
| mainly passkeys will be likely to offer only a single
| authenticator to be enrolled. Of course with hardware
| authenticators that is not going to work. Lose that one and
| you're screwed. This is why multi-authenticator support is
| so important.
|
| > For on-device passkeys, at least Android is preparing an
| API for this
|
| Thanks, I'll have a look at that. I'd want it on the PC too
| though (BSD). But anyway, hopefully it will come. I never
| really looked at it, as for now the website acceptance part
| is still so low that it didn't matter anyway. For the ones
| I use regularly, only Office 365 supports it. I'm not
| interested in the old FIDO MFA mode, only full passwordless
| will do.
|
| > Firefox (which unfortunately has been quite slow to adopt
| all aspects of WebAuthN).
|
| Yes, this is really a PITA now. They really don't seem to
| give a ***, they only offer CTAP2 (full FIDO2 + PIN) mode
| on Windows. Still not working on Mac, Linux, BSD... It's
| been in this sorry state for _years_ now.
|
| > In principle I agree, but some service providers like
| banks are legally liable for fraud losses (at least in some
| jurisdictions). I'd say they do have a legitimate interest
| of being able to verify which authenticators they trust.
|
| Banks here already use their own authenticators which they
| provide anyway, but yeah that's a point. Many other sites
| shouldn't be able to make such decisions though, IMO.
|
| PS: I'm not sure why you are being downvoted, I really
| appreciated your insightful comment. Especially about the
| Android option I wasn't aware of.
| AlexandrB wrote:
| > Today, Google has sent me an email about their intention to
| deprecate their (device-bound) iOS authenticator
|
| Is this the TOTP authenticator app that Google only started
| actively maintaining again in the last year or so? If that's
| the case, that's pretty funny timing.
| toomuchtodo wrote:
| How is this different than a password manager with encrypted
| cloud backup? Your recourse if someone breaks passkeys is
| legal, not technical. Security must be a balance with
| functionality, and this is a huge improvement over passwords.
| (Tangentially, it would be great if we got cryptographic
| digital identity cards like Estonia has for signatures but
| that's more of a long term goal)
|
| Cloud sync (encrypted!) is important because your average user
| needs that convenience and durability of authenticator.
| ris wrote:
| > Tangentially, it would be great if we got cryptographic
| digital identity cards like Estonia has for signatures but
| that's more of a long term goal
|
| Wonderful. Until every second web service starts to require a
| signature from such digital identity ("age verification"
| perhaps?) and that's the end of pseudonymity.
| transpute wrote:
| _> Cloud sync (encrypted!) is important because your average
| user needs that convenience and durability of authenticator_
|
| Local-only iOS+macOS Codebook sync (open-source encrypted! by
| SQLCipher) provides password and TOTP convenience,
| durability, transparency, decentralization and fewer supply
| chain dependencies with one-time purchase. Founded in 2005.
|
| https://www.zetetic.net/codebook
|
| https://github.com/sqlcipher/sqlcipher
| lxgr wrote:
| > password and TOTP convenience
|
| Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys
| implicitly are. (Credentials are bound to a specific RP,
| i.e. it's impossible to accidentally provide one to the
| wrong website or a scammer on the phone.)
| transpute wrote:
| Codebook links passwords to specific websites/RPs. Some
| people don't take phone calls from random callers.
|
| Can Apple allow existing password managers like Codebook
| to manage passkeys and synchronization locally?
| lxgr wrote:
| > Codebook links passwords to specific websites/RPs. Some
| people don't take phone calls from random callers.
|
| Sure, but passwords are still multiple-use, and sometimes
| auto-fill fails (often due to websites actively messing
| with it), requiring me to manually copy-paste the
| password and exposing me to phishing risk, or that of
| insecure/malicious applications on my system sniffing the
| clipboard.
|
| > Can Apple allow existing password managers like
| Codebook to manage passkeys and synchronization locally?
|
| Unfortunately not at the moment. There is some hope
| though, given that Apple has recently added a TOTP API
| for third-party authenticators, but I'm personally not
| holding my breath.
| transpute wrote:
| _> sometimes auto-fill fails_
|
| For those, Safari share sheet -> "Find in Codebook" =
| dialog with URL-matched credentials appearing first.
|
| _> insecure /malicious applications on my system
| sniffing the clipboard_
|
| iOS now requires interactive user consent for apps to
| Paste from clipboard.
| lxgr wrote:
| > iOS now requires interactive user consent for apps to
| Paste from clipboard.
|
| Fortunately it does - a big security win. But
| unfortunately, macOS does not yet, and I'm copy-paste-ing
| passwords there more often.
|
| I'm often wondering if drag and drop of text is actually
| more secure than the pasteboard?
| lxgr wrote:
| The difference is that I can choose my password manager on
| iOS (and thereby pick my desired security level for password
| synchronization or opt out of it completely), but not my
| Passkey synchronization backend: iOS forces these to be
| stored in iCloud Keychain. (Passkeys are unavailable without
| iCloud Keychain [1]!)
|
| Ideally, there would be a per-passkey UI option to opt out of
| synchronization at creation time.
|
| > Security must be a balance with functionality, and this is
| a huge improvement over passwords.
|
| Sure, but I'm somewhat disappointed that the WebAuthN WG
| basically forced this huge change of semantics (it's
| essentially a security vs. availability tradeoff) into
| relying parties without explicitly collecting their opt-in
| beforehand, or even providing an ergonomic way of opting out.
|
| [1] https://support.apple.com/guide/iphone/sign-in-with-
| passkeys...
| toomuchtodo wrote:
| I agree there should be a way to opt out of system level
| ecosystem passkey sync with a big ol' "you're fucked if you
| don't back these up somewhere" click through warning.
| lxgr wrote:
| That's exactly what I want, ideally at a per-passkey
| level.
|
| It should also be able for relying parties to express
| that desire (whether opt-in or opt-out by default). As it
| is, I think it'll just make banks and governments less
| likely to adopt passkeys.
|
| That's sad, because all in all I think WebAuthN has the
| potential to have a very positive impact on security
| globally.
| admax88qqq wrote:
| > The difference is that I can choose my password manager
| on iOS
|
| This is what you expect when you buy into the closed Apple
| ecosystem.
| lxgr wrote:
| Yes, being able to choose my own password manager is
| indeed an important feature to me. I'm pretty sure that
| feature is not unique to closed platforms, though.
| ilyt wrote:
| You're _basically_ complaining that your choice of using
| closed down platforms arrived with delay
| stouset wrote:
| Okay so use a YubiKey?
|
| I must be missing something but I _do not get_ all this
| hand-wringing. Don't like the passkey options from Google
| or Apple? Fine! Use the hardware authenticator you
| absolutely already have if you're the kind of person who
| has these sorts of objections.
| lxgr wrote:
| Sure, I already do that, but why shouldn't there be a
| choice in on-device passkey implementations just like
| there is for password and HOTP/TOTP authenticators?
|
| Your argument sounds a bit like "Don't like Safari? Just
| use a different OS then" in the context of allowing
| browser choice on iOS. There is no technical reason a
| Passkey provider and OS/platform should be necessarily
| bundled.
|
| It would encourage competition in both functionality and
| security, it reduces reliance on a single account your
| entire digital life, it allows niche products to address
| special requirements in all kinds of scenarios...
| stouset wrote:
| > Your argument sounds a bit like "Don't like Safari?
| Just use a different OS then" in the context of allowing
| browser choice on iOS.
|
| Except... you can just use a YubiKey. It's closer to
| saying "install Firefox" than "install a different OS".
|
| > There is no technical reason a Passkey provider and
| OS/platform should be necessarily bundled.
|
| Sure, fine. This is like V1 of every provider's
| implementation. None of this was even available three
| months ago, I have no doubt these things are coming.
| lxgr wrote:
| > Except... you can just use a YubiKey. It's closer to
| saying "install Firefox" than "install a different OS".
|
| No, you're literally recommending I use a separate
| physical device because there is no API to achieve the
| same functionality that the OS provides via their bundled
| implementation.
|
| > Sure, fine. This is like V1 of every provider's
| implementation. None of this was even available three
| months ago, I have no doubt these things are coming.
|
| On iOS, Passkeys have been available for more than half a
| year now. I really hope that Apple will eventually follow
| suit.
| dcow wrote:
| Yeah this is fair. It blows my mind that platform players
| don't understand that the security posture needs to be
| configurable at a per-credential level. The hope would be
| that 3rd parties step in and provide implementations that
| afford these options to users, but that would require
| platform players to stop dragging their feet on allowing PW
| managers to hook in to WebAuthN challenges as a credential
| store/backend.
| sebk wrote:
| For the client-side, the spec is comprehensive in allowing the
| authenticator to decide whether backups are allowed. In this
| case it's iOS not exposing that to you as a user. I get why
| you'd want this, but trusting Apple to store your single-device
| passkeys for high-stakes credentials but not trusting them for
| syncing them is somewhat of a very specific threat model I'd
| say, and definitely not in Apple's own interest to support, to
| your detriment.
|
| RP-side, it's true that RPs can't opt out of credential
| syncing, but I think that would be weak at best, as the
| authenticator can do what it wants. The RP can use attestation
| and the DPK extension to effectively bind authentications to
| the same originating device.
| lxgr wrote:
| > trusting Apple to store your single-device passkeys for
| high-stakes credentials but not trusting them for syncing
| them is somewhat of a very specific threat model I'd say
|
| I don't think it's that specific of a threat model, to be
| honest.
|
| Many people are logged into iCloud on multiple family devices
| - are they aware that with Passkeys, by default every device
| they are logged in to has single-factor access to their
| entire online life?
|
| Additionally, Apple's iCloud security posture has been in the
| news lately with some quite horrible stories that are very
| relevant to Passkeys, in my view:
| https://www.wsj.com/articles/apple-iphone-security-theft-
| pas...
| mmcnickle wrote:
| The linked security blog post[1] has a lot more of the technical
| details and can clear up some of the questions/confusion that
| people have added in the comments.
|
| [1]https://security.googleblog.com/2023/05/so-long-passwords-
| th...
| garganzol wrote:
| Those guys should not work in identity and access areas.
| Period. Only one reason says everything: they provide no
| support. Customers will be left in the cold, minus all their
| belongings.
|
| But they may separate into several companies to avoid conflict
| of interests, if they prefer, this time with proper support and
| everything. Or they can be forced to do so, if they are too
| stubborn and will continue running their dystopian playbooks.
|
| So, the situation is not strictly technical, it's much deeper
| than that. A blog post won't make a dent.
| wepple wrote:
| +1 everyone should read that - 60% of comments on this thread
| are explained away by reading this.
| mihaaly wrote:
| I will never weld my login to a physically so fragile and
| unpredictably high maintenance and volatile thing as a mobile
| phone. It is also cumbersome for casual logins and increadibly
| risky for important ones. Thank you, but no.
|
| (good thing I already started to migrate away from the Google
| universe)
| jrm4 wrote:
| I'm glad most people here are recognizing that this is a stupid,
| stupid idea.
|
| Here is some simple old-school ammo against it (or perhaps in
| favor of it, if they were to be so bold) Some good old-fashioned
| "skin-in-the-game" e.g. Nassim Nicholas Taleb style.
|
| I will gladly use (and pay for!) this, but only with
| _indemnification._
|
| Insure me to the tune of, say, $100,000 in the event of a breach
| or a problem and not only will I use it, I'll pay for it.
|
| Otherwise, no deal. If e.g. Google wouldn't take this theoretical
| (or practical) deal, then they are completely full of it.
| account-5 wrote:
| Nope, passwords stay until passkeys aren't tied to a device that
| can be lost, stolen, or broken. Or you need multiple devices to
| avoid that. And they are offline and not controlled by
| multinational corps only interested in monitoring everything you
| do for profit.
| Am4TIfIsER0ppos wrote:
| fuck off and bring back smtp access!
| CatWChainsaw wrote:
| The technology of passwords has been around for millennia, never
| perfect, not terrible enough to throw out wholesale. As I said
| somewhere else, the democracy of authentication, the best of
| several imperfect options. Certainly I'm not securing anything of
| mine behind my phone (can be broken) or my face (can also be
| broken) on a proprietary system under Google's fickle control,
| when my brain is less likely to be broken (and if it's not, I'll
| have much bigger problems to worry about than getting into my
| accounts).
| eulers_secret wrote:
| I'm a Linux user. I don't have an android/iOS/macOS/Windows
| machine.
|
| Is there a solution? Is this being used to push Linux users off
| the internet? Can I just fire up emulated Android and be ok?
|
| Am I screwed? Googling indicates I am, indeed, screwed. Pretty
| concerned about this future.
| nmca wrote:
| Yubikey is supported; which has linux compatibility.
| vlovich123 wrote:
| Let's say I have a passkey in Chrome and no password. How do I
| add a passkey to iOS so that I can login via both mechanisms?
|
| Is my understanding correct that if I only used Passkeys that I'd
| be permanently locking my account to a third party service to the
| vendor I used to login with in the first place?
| domoritz wrote:
| At least for the Google account, it looks like you can add
| multiple passkeys.
| vlovich123 wrote:
| Sure. But am I still locking my ability to access that
| account permanently to Google? Can I login via Chrome on an
| Apple/Windows platform and add a passkey there?
|
| I'm also a bit worried that this permanently entrenches these
| as the platform vendors because no one is going to port to a
| new platform unless you're already a major tech company
| (maybe).
| ytch wrote:
| For Chrome on desktop OS, it will popup a QR code that you
| can scan it by passkey-registered phone like[1].
|
| If your desktop/laptop has TPM, TrustZone or other similar
| devices, it can register Passkey too.
|
| [1] https://9to5google.com/2022/10/12/android-chrome-
| passkey-sup...
| vlovich123 wrote:
| That's interesting and I think potentially addresses the
| concern. I don't think I've seen Apple have a QR scanning
| code option for passcodes but it's possible that's just
| integrated into normal QR in-camera. Apple doesn't have a
| QR export does it?
|
| What would be nicer if there's a way to do this in Chrome
| on mobile. I'm not always near a computer although I'm
| reality that's probably when I'd be adding the passkey
| via chrome.
| CharlesW wrote:
| > _I don't think I've seen Apple have a QR scanning code
| option for passcodes but it's possible that's just
| integrated into normal QR in-camera._
|
| Exactly -- I just did this, and it's that simple.
| barkerja wrote:
| Google actually outlines that very scenario near the bottom
| of their announcement:
|
| > Using passkeys does not mean that you have to use your
| phone every time you sign in. If you use multiple devices,
| e.g. a laptop, a PC or a tablet, you can create a passkey
| for each one. In addition, some platforms securely back
| your passkeys up and sync them to other devices you own.
| For example, if you create a passkey on your iPhone, that
| passkey will also be available on your other Apple devices
| if they are signed in to the same iCloud account. This
| protects you from being locked out of your account in case
| you lose your devices, and makes it easier for you to
| upgrade from one device to another.
|
| > If you want to sign in on a new device for the first
| time, or temporarily use someone else's device, you can use
| a passkey stored on your phone to do so. On the new device,
| you'd just select the option to "use a passkey from another
| device" and follow the prompts. This does not automatically
| transfer the passkey to the new device, it only uses your
| phone's screen lock and proximity to approve a one-time
| sign-in. If the new device supports storing its own
| passkeys, we will ask separately if you want to create one
| there.
| kps wrote:
| > If you want to sign in on a new device for the first
| time, or temporarily use someone else's device, you can
| use a passkey stored on your phone to do so.
|
| No lock-in; you have _two_ phone OS vendors to choose
| from!
| alwaysbeconsing wrote:
| > that passkey will also be available on your other Apple
| devices if they are signed in to the same iCloud account
|
| I am not sure I like this. Unless the passkeys are only
| transferred directly device-to-device, each OS vendor's
| user cloud storage now becomes the keys-to-every-kingdom
| uber-target.
| barkerja wrote:
| If that is a concern of yours, there is an option on
| Apple devices to disable iCloud syncing for
| passwords/credentials. This would limit passkeys to
| strictly device-only.
| neilalexander wrote:
| > For example, if you create a passkey on your iPhone,
| that passkey will also be available on your other Apple
| devices if they are signed in to the same iCloud account.
|
| In addition to this, you can AirDrop a passkey from one
| device to another, even if they don't belong to the same
| iCloud account.
| vlovich123 wrote:
| All of that just locks you into Apple's platform and now
| I have a problem copying that passkey to chrome.
|
| However, a sibling commenter mentioned QR code
| export/import. That would alleviate the concern and be
| even more elegant, especially if it automatically created
| a new passkey registration instead of just copying it
| around.
| judge2020 wrote:
| AFAIK QR code export is not a thing, just speculation for
| how passkey exports could work (which I doubt since QR
| codes get hard to scan the more data you pack into them;
| maybe you could ask the user to hold the camera to the
| screen for a minute while the target machine cycles
| through each passkey, or cycles through qr code data
| itself to facilitate error correction and 100% data
| transfers)
| vlovich123 wrote:
| Seems to be a thing on Android/Chrome:
|
| https://news.ycombinator.com/threads?id=vlovich123#358025
| 11
| warkdarrior wrote:
| You are confusing the location where passkeys are stored
| (your Android, your iPhone, your Yubikey) and where they
| can be used (to access your Gmail account).
| alwaysbeconsing wrote:
| I don't think they are; they're effectively asking
| whether accounts will support multiple passkeys. This is
| a reasonable question IMO: if the protocol is not well-
| designed different services (account providers) may have
| different rules about how many passkeys can be attached
| to your account in their system. (E.g. "2 passkeys ought
| to be enough for anybody!") And for how they can be
| managed: removed and updated, particularly.
| aboringusername wrote:
| What are the legal implications of passkeys? Are there any case
| law examples yet?
|
| My understanding is it's 100% impossible to 'prove' I know a
| password or not as it could be written on a piece of paper
| somewhere, and it's entirely possible for that paper to be
| shredded and therefore any proof of that password is gone,
| forever. I remember hearing you cannot be compelled to hand over
| a password.
|
| Biometrics et al on the other hand? Could/would a judge compel
| those to be disclosed? I saw a video of a police officer forcing
| somebody to use their face to unlock their phone to delete a
| video. With a password, this would be 100% impossible.
|
| So yeah, think about that BEFORE using.
| Scion9066 wrote:
| You don't have to enable the biometric part of this as you can
| still protect your device with a passcode/password only if you
| want. I just tested it and was able to use it with just my
| device PIN, no biometrics.
|
| The part about not being able to be compelled to hand over a
| password or decrypt something is also not true in many parts of
| the world. See:
| https://en.wikipedia.org/wiki/Key_disclosure_law
| bobsoap wrote:
| Ok, Google. I'll bite.
|
| So you send me an email today titled "[Update] Google passkey
| support will replace your built-in security key starting May 3,
| 2023". It was in my spam folder, but I digress.
|
| This "update" kindly informs me that "Passkey support will be
| integrated because they're easier to use" [sic], that it's safer
| than most other forms of 2-SV, that this new method will work on
| any devices that have registered passkeys, which includes all
| phones on which I'm signed in, that I'll be able to sign in to my
| Google account with just a passkey, that no action is required
| from me to do this, and that you're here to help.
|
| Yes, Google, I'd like some help. For starters, I'd like to know:
|
| - What do you mean by "built-in security key"? Built-in suggests
| hardware, so my phone presumably has a hardware security chip and
| now passkey is a new type of hardware chip for authentication?
|
| - What's 2-SV? Two Sievert? Dos El Salvador? Double Support
| Vector? Second Silicon Valley?
|
| - What the heck is a passkey?
|
| Luckily, you provide a link to your HC article [1], which I click
| on. It's titled "Sign in with a passkey instead of a password".
| It helpfully informs me that with a passkey, I can sign in to my
| Google account with my fingerprint/face scan/device screen lock
| like a PIN. There's a bunch of other valuable information in that
| article, like how it won't work in Firefox, won't work in
| incognito mode, that Bluetooth must be enabled, and that anyone
| who manages to unlock my device gets full access to my account.
| Needless to say, sounds totally awesome, I'm sold!!1
|
| What the heck is a passkey?
|
| Is it like the thing that sometimes uses my Android phone as a
| 2FA device to sign into Google properties, just... somehow
| different? What's the difference, except that I now need to
| enable Bluetooth and can't use it in Firefox? How is it more
| secure than [something I know + something I own] if it removes
| [something I know] from the equation and only leaves me with one
| of the two factors? How is it more secure than Dos El Salvador?
|
| Who the heck wrote this email?
|
| [1] https://support.google.com/accounts/answer/13548313
| sys32768 wrote:
| Can we call it something other than passkey? That sounds
| suspiciously like password, but makes me picture a key fob.
|
| Biometics? Authentication device?
| Scion9066 wrote:
| Pretty sure that's intentional. It's replacing something you
| know (a word) with something you have (a key stored on a device
| or some kind of account).
|
| It doesn't necessarily need to use biometrics or be bound to a
| specific device, so those aren't quite accurate. Thus, passkey.
| hunter2_ wrote:
| Came to HN today figuring there would be a thread about this,
| after getting an email about it from Google themselves, riddled
| with things causing me to wonder if the message was spoofed:
|
| 1. "Dear User" -- other emails I've gotten from Google say
| "Hello" or "Hi <firstname>" or have no salutation at all.
|
| 2. The main section begins with "Passkey support will be
| integrated because they're easier to use, and safer than most
| other forms of 2-SV." -- The plural antecedent of "they're" is
| merely implied (the literal plural antecedent "passkeys" isn't
| actually written).
|
| 3. In that same sentence, the comma before "and" is grammatically
| incorrect. The comma should not exist, or it should be followed
| by a complete sentence. The same comma rule is also violated in a
| later sentence: "You won't need to enter a password to sign in to
| your account, or to select only a single phone to use as your
| built-in security key any longer."
|
| I'm not really a huge stickler for grammar, but I've seen
| countless "how to spot phishing" guides specifically suggesting
| that we look for grammatical mistakes, as they're specifically
| included for purposes of improving the ratio of hooked phish to
| eaten phish, so it follows that messages which aren't phishing
| really ought to use correct grammar!
| nobody9999 wrote:
| >I'm not really a huge stickler for grammar, but I've seen
| countless "how to spot phishing" guides specifically suggesting
| that we look for grammatical mistakes, as they're specifically
| included for purposes of improving the ratio of hooked phish to
| eaten phish, so it follows that messages which aren't phishing
| really ought to use correct grammar!
|
| Lily Tomlin & co. _could_ have made this[0] for Google today,
| instead of for AT &T ~50 years ago.
|
| The dynamics haven't changed, just the corporations involved.
| And more's the pity.
|
| [0] https://vimeo.com/355556831
| tialaramex wrote:
| > I've seen countless "how to spot phishing" guides
|
| One of the things you'd see those guides mention _a lot_ is the
| call to action. The bad guys want you to do something for them,
| otherwise they wouldn 't send you email.
|
| In contrast the Google email you're complaining about says, "No
| action is required from you" which is my favourite type of
| letter from every company. Can I forget all about this and take
| no action? You bet I can.
| SheinhardtWigCo wrote:
| Users pay a subtle price for the perceived convenience of
| passkeys when it's time to migrate to another platform.
|
| Before, you could just sign in to your password manager on the
| new platform, and get a 2FA prompt the first time you sign in to
| any particular site (so you're manually entering one additional
| factor per site). With passkeys, you have to do account
| _recovery_ , so you have to manually provide two factors per
| site. That translates to hours of cumulative extra work.
|
| It's an opportunity to increase platform stickiness, backed by a
| flimsy security excuse. Nobody using a password manager is
| getting their accounts hacked unless the vendor is breached or
| they have malware on their system. Passkeys don't help in either
| scenario. And the UX isn't materially better than the built-in
| password manager, though I guess that's a matter of opinion.
| RobotToaster wrote:
| Doesn't this just mean giving control of authentication to
| proprietary systems like google?
|
| I can't find a single FIDO level 2 (or higher) certified
| implementation that is open source?
| breakingrules wrote:
| [dead]
| Armic wrote:
| What happens if you lose all your hardware factors (eg if you
| have a home fire)? Are you just locked out of all your accounts
| with this approach?
| barkerja wrote:
| Not if the Passkey was synced (ex: you used iCloud keychain).
| If the passkey was not synced, then I would have to assume it
| would be the same if you lost a physical hardware key.
| Gasp0de wrote:
| How do you access iCloud without your passkey?
| AlexandrB wrote:
| Complain loudly on Twitter and hope your tweet goes viral.
| warkdarrior wrote:
| Call Tim, he'll vouch for you.
| ezfe wrote:
| Apple account recovery supports setting a recovery code or
| having a friend listed as a recovery contact.
|
| Apple does not yet support Passkey for iCloud accounts
| login.
| barkerja wrote:
| I use a yubikey. But AFAIK, Apple doesn't actually use
| passkeys for iCloud/Apple ID authentication.
| jamesdepp wrote:
| Until there is a viable way to sync passkeys between all devices,
| all platforms, and all browsers, I will be happily sticking to my
| passwords. The security benefits provided by passkeys are not
| enough to offset the ecosystem lock-in that passkeys cause.
| CharlesW wrote:
| What ecosystem lock-in are you talking about, exactly? I just
| created a passkey for Chrome on my macOS desktop and another on
| iOS. The Chrome passkey will sync to Chrome for Windows, my iOS
| passkey will sync to my other Apple devices, and I can create
| more as needed.
| teeray wrote:
| I really wish these "password killers" would acknowledge that we
| will _never_ eliminate passwords. Ever. There's too many under-
| funded applications deployed out there that have no resources to
| add passkey support. Password managers are an excellent place to
| progressively enhance the user authentication story and could
| support more advanced schemes like passkeys while remaining
| compatible with the registry of deeds site from 1999. Instead,
| it's always presented as some other thing (usually conveniently
| tied to Chrome) that you have in lieu of your password manager.
| awaythrow98765 wrote:
| Actually I'd see a future where some of those password killers
| might replace passwords, even for some of the under-funded,
| under-manned applications out there.
|
| What is necessary is a robust, simple-to-integrate standard for
| authentication, authorization and sessions built into HTTP.
| Such that all the "hard work" is integrated into common HTTP
| server software or load balancers, transparently. From an
| application perspective it should just look like your request
| getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar"
| HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP
| basic or negotiate auth, but with a few more necessary features
| such as session, login/out and a permission model. Browsers
| would have to provide some proper UI for that, not utter crap
| like they currently do for HTTP basic or negotiate auth.
|
| Then your centralized auth application can just talk to any old
| application in a very simple way, no need to deal with huge
| integration headaches like OAuth or stuff. And the centralized
| auth application can do all the fancy password killer, 2FA,
| magic or whatever special auth you need.
| ilyt wrote:
| Yeah, none of big tech wants that, they don't want to make it
| easy for 3rd party.
|
| Ideally there would just be standarized interface between
| "credential manager" and applications + some OS-enforced
| security (so password manager knows which PID sent the question
| about password or other type of credential).
|
| Then we could have say pub/privkey or cert based authentication
| implemented there, app just asks for a credential for a site
| and cred manager asks user whether to allow it once or forever,
| and which credential to give.
|
| The app then could garnish that with extra metadata so say
| firefox container feature, or different firefox profile could
| attach metadata about from which container or profile the
| request comes from, and credential manager could hand out
| different credentials based on from where it came.
| lxgr wrote:
| > Yeah, none of big tech wants that, they don't want to make
| it easy for 3rd party.
|
| iOS has an API for password managers and HOTP/TOTP
| authenticators. Android is planning to introduce one for
| passkeys.
| Gasp0de wrote:
| There is a legal advantage that passwords have that passkeys and
| FIDO and so on do not have. In civilized countries, no one can
| force you to hand over a password (as you have a right to not
| incriminate yourself). That does not hold for property which can
| be confiscated or even biometric attributes which can be taken
| against your will legally.
|
| Theoretically, passkeys could still offer this advantage if they
| are stored exclusively on my phone which is encrypted and secured
| with a password.
| oasisbob wrote:
| > In civilized countries, no one can force you to hand over a
| password (as you have a right to not incriminate yourself).
|
| Which countries?
|
| In the US, the intersection between 5th amendment rights and
| password disclosure is not complete. You can be forced to
| disclose a password in certain circumstances here.
| stinkytaco wrote:
| I think in Florida v. Voigt someone was sentenced to 6 months
| for not handing their iPhone password in an extortion case.
| If I recall, the phone was ultimately hacked to get the
| evidence.
| croes wrote:
| And if you don't comply?
|
| With biometric data like FaceId or fingerprint it's easier
| for them to get access.
| __turbobrew__ wrote:
| In Canada it has been upheld that you cannot be compelled to
| divulge your passwords as it violates the Charter of Rights
| and Freedoms.
| sixstringtheory wrote:
| This was not my understanding so I looked it up and found
| this: https://www.reuters.com/business/legal/us-supreme-
| court-nixe...
|
| Wherein it mentions passwords are considered testimonial and
| therefore protected by the 5th, but device passcodes were
| ruled to be exempted under the "forgone conclusion" exception
| to the 5th (TIL about that).
|
| Is this kind of thing you are referring to?
| themoonisachees wrote:
| Pretty much only the US explicits this right. I know France
| tacks on more charges to protesters who refuse to unlock
| their phones when arrested.
| Hamuko wrote:
| Has that been tested with the ECJ yet?
| 015a wrote:
| As opposed to where you store your passwords? I can only speak
| for me, but they're in 1Password; if the police get my phone,
| the same thing protects 1Password as would protect these
| passkey private keys: FaceID, maybe a PIN if a lockout can be
| triggered before they get it, and at its core, the Secure
| Enclave. There's no legal advantage to passwords, unless you
| were actually memorizing every password you've got (and if
| that's the case, son we got bigger fish to fry).
|
| A ton of people in our bubble have this Mission Impossible-
| esque view of their security footprint, which simply isn't true
| in reality. Its XKCD 538 every time this comes up.
| lxgr wrote:
| Passkeys are an authentication mechanism, and as such replace
| (authentication) passwords, not (encryption) passphrases.
|
| A password (at least as I understand the term) is used to
| authenticate to some third-party entity to get access to your
| data or services. The (implied or legal) contract here is:
| "Only give access to my data to anybody that can provide my
| password."
|
| Government authorities can in most cases just go to the service
| and demand that access legally; there is no need to get your
| password through whatever means.
|
| A passphrase, on the other hand, can be used to encrypt your
| data directly, and the service provider might not be able to
| hand over your data to the authorities without it.
| angry_octet wrote:
| This is incorrect because you're conflating access by request
| and access with a court order. Without a warrant, or even
| probable cause, police can get some meta data, but not
| everything in the cloud. In many places police can force you
| to use biometrics to unlock devices, but not compel a
| passphrase. (Passphrases are significantly harder for e.g.
| Greykey to glitch brute force than PINs.)
| lxgr wrote:
| What's "access by request"?
|
| > Passphrases are significantly harder for e.g. Greykey to
| glitch brute force than PINs.
|
| PINs are their own thing, i.e. neither passwords nor
| passphrases. They form a hierarchy:
|
| Passphrases: High (enough) entropy; can be stretched into
| an encryption key using a PBKDF.
|
| Passwords: Medium entropy; long enough to be somewhat
| brute-force resistant in case of a database breach. Can't
| really be used to encrypt data by themselves.
|
| PINs: Very low entropy, must be part of a larger, trusted
| system that can reliably enforce limits on invalid PIN
| attempts. Practically, this means tamper-resistant
| hardware, e.g. a HSM, TPM, smartcard, Yubikey...
| ilyt wrote:
| Great! Where I can type those passhphrase in google mail or
| o365 or million other serivces to secure my data ?
|
| Oh? Nowhere? Then why you're even talking about the
| distinction ?
|
| Also passphrase definition is definitely not "a password used
| for encryption", I dunno where you pulled that from. Original
| meaning is just "longer, more secure password"
| lxgr wrote:
| > Then why you're even talking about the distinction ?
|
| GP was talking about the legal implications of using a
| hardware authenticator vs. a password.
|
| > Original meaning is just "longer, more secure password"
|
| And where do you usually need a longer, more secure
| password? Encryption (as opposed to authentication, where
| you can often rate-limit attempts) immediately comes to
| mind.
|
| > I dunno where you pulled that from.
|
| From https://en.wikipedia.org/wiki/Passphrase:
|
| [...] , especially those that derive an encryption key from
| a passphrase [...]
| kmlx wrote:
| i've got passkeys enabled on github, cloudflare, google, twitter
| etc via apple's passkey implementation
| (https://support.apple.com/en-
| gb/guide/iphone/iphf538ea8d0/io...). they all implemented
| passkeys as an alternative to sms OTP. very easy to use, and
| should be better than sms, but still haven't seen full on login
| using passkeys. if anyone knows of such a site i'm curios how
| they implemented it.
| blep-arsh wrote:
| It seems there's no way to prevent an Android device from
| creating and registering a passkey when signing in to a Google
| account on the device. Also, once you opt in, there's no way to
| opt out of using passkeys except by signing out of all Android
| devices. Great. Entrusting my Google account to my Fiio MP3
| player for safekeeping was exactly what I was looking for.
| Phemist wrote:
| Argh.
|
| Passwords are amazing. I loathe many of the attempts at replacing
| them simply because the _average_ user has proven to be unable to
| manage them.
|
| The three factors of authentication are a thing because they all
| protect against somewhat orthogonal threat vectors.
|
| Possession "have" is nice because it binds the authentication to
| a single thing in the real world (as opposed to some digital
| thing that can be copied endlessly). Biometrics, if nice, is
| something that is relatively unique and always carried with you
| (mostly identification), and bind the factor to a person, secrets
| like passwords are nice because they essentially bind the factor
| to the intent, in that a user displays their secret behaviour (of
| which passwords are one) as opposed to not displaying the
| behaviour.
|
| Articles that solely focus on the downsides of passwords, often
| neglect downsides of the other factor types. What are ways the
| strong personal binding of the "are" factor can be abused if
| there is no intent? FaceID/TouchID on sleeping or otherwise
| inattentive persons is a prime one.
|
| All factor-types can work in ways that complement eachother.
| Removing or at least weakening passwords is not a good way
| forward, we need to work on fusing all the factor-types jnto a
| single strong 3-factor auth
| breakingrules wrote:
| [dead]
| 2OEH8eoCRo0 wrote:
| When a company rolls out something new and exciting that will
| improve your life, ask yourself: why are they spending money on
| this?
|
| Just stuffing more of our private lives into phones full of ads
| and tracking. Each time you unlock your phone Google makes money.
| AlexandrB wrote:
| There _is_ a less sinister motive available - reducing customer
| support costs - but the default of syncing everything to the
| cloud does give me pause.
| organman91 wrote:
| It looks like this is a wrapper around public/private keys stored
| on a device: https://security.googleblog.com/2023/05/so-long-
| passwords-th...
| chunk_waffle wrote:
| Forgive me if I sound dense but you would still want a password
| to unlock the private key, right? Otherwise, authentication is
| just "something you have" not "something you know + something you
| have." In which case, this headline might really mean "The
| beginning of the end of the password on the web".
| jesterpm wrote:
| I don't use my google account for much anymore, but I love the
| idea. I tried very hard to use it and... it didn't work.
|
| I went to my google account and clicked "Create a passkey", but
| apparent my "device doesn't support creating passkeys" (Linux,
| Firefox).
|
| The page said my Pixel 2 has an automatically created passkey, so
| maybe I could experience the "use another device to sign in"
| flow. Opened a private window and my only option was a password
| (but there was a feedback prompt asking why I still wanted to use
| a password).
|
| I tried again with Firefox on Android, but the "Create a passkey"
| button doesn't even appear. Same story with Chrome on Android.
|
| Is it just me, or does the future look a lot like Internet
| Explorer in the early 2000s?
| XorNot wrote:
| I hate this, I hate every part of this.
|
| The attempt to get rid of passwords has been the biggest assault
| on the free internet in recent history, and people are asleep at
| the wheel as it's happening.
|
| They want to tie you to an external service, so they can tie you
| to your phone, which they also manage with another external
| service.
|
| All of these schemes are braindead with obtuse, user-unfriendly
| backup/transfer/restore options. They fail at even making things
| "simple" for _regular_ users.
| ghaff wrote:
| Passwords are terrible for a world where people have hundreds
| of them and are lazy. And password managers are a bandaid
| solution.
|
| Arguing effectively that passwords were fine for computing in
| 1970 isn't an answer. So if you don't like passkeys it's
| reasonable to ask for your alternative.
| garganzol wrote:
| Whatever an alternative would be, it should be decentralized.
| photochemsyn wrote:
| The first point seems correct, the second seems incorrect.
| Remembering a single password for access to a secure well-
| designed password manager seems a bit more secure than a
| physical passkey, what am I missing?
| ghaff wrote:
| Because password managers that you (and many others) use
| all the time are probably a more serious attack vector than
| your bank deposit box.
| asimpletune wrote:
| But you still need a password to use a passkey right? So
| passwords aren't going away, they're just being used to a more
| secure way.
|
| My mom can't tell if a website is fake if it's made to look
| exactly like Facebook, for example. So in a sense passwords are
| actually awful for users because they're required to remember
| dozens of passwords and verify that a website is legit. If they
| just reuse the same password everywhere then they are
| vulnerable to another kind of attack because some website
| somewhere will mishandle it, forcing her to change every
| password on every site afterward.
|
| Instead, she can have the best of both worlds by remembering
| one master password, that basically opens a magic app that will
| check that the website is legit and create/retrieve a unique
| passkey for each login.
| eviks wrote:
| > remember dozens of passwords and verify that a website is
| legit
|
| Or use a password manager to solve both of these issues
|
| Except you're not tied to a magic phone
| ajmarsh wrote:
| Nothing prevents anyone from creating an open-source
| implementation of the FIDO server/services.
|
| For example: https://github.com/StrongKey/fido2
| bsenftner wrote:
| This is the truth.
|
| If this Passkey sounds like a good idea, you've been
| propagandized to be yet another stupid lemming.
| [deleted]
| jmull wrote:
| To avoid being a propagandized lemming you have to have a
| basic understanding of what is happening...
|
| passkeys aren't tied to Google or to any other specific
| provider. Note that this announcement is just about Google
| supporting logging to with passkeys to their platform. But
| you don't have to have anything to do with Google to use
| passkeys with other sites/apps that support them.
| garganzol wrote:
| Disguising a proprietary development under an industry
| standard umbrella is a typical move from Corporate Utopia
| playbook. That's why it is so easy to spot when somebody
| tries to manipulate public opinion using social media
| accounts.
|
| It would be a totally different situation if customers were
| actually interested in a particular solution. Otherwise,
| it's all astroturfing and nothing can really change that.
|
| Also it's always a good tone to put a disclaimer, e.g.
| "Googler".
| cromwellian wrote:
| Ex-Googler, laid off, so no allegiance.
|
| It's not a proprietary development. The intention to use
| private keys for authentication goes all the way back to
| the KEYGEN tag in HTML. WebAuthn started from FIDO, not
| Google, and FIDO Alliance was started in 2012 by PayPal,
| Lenovo, and others, not Google, Apple, etc. Google joined
| in 2013, and they were mostly interested in 2FA at that
| point. And prior to that, when I worked at IBM TJ Watson
| in the 90s on some of the first TPMs, we were developing
| passkey equivalents using public key crypto for login and
| digital signatures on ThinkPads and RS/6000 workstations.
|
| This work, desire to use public key crypto for
| authentication, goes back A LONG time practically before
| the internet was taken over by corporations.
|
| This is a good thing for the public. Passwords _suck_.
| The number of people who have been pwn3d and phished due
| to passwords is insane, they 're user hostile in so many
| ways "It would be a totally different situation if
| customers were actually interested in a particular
| solution", are customers actually interested in
| constantly logging in with password and SMS codes -- the
| default today. Does anyone love using authenticators, or
| Apple 2FA popups, security keys?
| garganzol wrote:
| Thank you for sharing the historical context. So, I have
| to wear off my tin foil hat, at least for today.
| jmull wrote:
| > Disguising a proprietary development under an industry
| standard umbrella is a typical move from Corporate Utopia
| playbook.
|
| OK, but is that what's going on here?
|
| There's the suggestion in this part of the thread that
| somehow this all inhibits user freedom. But these
| objections appear to come out of complete ignorance of
| what is actually happening. I'm pointing it out because
| it's the people who are most concerned about corporate
| manipulation that need to understand what's happening to
| have any idea on how to guard against it.
|
| > Also it's always a good tone to put a disclaimer, e.g.
| "Googler".
|
| I guess you're suggesting I'm a Google shill? Well, (1)
| you're wrong (in fact, I got rid of all the Google things
| I used to use personally); (2) did I even say anything
| helpful to Google?
|
| I suggest to take off the tin-foil hat of paranoia. It's
| not going to protect you from anything and, in fact, will
| make you more vulnerable if you let it cause you to focus
| on the wrong things.
| Pxtl wrote:
| Okay, but the alternative is users managing a separate password
| for every service, which is impossible to do securely without
| using a password-manager, and the password-manager is basically
| a weaker version of an external service like Google's.
| [deleted]
| recursive wrote:
| Weaker? The UX for signing in on a new device seems better.
| Maybe that's the same thing as weaker. I'm not seeing any
| reason in all of this to switch from a password manager
| though.
| neilalexander wrote:
| Nothing about this is tied to phones or external services. You
| could just use a hardware authenticator (like a YubiKey) as a
| device-bound passkey if that is what you prefer.
| lazyeye wrote:
| More Google tracking.
|
| I wonder if they get your device fingerprint on login too.
| alberth wrote:
| Dumb questions:
|
| 1. what's the backup login mechanism when you lose your mobile
| device?
|
| 2. with Passkeys enabled/used, will this stop google from
| randomly locking my account because I happen to be a person who
| travels a lot and they constantly think I'm a fraudster
| attempting to log into my own account.
|
| 3a. can I use my google passkey for logging into non-Google
| sites?
|
| 3b. can I use my google passkey (biometric) to log into sites
| that don't accept "Sign in with Google"? (meaning, other sites
| tap into my same enrolled passkey biometric)
|
| 4a. is the way to think about Passkey is that, it's basically
| turning your mobile device into an open-standard Yubikey?
| (meaning, Yubikey is a hardware biometric that you need to be in
| possession of to login. Passkeys turns your mobile phone to
| functionally perform the equivalent of Yubikey)
|
| 4b. Or is the way to think about passkeys is that's it's
| effectively just a password manager (like 1Password) that you use
| your biometric to unlock?
|
| 5. is FaceID a "passkey"?
|
| 6a. can a Passkey be paired with a mobile Drivers license, to
| effectively create an eID?
|
| 6b. if so, would this be a competitive threat to all the KYC
| offerings that exist in the world (because now you have a
| verified biometric login that can be used for new account
| openings)?
| jmholla wrote:
| Here's what Google has to say [0]:
|
| > Passkeys use public key cryptography. Public key cryptography
| reduces the threat from potential data breaches. When a user
| creates a passkey with a site or application, this generates a
| public-private key pair on the user's device. Only the public
| key is stored by the site, but this alone is useless to an
| attacker. An attacker can't derive the user's private key from
| the data stored on the server, which is required to complete
| authentication. > Because passkeys are bound to a website or
| app's identity, they're safe from phishing attacks. The browser
| and operating system ensure that a passkey can only be used
| with the website or app that created them. This frees users
| from being responsible for signing in to the genuine website or
| app.
|
| Two is already handled by a good password manager (which every
| announcement of passkeys leaves out), so the real benefits are
| in one. Instead of providing the same password each time, you
| prove that you have your private key in a way only that website
| (or whatever holds the public key) can ask.
|
| Among the many issues, I think the biggest is that this
| functionality is being locked behind these large corporations
| as gate keepers. Is anyone aware of any open source, self-
| hostable work to provide passkey functionality?
|
| It seems to me not all of it could be since some
| implementations will require that you prove your private key is
| stored by a special chips that can be attested which you
| necessarily can't muck with or reproduce (at least without a
| lot of effort and maybe running afoul of laws). And there's
| nothing that guarantees that your keys can be take elsewhere
| unlike passwords which you can do whatever you want with.
|
| Something else to keep in mind, when they talk about the
| guarantees of passkeys, they're talking about several other
| layers of technology. That's why password managers already
| offer a lot of the security being touted.
|
| [0]: https://developers.google.com/identity/passkeys
| lxgr wrote:
| > 1. what's the backup login mechanism when you lose your
| mobile device?
|
| Passkeys are synced to the cloud by default on iOS and Android,
| which is probably a good idea for many use cases, but might not
| be what you want in some instances.
|
| > will this stop google from randomly locking my account
| because I happen to be a person who travels a lot and they
| constantly think I'm a fraudster attempting to log into my own
| account.
|
| Probably not, but it will make it much easier to log back in -
| you won't even need to type your password if you use a 2FA-
| capable authenticator/passkey.
|
| > 3a. can I use my google passkey for logging into non-Google
| sites?
|
| No, a Passkey is bound to a website. But you can create as many
| of these as you want.
| InCityDreams wrote:
| >Passkeys are synced to the cloud by default on iOS and
| Android, which is probably a good idea for many use cases,
|
| Gtfo.
| clnq wrote:
| > Passkeys are synced to the cloud by default on iOS and
| Android, which is probably a good idea for many use cases,
| but might not be what you want in some instances.
|
| Okay, but Google is suggesting logging into their account
| with a passkey, so how do I access the cloud if I lose the
| devices with my Google passkey?
| hedora wrote:
| Like the commenter you are responding to, I still don't
| understand how any of this can possibly work in practice.
|
| > Passkeys are synced to the cloud by default on iOS and
| Android, which is probably a good idea for many use cases,
| but might not be what you want in some instances.
|
| OK, so how do I use my cloud synced passkey to log on to my
| Google account (which no longer has a password or other
| secret that I can back up locally) after I lose my phone?
|
| > Probably not, but it will make it much easier to log back
| in - you won't even need to type your password if you use a
| 2FA-capable authenticator/passkey.
|
| OK, but if the account is locked, that just gets them to
| display the "you're screwed" screen faster (since they don't
| need to wait for me to type a password), and the blast radius
| goes from just my Google account to all my other accounts,
| right?
| lxgr wrote:
| > [...] how do I use my cloud synced passkey to log on to
| my Google account (which no longer has a password or other
| secret that I can back up locally) after I lose my phone?
|
| You don't, in the same way that you can't store the
| password to your password manager in your password manager.
| That's why having another way to log back in to your
| Passkey sync/backup account is crucial.
|
| > OK, but if the account is locked, that just gets them to
| display the "you're screwed" screen faster (since they
| don't need to wait for me to type a password), and the
| blast radius goes from just my Google account to all my
| other accounts, right?
|
| If you lose both access to your Google account and all of
| your devices that have your Passkeys locally synchronized,
| yes. The same goes for somebody taking over one
| synchronized device and remotely deleting all of your
| passkeys before you can take another device offline.
|
| I'm personally pretty skeptical of passkey synchronization
| by default without a way to opt out, but I can see how
| availability might be just as big a concern for most non-
| technical users as security.
| jdeibele wrote:
| I've lost a lot of confidence in Apple's keychain. I had been
| using iCloud Keychain and backing up username and password into
| BitWarden.
|
| I say "had been" because 189 lines of garbage entries are in
| iCloud Keychain and I can't get them out. They look like this:
|
| Title,URL,Username,Password,Notes,OTPAuth www.amazon.com (MEoEEPg
| AAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJeL6XzO81KJBCA02+DHVDASQ5Y3
| hOVrhGjCxV9Mv9qSEOc7uod7iKS3Rw==),https://www.amazon.com/,MEoEEPg
| AAAAAAAAAAAAAAAAAAAEwFAYIKoZI...,, (repeat for various sites 188
| times)
|
| I've tried deleting them multiple times but they always come
| back. I've filed Feedback with Apple but no acknowledgement of
| the problem. There's no hint as to whether the problem is with
| one of my devices or with iCloud.
|
| I've switched over to BitWarden entirely. At some point, I guess
| I try deleting the keychain and starting over but I really am
| concerned about using something that allows an error like this.
| dgrin91 wrote:
| How is this more secure? They say "with a fingerprint, a face
| scan or a screen lock PIN", but basically all phones let you fall
| back to PINs if you dont want to do face or fingerprints. Pins
| are flat out not secure - typically just 4 digits.
|
| Yeah its probably better than 80% of people having "password123",
| but it seems strictly worse than a password + password manager?
| Or at least just having proper 2FA.
| bkettle wrote:
| A PIN entered onto a physical device like a smartphone can be
| rate limited (see iPhone progressively increasing PIN
| timeouts). If you try to rate limit password entry to an online
| service, you make it trivially easy for an attacker to lock out
| a real user.
|
| Thus, even short PINs can provide strong security since the
| attacker gets, e.g., at most 10 tries to guess it out of 100k
| possibilities for a 6-digit PIN.
| ferminaut wrote:
| it's more secure on the back end. The DB will store a hashed
| unique pass phrase that isnt shared with anyone else.
|
| You enter a pin, the web server sees a public key that only
| your side has the private key to.
| bhk wrote:
| Being tied to a device, it defeats the most serious threats of
| phishing and weak passwords, for which attacks can be mounted
| on a global scale.
|
| 2FA via SMS is still vulnerable. 2FA with an app like Google
| Authenticator or VIPAccess is more secure because it is tied to
| a device.
| ilyt wrote:
| The devices are far from being security bastion.
| jjav wrote:
| > more secure because it is tied to a device
|
| Tied to a phone (as opposed to some security-specific device
| like a Yubikey) is a terrible idea.
|
| It ties your authentication to something that is often lost
| or damages, but more importantly, something that is
| controlled by a third party (apple or google) _and_ requires
| an expensive monthly subscription to yet another third party
| (your cellphone company).
|
| TOTP is not tied to a device which is why it's a beautiful
| solution. You can store it where you wish under the controls
| you wish and back it up as you wish. You are fully in
| control, dependent on nobody.
| surteen wrote:
| Because it's a PIN protecting a certificate stored on the
| device. Even if you know the PIN but don't have access to the
| device, you can't use it.
| toomuchtodo wrote:
| And the pin is the same functionality as activating a
| hardware authenticator like a Yubikey.
| stouset wrote:
| ... which have historically yielded credentials at _any_
| touch, without a need for a PIN, fingerprint, or face scan.
| wepple wrote:
| Password + password manager can be trivially phished. PIN
| can't, because even if you somehow phished a user you can't use
| it.
|
| I don't know what "proper 2FA" means but the gold standard
| today is U2F, and it has failed to be mass adopted due to
| requirement to purchase and maintain another device.
| aidenn0 wrote:
| FWIW, my password manager has prevented me from being phished
| because it wouldn't auto-fill the password.
| VoodooJuJu wrote:
| >with a fingerprint, a face scan or a screen lock PIN
|
| I agree - not secure.
|
| And just a daily reminder that biometrics are _usernames_ ,
| they are _not_ passwords. You can change a password, a lock, a
| key, you cannot change biometrics, and thus they should not be
| used for guarding sensitive info.
|
| The only use-case for biometrics is deanonymization, sold to
| you under the auspices of security, primarily used for
| corporate surveillance.
| pcthrowaway wrote:
| Biometrics are shitty usernames too. They _might_ change, it
| 's just outside of your control.
|
| My apple touchID never works because I rock climb and I guess
| that abrades the skin too much
| nilsbunger wrote:
| i rowed on a crew team for many years. The pads of my
| fingers were all worn down. I was rejected three times for
| "bad fingerprints" when applying for US citizenship.
| JohnFen wrote:
| It's not as rare as people think for fingerprints to be
| messed up either permanently or temporarily. Which amazes
| me, actually, because I'll be willing to be pretty near
| 100% of adults have, at least once in their lives, burned
| or otherwise injured their fingers in a way that alters
| their prints.
|
| Relying on fingerprints to gain access to things on a
| regular basis never seemed like a great idea to me.
| wepple wrote:
| > The only use-case for biometrics is deanonymization, sold
| to you under the auspices of security, primarily used for
| corporate surveillance.
|
| Please provide evidence that biometric data has ever been
| extracted from a major platform (IE Apple/enclave). Absence
| of evidence != evidence of absence, I know, but you're
| selling it as the _only_ use case so surely you have proof.
| johndough wrote:
| > Please provide evidence that biometric data has ever been
| extracted from a major platform
|
| Why extract it from a platform when it can be extracted
| easily from the person? Imagine your password was written
| on every surface you touched (fingerprint) or is
| prominently displayed on your social media accounts (face).
| startupsfail wrote:
| I don't understand how this could work actually. From a
| couple of photos on the social media you can likely
| recover the 3d geometry of the face. From that, if the
| signing algorithm is known, you should be able to
| replicate these passkeys.
|
| If the algorithm is not known, it's only a matter of time
| it'd be leaked or reverse engineered. And then suddenly
| there'd be a massive, difficult to fix security breach.
| Just like the breaches that we have now, with voice based
| authentication.
|
| Can someone explain, how this can be mitigated?
| wepple wrote:
| That's not my understanding of how it works.
|
| Your face geometry is used to allow access to a secure
| processor (trustzone/Secure Enclave/etc) which then signs
| the web token.
|
| Which is why the phone is the "something you have" piece
| of the puzzle here.
| Scion9066 wrote:
| The biometrics like your face or fingerprints aren't used
| directly with the site you're trying to log into and
| would never leave your device. It's just used to unlock
| your phone/tablet/computer/whatever's stored secrets to
| sign a message verifying it's you. If you don't trust the
| biometric systems on your device or are worried about
| someone stealing them and trying to fool your device's
| hardware, you can always just not use them and just use a
| passcode/password to protect your device instead.
| wepple wrote:
| How does my use of faceID on my iPhone promote de-
| anonymization if it doesn't leave my phone?
|
| Everything you've described can be done whether or not I
| use biometric to sign into a device, or even own a
| device?
| fireflash38 wrote:
| And then extrapolate to how those biometric factors could
| be changed outside of your control -- car accident
| requires facial reconstruction. Or a fire burns your
| fingerprints.
| jeroenhd wrote:
| I cut myself on a cheese slicer once and had to use PIN
| for unlocking my phone for a week or two while the cut
| healed. Annoying, but that's what the fallback PIN was
| for I guess.
| akira2501 wrote:
| > you cannot change biometrics
|
| Bodies are not invulnerable to damage. You can absolutely
| change your "biometrics", you just probably wouldn't _want_
| to.
| oli-g wrote:
| > biometrics are usernames, they are not passwords
|
| While I see where you're coming from, they really aren't just
| usernames. It's not like I can log into your e-mail account
| by typing VoodooJuJu and pressing Enter.
| JohnFen wrote:
| But most biometrics (at least faces and fingerprints) make
| terrible passwords. They can be copied and they're very
| hard to change if you need to.
| somedudetbh wrote:
| > And just a daily reminder that biometrics are usernames,
| they are not passwords.
|
| I think you should stop giving out this daily reminder. This
| meme has outlived its usefulness.
|
| Using face id to unlock a local key store to enable my device
| to sign a signed challenge from a site I want to log into
| with the private key stored on my device is not a 'username'
| in any meaningful sense.
|
| The problem is, the metaphor about passwords and usernames is
| not a good, structure-preserving simplification of the actual
| problem of authentication.
|
| The biometric data and/or pin code are not being used to
| prove that you are you to Gmail, it's being used to unlock
| the set of private keys you have on your device. This doesn't
| fit into the metaphor at all.
|
| If my non-technical parents said they were migrating all
| their accounts to passkeys, I would be very pleased. I
| wouldn't be worried about their inability to change their
| biometrics and that causing a problem following some sort of
| breach in the future. I am highly worried about their extreme
| susceptibility to phishing, especially in their inability to
| distinguish phishing sites from real sites, or real account
| maintence contacts via email and SMS from phishing contacts,
| their reuse of very simple passwords that are probably
| circulating in combolists already, and their general
| inability to retain username/password pairs. I have a lot of
| sympathy for them when I try to talk them through something
| like logging in to an Apple device with their apple id, when
| their appleid username is their email, which ends with
| @gmail.com. "But...why would i log in to apple with my
| gmail?" nevermind how confused they are about 'log in with
| google', 'log in with facebook', etc.
|
| Moving to a model where their devices store webauthn
| credentials and guard them with a pin or faceid-style
| biometric shortcut is a _massive_ improvement in practical
| resistance to account takeover for my parents, and I don't
| think continuing to say 'biometrics are usernames in authn'
| is accurate or helpful.
| latchkey wrote:
| > _If my non-technical parents said they were migrating all
| their accounts to passkeys, I would be very pleased. I
| wouldn 't be worried about their inability to change their
| biometrics_
|
| My 76 yr old dad can't do it. His phone is some shitty
| android trash that when he's setting up his biometrics, he
| shakes a bit, and it never stores the finger data
| correctly. I have to hold his finger and his phone at the
| same time to even scan it. Then, unlocking is also super
| unreliable because of the shaking. He refuses to get a
| better phone cause this one "works well enough."
| sam345 wrote:
| This is so true - most older people I've worked with have
| major problems with touch devices. No one has come up
| with a satisfactory solution. This is not a new problem -
| I remember working with my grandfather in his 80's on a
| 286 equipped with a mouse - his arthritis prevented him
| from accurately positioning the mouse. Today's touch
| interfaces are far worse. And fingerprint scans are very
| difficult to get right and use with older people. Maybe
| face scans are fine but I've never trusted them.
| Regardless of security logins, there are a host of other
| issues - complex navigation, complex and confusing
| layouts (especially desktop), and hard to manipulate
| controls. One example, a simple zoom or skype call - why
| hasn't anyone ever developed a simple device to allow for
| same without having to use intricate controls. I've
| always imagined something similar to the video enabled
| nest or alexa devices but with physical knobs and push
| buttons. There's a very large market being ignored for
| some reason.
| anonymouskimmer wrote:
| > No one has come up with a satisfactory solution.
|
| Stick your finger inside of a dynamically sizing
| aperture, or clip a finger reader onto your finger? If
| both the finger and the reader shake the same there
| shouldn't be a problem.
|
| That doesn't solve the general touch issue, but it solves
| this particular case.
| latchkey wrote:
| Forcing my dad to carry around and stick something on his
| finger just to get into his device, seems rather
| overkill, don't you think?
| anonymouskimmer wrote:
| People carry around earpods, keychains, wallets. What's
| one more little dongle on a keychain?
|
| But sure, I agree
| (https://news.ycombinator.com/item?id=35790638 ). I'm
| just trying to come up with some workable solution. Not
| trying to make the best of all possible worlds.
| latchkey wrote:
| Let me guess, you're not a 76 year old man.
| anonymouskimmer wrote:
| It doesn't fucking matter who I am if I don't have the
| power to direct product development. Fads in product
| development are Hobson's choice for us consumers. The
| best we can do is try to work around them with other
| products.
| [deleted]
| ryandrake wrote:
| > There's a very large market being ignored for some
| reason.
|
| It's no surprise that the tech industry, which largely
| employs urban, educated 20-somethings and 30-somethings,
| tends to produce products aimed at urban, educated
| 20-somethings and 30-somethings.
| jrm4 wrote:
| It's 100% accurate. And I get why it may not seem
| _helpful,_ but I think this is simply due to this industry
| trying too hard to cater to people who want things to be
| 6-year-old level easy.
|
| Security is HARD. There's no getting around that. Your data
| is valuable and protecting it is not an easy task. At
| _some_ level, security and convenience is a zero-sum game.
|
| As for old people, my dad writes down his passwords on a
| text file in his laptop and has a printed backup in the
| house.
|
| And, yes, he does have to bug me sometimes to re-login or
| change a password, but we've _never_ had a security
| problem, which is way more than can be said for a lot of
| people who tried the INHERENTLY unsafe "3rd party manager"
| thing.
| bb88 wrote:
| > It's 100% accurate.
|
| No it's not.
|
| The security triad is "something you are", "something you
| know", and "something you have". Fingerprints are
| something you are. Usernames are something you claim to
| be.
|
| The username is the "claim" you are this person. The
| password is the "proof" you are.
|
| If I'm fingerprinted by any federal agency today (and my
| fingerprints have been on file with the government since
| the 90's for a security clearance), then my fingerprints
| can serve as absolute proof of my identity. This is
| helpful to me should my identity ever be stolen and I
| need to show absolute proof of who I am.
| withinboredom wrote:
| Your fingerprints change over time (mine are different
| from just five years ago -- as I learned when recently
| renewing a visa a few weeks ago).
| jrm4 wrote:
| Good point, you're right. And with e.g. federal agencies,
| this fine.
|
| But given the relatively high level of laziness,
| capriciousness, and general failure all around that is
| "IT security by means of companies who are rarely held
| accountable," it's good to point out that this is what
| makes biometrics _worse_ than usernames and should
| probably mostly be avoided, or at least optional.
| bb88 wrote:
| Your points are taken, but I do believe that the
| "something you are" is better than the "something you
| know" and "something you have" pieces -- as the knowledge
| or the thing you have can be stolen.
|
| Sure fingerprints, face scans, and iris scans can be
| stolen as well. But certain things are really hard to
| fake, including potentially, scans of faces and an iris
| scan at the same time -- unless you can somehow graft a
| new iris and grow a new face.
|
| Put it like this: a dead victim is found naked along the
| side of the road. Which leg(s) of the security triad can
| the police use to prove the identity of the victim?
| lcnPylGDnU4H9OF wrote:
| Those are all factors in multi-factor authentication. If
| a service does not require the "something you are"
| there's still good security if they require the other two
| factors. If the only required factor is "something you
| are" that's bad security.
| newaccount74 wrote:
| They all require the "something you have" as well. Pretty
| much all the face recognition / finger print tech on
| mobiles is locked to a single device.
| segmondy wrote:
| This is more secure, passwords can't be stolen from the site.
| Sure, let's go with the assumption that your phone can be
| stolen. It would be only your phone. If a site has 100 million
| users, an attacker could steal 100 million passwords. With this
| approach, the attacker would have to steal 100 million phones.
| No matter what password manager you use, with a password length
| of 100 characters. The entire password list (encrypted) can be
| stolen.
| aidenn0 wrote:
| This keeps you from ever sending the password to the site
| (similar to e.g. SRP).
|
| Most sites already don't store the password. If you have a
| sufficiently strong password (i.e. very long, randomly
| generated, stored in a password manager), it is likely _not_
| computationally easier to recover the password from a hash
| than it is from a public-key. The only improvement here is
| that you don 't have to trust that the site is following
| best-practices for storing passwords, as you never send them
| the password.
|
| [edit]
|
| It _also_ prevents phishing attacks for those using some form
| of entering a password other than autofill from the password-
| manager.
| NoMoreNicksLeft wrote:
| You're forgetting Oyler's Law of Passwords: Humanity will be
| forced to try each wrong approach to passwords, one at a time
| and trial-and-error, for all eternity.
|
| Slightly off-topic: If a website will not let me register and
| complains that my password is too long, they're still storing
| that in the underlying database as a properly-salted (modern
| algo) hash, right?
| neilalexander wrote:
| > How is this more secure?
|
| The three factors of authentication are:
|
| 1. Something you have
|
| 2. Something you know
|
| 3. Something you are
|
| Passkeys are typically 1+2 or 1+3 -- you'd need to have
| physical access to the device either way.
| [deleted]
| petedoyle wrote:
| This has been bothering me, a lot. Google talks [1] about how
| Passkey replication is e2e encrypted between devices, but
| AFAICT they're just using a pin + key derivation. A six digit
| pin is like 20 bits of entropy before a KDF. [2]
|
| Has anyone seen any docs that might help characterize how much
| entropy the keys have for e2e encryption (Android/iOS)?
|
| I must be missing something, because I can't see how Google
| would call something e2e encrypted if the keys only have like
| 30-35 bits of "effective" entropy after a KDF. But that seems
| like it's the case?? [1] "From the user's
| point of view, this means that when using a passkey
| for the first time on the new device, they will be
| asked for an existing device's screen lock in order to
| restore the end-to-end encryption keys"
|
| [1]
| https://security.googleblog.com/2022/10/SecurityofPasskeysin...
|
| [2] https://www.omnicalculator.com/other/password-
| entropy?c=SGD&...
| 015a wrote:
| Sure, but if that key derivation function is protected by a
| "you get 10 attempts then we wipe the keys" safeguard, the
| effective entropy is much higher. The question shouldn't
| really surround the effective entropy of the PIN, but rather
| the systems in-place to protect bypassing safeguards in the
| key derivation function which render the actual entropy of
| the PIN irrelevant. There probably isn't _no_ way around that
| safeguard, but as more of this gets moved into trusted
| compute silicon the level of sophistication required to
| breach it goes up; and is one hardware revision or operating
| system update away from being made moot again.
|
| This thread really smells like https://xkcd.com/538/. Three
| things you _have_ to remember, that are far more important
| than any of the concerns you have:
|
| 1) The effective entropy of the current system (passwords) is
| "shrugs shoulders fuck it not our problem". Services can
| enforce password entropy requirements. They cannot
| effectually require users to use a unique password. They also
| cannot forbid users from writing the password they use in a
| .txt file on their desktop or post-it note or throwing it in
| Apple Notes (EVERYONE does this outside of our bubble. Apple
| Notes and Excel are the #1 and #2 password managers on the
| planet). A six digit pin + hardware TPM key derivation is, at
| best, the same thing that was guarding how most people store
| their passwords anyway, and in many cases far better than the
| current state (if a user's device has no E2EE, or if they're
| syncing their passwords.xlsx file with Dropbox, etc).
|
| 2) Passkeys do not and are not designed to protect against
| nation-state level attackers. Passwords weren't either. They
| also don't protect well against the "grab a hammer and beat
| it out of him" threat vector; you're going to give up your
| password, and tomorrow they'll probably have your iPhone and
| your passkeys will be disclosed as well. Passkeys are
| designed to protect against unsophisticated (and even
| moderately sophisticated) attackers; phishing, data breaches,
| etc.
|
| 3) If you _want_ higher tiers of entropy guarding your
| passkeys, you can do that. 1Password, as an example, _already
| has this_ [1]. They store passkeys, and encrypt those
| passkeys with their two-level account & master password
| keys. Done! If you don't like 1Password, you can roll your
| own, and I'm sure OSS password managers like
| gopass/keepass/etc will eventually add this.
| Passkeys/WebAuthn don't prescribe to _anyone_ how you store
| the private keys; Apple will do their thing, Google will do
| their thing, you don 't have to use them, many people will,
| and they'll be better off (see point 1).
|
| [1] https://future.1password.com
| petedoyle wrote:
| > Sure, but if that key derivation function is protected by
| a "you get 10 attempts then we wipe the keys" safeguard,
| the effective entropy is much higher.
|
| Thank you. 100% agree.
|
| > Passkeys do not and are not designed to protect against
| nation-state level attackers
|
| I've been mulling over some use-cases where this is
| important, hence the deep consideration over entropy. 100%
| not a huge deal for the passkeys case for many 9's of
| people.
| sebk wrote:
| Talking about Apple here because it's what I'm more familiar
| with, and their security whitepapers are more widely
| available.
|
| The PIN and key derivation wraps the actual encryption key
| that's stored locally in the device or secure enclave, not
| the actual secrets that are stored in the provider's cloud.
| The actual wrapping keys are random 256 bit AES-GCM keys.
| This approach works because the secure enclave provides
| measures against bruteforcing and tampering.
|
| There is some controversy that I can't find an explanation
| for in any whitepaper, specifically here:
| https://support.apple.com/en-us/HT202303 where it reads
| "(...) this data remains secure even in the case of a data
| breach in the cloud. If you lose access to your account, only
| you can recover this data, using your _device passcode or
| password_ , recovery contact, or recovery key." because that
| implies off-device use of the PIN, so those measures are
| lost. There's no further explanation that I could find about
| that. Some previous discussion about that particular point
| here:
| https://news.ycombinator.com/item?id=33897793&p=2#33900540
| petedoyle wrote:
| Thank you! I'm trying to understand more deeply, so I
| appreciate it. :)
|
| > This approach works because the secure enclave provides
| measures against bruteforcing and tampering.
|
| That's interesting!
|
| > because that implies off-device use of the PIN, so those
| measures are lost
|
| This link from your previous thread is interesting:
| https://support.apple.com/en-
| sg/guide/security/sec3e341e75d/...
|
| Uses SRP to let the device prove to iCloud HSMs that the
| user entered the correct pin, without ever sending it over
| the wire. The HSMs have similar protections for brute
| forcing, etc.
|
| From the docs I have a fairly high confidence entropy is
| 256 bits for iCloud Keychain. I have much less confidence
| on Android, but I'm still researching... :)
| ExoticPearTree wrote:
| The advantages are very poorly explained in the article.
|
| Last time I read about this, you could use your phone or a FIDO
| key to authenticate. Like if the phone was close to the computer
| you could aithenticate the same way you can unlock your computer
| with your watch.
|
| So either this new technology is so advanced lesser minds don't
| understand it or it jus adds a more cumbersome authentication
| method instead of passwords and its adoption rate will be in
| single digits.
| mihaaly wrote:
| My takeaway is that this is infinitly more secure for those do
| not care about security - the "password1234" crowd, actually
| their account may even be secure from them logging in from now
| on -, for the rest it is about the same, but different.
| dtech wrote:
| It looks like a good change for the average user, a secret stored
| on the device is likely a whole lot safer than just having a
| password. Having it as the only factor seems less secure than
| password + good extra factor like TOTP on device though.
|
| I also wonder how a lost/broken/replaced device is dealth with,
| especially given Google's less-than-stellar account lockout
| history.
|
| _edit_ : I guess this is still MFA since you need both the
| physical device and a fingerprint and phone unlock code
| barkerja wrote:
| Passkeys can also be used in addition to passwords, as a form
| of 2FA. I've seen a number of sites approach Passkeys in this
| manner.
|
| Or if you really wanted to, you could flip it. You can allow
| the Passkey to be the "password" and an actual password the
| second-factor for the user.
| Zamicol wrote:
| On my website, I'm doing authentication via simple public key
| authentication using Coze.
|
| No passwords. No email. No Google. Just public key authentication
| with private keys in possession of the user.
| https://github.com/Cyphrme/Coze
| 8organicbits wrote:
| I've always expected end users would struggle to manage private
| keys. What sort of users does your website have?
| voytec wrote:
| Coming soon to a device new you, from the authors of no E2E
| encryption on Authenticator backups! [1]
|
| [1] https://news.ycombinator.com/item?id=35708869
|
| [1] https://news.ycombinator.com/item?id=35720460
| attah_ wrote:
| Google: What are Passkeys? Also Google: Goes on to not explain
| what they are at all. That's about when i stopped taking it
| seriously.
| awaythrow98765 wrote:
| Those passkeys are either insecure or unreliable. Let me explain:
|
| Those passkeys are asymmetric cryptographic keypairs where the
| private key is securely stored on a device, unlockable (for use,
| not reading) only by convincing your devices security processor
| to do so by pin/fingerprint/pattern. Which in itself can be
| secure, given you do trust that magic security processor (which
| you shouldn't, see yesterday's news for example). However, if
| that key cannot be read, you cannot make a backup of it, so it
| will be unrealiable and easy to loose. The recovery process will
| either be insecure and prone to social engineering, or unreliable
| because proving your identity will be nigh impossible without
| that passkey. Now one could allow backups of a passkey, but then
| that passkey would be as insecure as a password. One could allow
| multiple instances of authorized passkeys, but those would be
| even more insecure than passwords, because malicious software on
| your device could create evil new key instances.
|
| In all a bad and dangerous idea.
| seti0Cha wrote:
| The idea seems to be that you will either trust a provider like
| Apple or Google to keep you private key safe and let them sync
| it around, or you will create a passkey for each device that
| you use. If you lose the device, deauthorize the passkey. If
| you somehow lose the passkey itself, create another one, either
| by using an older form of authentication, or by creating using
| a different device to authenticate. There is no need for
| passkey recovery or backup.
| jmbwell wrote:
| As an administrator, I hear you, but we have to adapt.
| Passwords are awful. On the whole, the effort and energy spent
| training people on passwords, battling phishing, dealing with
| password managers, cleaning up from breaches, and more...
| passwords can't die soon enough.
|
| FWIW, asymmetric PKI is technically mature and relatively easy
| to implement in most applications (without "vendor lock-in", I
| might add to comments upthread), and there are ways to address
| most of your concerns about key loss and recovery beyond what
| you describe, as by the ring of trust scheme Apple uses, for
| example.
|
| The only way through this is forward. I'm confident it really
| will get better once passwords become a smelly indicator of bad
| security practice.
| JohnFen wrote:
| I'm looking forward to such glory days. Right now, however,
| none of the solutions available are ones that I could live
| with if I had to use them for everything. For one or two very
| sensitive things, sure, but for everything? It's less of a
| pain to use long, random passwords.
| 015a wrote:
| It would be a bad and dangerous idea, if what you said was
| true; but it isn't.
|
| Passkeys are just asymmetric key-pairs. There will be a variety
| of client-side implementations. Some may make export and backup
| difficult or impossible. Others, such as 1Password's _already
| extant implementation_ advertise backup and synchronization as
| a feature! There is _nothing_ about the passkey standard which
| prescribes the reality you fear.
|
| > Now one could allow backups of a passkey, but then that
| passkey would be as insecure as a password.
|
| Wrong, absolutely and entirely. Its still more secure, because
| its an _asymmetric_ keypair, and you 're forgetting about the
| far more common attack vector against password disclosure:
| service breaches. That's how attackers learn about passwords
| by-and-large. And this is not just some nice-to-have side-
| benefit of passkeys: its a _core motivation_ of this standard.
| With passwords, a service breach compromises not only the
| accounts of every user on that service, but potentially every
| other account every user has, globally, because of password
| sharing. With passkeys, all of that is resolved.
|
| Even if we end up with a system that is the same level of
| effective client-side security, which is also extremely wrong,
| the net security of the system will be vastly improved because
| service providers aren't storing the private key used to
| authenticate user accounts.
|
| But the client-side security is _also_ substantially improved,
| because passkeys have much higher phishing resistance.
| jmull wrote:
| > you cannot make a backup of it
|
| The way this typically works is that the keys are stored in an
| encrypted file, which can be backed up securely as-is. It can
| also be copied around and sync'd to other devices.
|
| Of course, this means the authenticator app/service that needs
| to use the private keys to respond to challenges has to be able
| to decrypt that file, which means logging in to it.
| Authenticators balance convenience with security in terms of
| how often you need to fully log in to it. They are also often
| configured to require a light-weight authentication on each use
| (fingerprint, face, pin).
|
| With authenticator apps handling the private keys, secure
| backups should be easy and automatic. Things should improve
| since the people using passwords now who don't have a secure
| automatic backup mechanism for them and switch to passkeys will
| probably end up with an authenticator that does it
| automatically.
|
| (Recovery processes will still exist and can still be an
| issue.)
| Shank wrote:
| The point of passkeys isn't to be perfect -- the point is to
| replace passwords, which are already far more imperfect than
| passkeys. The bonus points with a password is that every site
| that uses them has to secure them properly and theft of
| passwords, in plain-text, hashed, etc form is common.
| XorNot wrote:
| Imagine for a moment that instead of all the time wasted on
| this, we just implemented a protocol amongst the browser
| makers which allowed a secure password prompt to be
| requested, and required strong-hashing before sending
| anything over the wire?
|
| Which would be easier to use and more effective.
| doodlesdev wrote:
| If you hash before sending anything over the wire then the
| hash of your password is now your password, meaning that if
| it leaks it amounts to basically the same as your password
| leaking. Granted, applications may choose different hashing
| algorithms, provide their own clientside salts, etc. which
| would be really nice. To be fair, I believe more systems
| should be doing this nowadays, it's really weird to have to
| send your actual password to the website if a hash would
| suffice. Then the website could store the salted hash of
| the salted hash of your password in their database.
|
| Programs such as Bitwarden already do this, where you send
| the hash of your password to the server instead of the
| password itself, because from the password you derive the
| decryption key and you never want that reaching the server.
| You then use that hashed password as the authorization
| password, but the client uses the actual password to
| decrypt the delivered password vault.
| XorNot wrote:
| If a common browser protocol required the password to be
| salted with an application supplied value _and_ then
| rehashed with the domain name it 's served on, there'd be
| no way to phish a password.
|
| The value the user's browser sends back can't be
| reversed, so any website prompting from the wrong domain
| would only ever see an incorrect hash, rather then the
| cleartext as it does now.
| awaythrow98765 wrote:
| For an end-user, reliability and ease-of-use trump security.
| Passkeys are imperfect in the wrong places imho.
| boudin wrote:
| I find this to be a regression in terms of usability and
| security as well.
|
| On top of what you mentioned, it also fails really hard when
| someone has access to you and your trusted device (which will
| be the smartphone in most cases). It's already an issue
| allowing easy access to smartphone content, it will extend it
| to any account using that method of authentication.
| lxgr wrote:
| What would be a better idea, then?
| Ajedi32 wrote:
| > Now one could allow backups of a passkey
|
| That's literally part of what makes a passkey a passkey (v.s.
| just a WebAuthn credential), so that's a given.
|
| > as insecure as a password
|
| No. Passkeys can't be phished, passwords can. Passkeys can't be
| cracked after a data breach. Passwords can. Passkeys can't be
| set to something easily guessable. Passwords can. Passkeys
| can't be written on a post-it note and taped to your monitor.
| Passwords can. Passkeys can't be reused across multiple sites.
| Passwords can.
|
| There are _so_ many ways passkeys are superior to user-
| memorized passwords from a security perspective, it 's
| laughable to call them "as insecure as a password".
|
| > One could allow multiple instances of authorized passkeys,
| but those would be even more insecure than passwords, because
| malicious software on your device could create evil new key
| instances.
|
| What? Malware stealing your password is "more secure" than
| malware registering it's own malicious key to each individual
| site it wants access to?
| awaythrow98765 wrote:
| > No. Passkeys can't be phished, passwords can. Passkeys
| can't be cracked after a data breach. Passwords can. Passkeys
| can't be set to something easily guessable. Passwords can.
| Passkeys can't be written on a post-it note and taped to your
| monitor. Passwords can. Passkeys can't be reused across
| multiple sites. Passwords can.
|
| Passkeys don't need to be cracked after a data breach of your
| backup provider, they are just usable, right there.
|
| > There are so many ways passkeys are superior to user-
| memorized passwords from a security perspective, it's
| laughable to call them "as insecure as a password".
|
| Passkeys are accessible permanently on some devices
| unencrypted or decryptable in the filesystem, if part of e.g.
| a backup. Whereas passwords are usually only accessible
| temporarily. That makes the attack surface top copy over some
| passkey far larger than for sniffing a password.
| lxgr wrote:
| > Passkeys are accessible permanently on some devices
| unencrypted or decryptable in the filesystem, if part of
| e.g. a backup. Whereas passwords are usually only
| accessible temporarily.
|
| I think you're mixing up server-side and client/sync-
| backend-side compromises here.
|
| For the former (i.e. a compromise of hashed passwords and
| their corresponding salts), you'll need to rotate all
| passwords since the hashes can be brute-forced. For
| passkeys, all an attacker gets when compromising a
| service's database are public keys that can't be brute-
| forced and key handles that don't give an attacker anything
| without the corresponding authenticators.
|
| For the latter, the situation is exactly the same for
| passkeys and passwords in a password manager, i.e. both are
| as secure as their on-device storage and encryption in
| transit and rest at a synchronization provider (if any).
| Ajedi32 wrote:
| You seem to be under the false impression that passkey
| databases are stored completely unencrypted and unprotected
| on disk or in the cloud. Obviously those details are
| implementation-dependent, but I don't know of any passkey
| implementation that works that way.
|
| Let's take Apple's implementation as an example (since that
| was the one I could most easily find information on). Their
| implementation stores passkeys in the iCloud keychain[1],
| which is end-to-end encrypted[2].
|
| [1]: https://support.apple.com/guide/iphone/sign-in-with-
| passkeys...
|
| [2]: https://support.apple.com/guide/security/secure-
| keychain-syn...
| judge2020 wrote:
| Maybe for browsers on Windows it'll default to storing the key
| purely on-device, but especially with iCloud Keychain the key
| is not encrypted by the on-device processor.
|
| This does not make it as "insecure as a password". It does mean
| you can use root/OS access to exfiltrate keys, but it closes
| the following security holes that affect passwords:
|
| - keyboard sound-based exfiltration[0]
|
| - visual exfiltration (someone recording you enter your
| password, or looking over your shoulder and memorizing it)
|
| - credential stuffing, where people who reuse passwords get
| pwned when the same leaked password is used on other websites
|
| 0: https://www.independent.co.uk/tech/cyber-security-
| passwords-...
| psanford wrote:
| I was expecting this also meant that I could add a FIDO2 resident
| key as a passkey, but the google UI currently does not allow me
| to do that. That's fairly disappointing.
|
| Its also fairly surprising that desktop UI on linux tells me I
| can't add passkeys from it. I understand that Chrome isn't
| planning on supporting platform authenticators on linux, but why
| can't I add another phone from the desktop with the QR flow?
| jlnho wrote:
| I enabled passkey and literally nothing changed. Signed out and
| back in again several times.
| ezfe wrote:
| Yeah, it's not doing anything for me either
| lars_francke wrote:
| Doesn't work here either. But I'm on Firefox on Linux, both
| of which are not yet supported as per the docs.
|
| Firefox might get it around version 120:
| https://connect.mozilla.org/t5/ideas/support-webauthn-
| passke...
| hhh wrote:
| I have used FaceID & TouchID passkeys for a few months now for
| MFA. I love it, it's the most seamless auth for me thru PingID.
| baryphonic wrote:
| I don't want to give Google my fingerprint or my face. A password
| in a password manager + 2FA is fine.
| tallanvor wrote:
| You're not. You're storing a private key on a device, and using
| something like a fingerprint or pin to unlock it and use it to
| authenticate. The fingerprint data is also only stored on the
| local device.
| awaythrow98765 wrote:
| Yeah. Except if the usual Qualcom spy chips (also available
| in Google Pixel) phone home all your biometrics...
| Springtime wrote:
| _> And, unlike passwords, passkeys are resistant to online
| attacks like phishing, making them more secure than things like
| SMS one-time codes._
|
| It's a bit disappointing seeing them re-affirm SMS as a a more
| vulnerable form for 2FA when Google's stance has been to try and
| force a phone requirement on Google accounts that lack them in
| order to login--and then using the phone for SMS 2FA.
|
| In the past number of years only after a phone is attached do
| other 2FA methods like TOTP become accessible as options.
|
| However even when a phone is added Google continues to utilize
| SMS 2FA over them for what are deemed important actions like
| Takeaway or auth keys, in my experience.
|
| This is despite known issues like SIM swapping, lock screen
| messages (viewable by anyone with device access) and due to the
| prevailing use of SMS for 2FA users have been prepped to accept
| security codes via messages which is arguably more exploitable
| than app-based TOTP in scams where fraudulent messages are known
| to be used alongside calls to mislead users into gaining trust
| then subsequently requesting a real 2FA message[1].
|
| [1] https://robertheaton.com/almost-scammed/
| tialaramex wrote:
| > In the past number of years only after a phone is attached do
| other 2FA methods like TOTP become accessible as options.
|
| I do always see these comments on HN and I think "Huh, really?"
| and I go check and, nope, Google doesn't have my phone number,
| but they _do_ know I have security keys, so that 's all working
| as intended.
| shortcake27 wrote:
| I don't have my phone number "registered" with Google. IE it
| does not appear in my account.
|
| A few years back I was logging into a new machine from a
| known network. I provided the correct username, password, and
| TOTP on the first try. Google then forced me to authenticate
| further by providing my phone number _in the sign in flow_ to
| receive an SMS. This is pure theatre as I could have provided
| any number. No security was gained. Google does, however, now
| have my number. Even if it isn't displayed on my account.
| talkingtab wrote:
| How does google make money? By having information about users and
| providing that to people who want to 'target' users. So in the
| interest of making a 'better' user experience we now have google
| passkeys. Is Google making this to help users or perhaps does it
| provide more ability to target users. Hmmm.....
|
| You are not googles customers. Advertisers and other agent
| wanting to target you are google customers.
|
| Channeling someone, "just say no to google." Or "friends don't
| let friends use google passkeys".
| rcarmo wrote:
| I've yet to figure out how passkeys can be useful for someone who
| switches between multiple devices (and platforms) throughout the
| day, and who wants to retain control over where tokens are
| stored. I have switched as many of my MFA credentials as possible
| to TOTP and have avoided Yubikeys because I don't want to be tied
| to a single piece of hardware that can be easily lost, or to an
| identity provided that may decide to lock me out...
| jimmar wrote:
| The paragraph in the section, "What are passkeys?" tells me that
| they: are new, are easier, let me use biometrics, and are
| resistant to attacks. But, it doesn't tell me what passkeys
| actually are.
|
| Compare passkeys to traditional authentication factors. What's a
| password? A secret word or phrase that only you know. What are
| biometrics? Parts of your body that can help uniquely identify
| you, like your fingerprint or retina. What are hardware tokens?
| They are physical devices that give you codes that verify that
| the person logging in has the device on their person.
|
| What are passkeys?
|
| Until they develop a way to explain what passkeys really are, I
| question how quickly they will be adopted.
| jjav wrote:
| > Until they develop a way to explain what passkeys really are,
| I question how quickly they will be adopted.
|
| The article is very frustrating, very long on fluff and no
| substance.
|
| If anyone has a link to a detailed technical description by an
| unbiased third-party (not google hawking their lock-in), I'd be
| very thankful if it can be posted.
| [deleted]
| laegooose wrote:
| I suspect that one screen comic or a 20 second video could
| explain it. Instead they give us a wall of text that even
| technical people can't understand.
| JustSomeNobody wrote:
| Thank you. I've been trying to figure out what they hell they
| are and have been unsuccessful. I thought it was just me.
| TulliusCicero wrote:
| This goes into more detail:
| https://developers.google.com/identity/passkeys
|
| As far as I can tell: it's a system of private keys stored on
| devices, in order to transmit a key you also need to unlock a
| device (e.g. phone) with some other method like a PIN or
| fingerprint/face scan. Combine those two things and it means
| a would-be hacker would need both the physical device as well
| as the local authentication for that device (PIN or
| biometrics).
| laegooose wrote:
| Can it be uses on both Android and iOS? What about desktop
| machines with no fingerprint sensor or faceID?
|
| What happens if user loses the only device on which passkey
| was enrolled?
| danieldk wrote:
| In principle it can be synced between any is, it just
| depends on the cloud/implementation. Eg. 1Password is
| currently adding Passkey support, that would probably
| work on any device they have browser plugins and the
| private key material is stored and synced through
| 1Password vaults.
| echeese wrote:
| It can be used on both Android and iOS. Desktop machines
| can display a QR code which you scan with your device.
| Passkeys are backed up to the cloud using E2E encryption.
| If you get locked out of that device, you can do the same
| thing as when you lose your password.
| ChrisMarshallNY wrote:
| _> do the same thing as when you lose your password._
|
| If this is a Google Service, then that means begging,
| pleading, threatening, crying like a baby, then finally
| posting a rant on HN to get the service unlocked.
| echeese wrote:
| You could also try your password, I guess.
| lxgr wrote:
| > Can it be uses on both Android and iOS?
|
| Yes!
|
| > What about desktop machines with no fingerprint sensor
| or faceID?
|
| You can use a PIN, your login/screen lock password, or an
| external device offering a fingerprint sensor.
|
| > What happens if user loses the only device on which
| passkey was enrolled?
|
| You can either sync passkeys to an online account and
| across multiple devices, or use multiple passkeys stored
| in multiple physical authenticators.
| [deleted]
| berkle4455 wrote:
| It's a password that Google controls so when they incorrectly
| ban you from their services you lose access to literally
| everything.
|
| Or if you drop your phone in a lake you're out of luck too.
| shadowgovt wrote:
| It's the second one, not the first one.
|
| The protocol is private key stored on your hardware; public
| on the service you're authing to. Google doesn't have a way
| to MITM that, but if you lose the machine storing the private
| key, best have another way to auth.
|
| (Note: some implementations, including Chrome on Android, do
| allow sync and sharing of the key, but IIUC even if Google
| bars you access to your account, the phone will still have
| the private key and can still do the login).
| yeeeloit wrote:
| > the phone will still have the private key and can still
| do the login
|
| One of the main gripes people have is about whether or not
| the user actually has access to the key or not.
|
| ie. Can I save my passkey somewhere that I control, can I
| login on another device, etc. etc. Or do I need google's
| sync/account to do that for me.
| xdennis wrote:
| > Google doesn't have a way to MITM that
|
| Google controls the software so it can MITM.
| Dalewyn wrote:
| Passwords will never be supplanted unless the new challenger
| can satisfy all of the following:
|
| * Easy to understand. (A password is just a word/phrase/string
| of characters only you know.)
|
| * Easy to use. (Using a password only requires remembering and
| typing it in when prompted.)
|
| * Convenient. (Only your ability to remember and type required.
| No other tools or gadgets required.)
|
| * Simple. (All of the above.)
|
| If something needs an essay to describe itself, it's not
| killing off passwords.
| mrb wrote:
| Passwords will _never_ be supplanted? As always, it 's a
| false dichotomy. Passwords will continue to be useful for
| some scenarios, but in others they will and are being
| replaced by other methods such as biometrics, U2F tokens, etc
| shadowgovt wrote:
| I'm actually going to set this up on my mother-in-law's
| machine next time I see her. She's forever losing her book of
| passwords, but always has her phone on her.
| augusto-moura wrote:
| I'm not sure if it is passkeys or other mechanism, but I can
| easily open my bank account on my Android phone just by using
| biometrics. Instead of typing a pin or password I just do the
| biometrics and voila, it opens like magic. That really made
| me appreciate passwordless apps.
|
| On the other hand, I don't really know how would that work on
| desktops, should chrome use a Windows service for that? Would
| it use its own servers? Apple would probably do it
| themselves. And how about Linux? Would a cross platform
| option ever exist? Maybe 1password?
| psychphysic wrote:
| It's also private.
|
| Do you really want your only means of logging into a service
| identify you because it's also the only way you log into your
| banking?
|
| And should you want to kill off an identity so you want to
| have to register everything?!
| mk89 wrote:
| You need to click on the link that is in the post:
| https://blog.google/technology/safety-security/one-step-clos...
|
| > Instead, your phone will store a FIDO credential called a
| passkey which is used to unlock your online account. The
| passkey makes signing in far more secure, as it's based on
| public key cryptography and is only shown to your online
| account when you unlock your phone.
|
| It looks like a token stored on your phone that will be used
| instead of your password to authenticate.
|
| Apple did something similar:
| https://developer.apple.com/passkeys/ that is automatically
| sync-ed in iCloud Keychain, so on every apple device you own,
| you can use it.
|
| More information here: https://fidoalliance.org/passkeys/ and
| this explains finally how it works FIDO in general:
| https://fidoalliance.org/how-fido-works/
|
| So yeah it's _sort of_ a token, but technically, it 's a
| private key that is used to sign the challenge at login time.
|
| EDIT: from what I understand, while this prevents from
| "stealing passwords" etc., there is still the risk that someone
| steals your private key (copy/paste your phone or ... well,
| steals stuff from iCloud Keychain) and tries to use that to
| sign the challenge. Did I get it right? Or what mechanism is in
| place to prevent it? It looks like this time we use biometrics
| first (to unlock the screen) and passkey later?
| __MatrixMan__ wrote:
| Why not call it a private key then, we've been handling those
| since the 70's.
|
| They don't need to be rebranded, they need to be taught in
| high school with the same words we've always used to talk
| about them.
| esquivalience wrote:
| Why not call passwords private words? We've been using
| words even longer.
|
| The answer is that they're being used to pass an
| authentication challenge. Pass + key is no different.
| xg15 wrote:
| I'm not completely sure, but my understanding was that it's
| basically the same principle as SSH keypairs, with the added
| twist that the user never gets direct access to the private
| keys.
|
| The keys are also per-device, so e.g. if you use your Google
| account from your phone, your laptop and your workplace PC,
| there would be three public keys associated with your
| account.
|
| Because the private key (in principle) doesn't ever need to
| leave the device, it could be stored in a TPM, Secure Enclave
| or similar chip. The device itself is also supposed to
| protect the key with some sort of local authentication, i.e.
| biometrics or a PIN. That stuff only happens locally on the
| device though and doesn't involve Google's servers in any
| way.
|
| Consequently, if you want to log in from a new device, you
| can't just copy over the key, you have to perform some
| complicated dance where the new device _and an old device
| that you have already registered_ work together to generate a
| new keypair for the new device.
|
| If you don't _have_ and old device, e.g. because you 're a
| non-techie and only ever used your account on your phone and
| bow your phone just broke? Though luck, I guess?
|
| Same goes for blocking a key: In theory, you can block access
| for each device individually - however, you need to be able
| to access your account using one working device in order to
| do so.
|
| (There is also the hilariously useless flow of "delegating"
| to a device, for when you're really really really want to
| check emails from your friend's phone _but also have your own
| phone right with you in your pocket_. It will not actually
| help you if you want to check emails from your friend 's
| phone because you have forgotten your's. This feature sounds
| a lot like they needed something to respond with if someone
| asks about logging in from 3rd party devices - without making
| that usecase actually practical.)
|
| So I guess all that does make stealing the private key
| somewhat hard: Phishing is out of the question as the user
| can't access the key even if they wanted to and even if you
| got hold if the physical device, you'd have to get the key
| out of the TPM. The bigger problems I see is that your
| account is now tied to your devices instead of, well, you: If
| someone steals your phone and manages to guess the PIN or get
| through the biometric auth, they have instant access to
| everything. On the other hand, if you have no registered
| device left, you're effectively locked out of your account.
|
| (All that assuming _if_ passkeys were the only option for
| logging in. As of now, they still seem to plan with passwords
| as fallback, so that 's just hypothetical)
| moffkalast wrote:
| From what I can find the word passkey is just a synonym for
| password. So yes, none of this makes any sense.
| psychphysic wrote:
| It makes sense if you want to move from two factor
| authentication to just the second factor while making it seem
| new and cool?
|
| It seems to be smoke and mirrors for you register a bunch of
| TPM/HSM.
| dannyphantom wrote:
| I'm not sure how it's all that different from Windows Hello.
|
| > Passkeys are easy to set up and let you securely sign in to
| your Google Account using your fingerprint, face, screen lock,
| or hardware security key. You can create a passkey on this
| device, or use another device.
|
| When I press [Continue], Windows Security appears where I can
| then scan my fingerprint which I already use to sign on.
|
| A single glide of my finger worked as expected and a 'Passkey
| created' screen appeared with [Done] being my only option to
| continue.
|
| After a sign out, re-enter of my gmail and these are the next
| few steps: https://imgur.com/a/heLrUkb
|
| It seems like it just integrates the built-in verification
| methods depending on what device you are on.
| lxgr wrote:
| How about: "Passkeys are digital keys that can be securely
| stored either in a physical device (such as a Yubikey) or in an
| online account (such as iCloud Keychain or Google Passwords)"?
|
| Thinking about this some more, maybe we should start calling
| Yubikey etc. keyrings, rather than keys, given that they can
| store multiple independent passkeys securely?
| JohnFen wrote:
| Yubikeyrings? I like it.
___________________________________________________________________
(page generated 2023-05-03 23:00 UTC)