[HN Gopher] Google Introduces Passkey Authentication
___________________________________________________________________
Google Introduces Passkey Authentication
Author : rbinv
Score : 169 points
Date : 2023-05-04 14:30 UTC (8 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| tonymet wrote:
| This still feels like a beta product, with a foot-gun of a UX
|
| * I activated the passkey, but since i had one saved from an old
| device, it did not set up my new device. So i got locked out of
| my account (luckily i have a backup option)
|
| * How does this work with desktop PCs that don't have a camera?
|
| * Now we have a web of primary, secondary, n-ary authentication
| methods that need managed. Password, app 2-fa, phone 2-fa, tokens
| etc. Any one could be a weak link in the chain. Now warnings,
| notifs & reporting is needed to maintain security among all the
| auth methods.
|
| It reminds me of the XKCD "standard" that now means we have n+1
| protocols
| echeese wrote:
| The way it works with desktop is that the browser displays a QR
| code, and scan it with the camera app, which allows you to
| register or log in.
| mikelward wrote:
| Pretty sure you scan the QR code using your phone's camera.
| Trying to find a page that confirms this...
| tonymet wrote:
| thanks i re-read apple's docs and you're right. I was
| thinking (metaphorically) QR-code=Passkey but on desktop QR-
| code = lock, phone=Key
|
| Sign in on a different device with the passkey stored on your
| iPhone iPhone stores your passkeys in iCloud Keychain, so
| they're automatically used whenever you're signed in with
| your Apple ID on another device (iOS 16, iPadOS 16, macOS
| Ventura, or tvOS 16 required). However, if you use a device
| that's not associated with your Apple ID, you can still sign
| in to an account by using the passkey stored on your iPhone.
| Signing in usually consists of the following steps: Use the
| other device to go to your account sign-in screen. On the
| sign-in screen, tap the account name field. Tap "Other
| options," "Passkey from nearby device," or similar, then
| follow the onscreen instructions to display a QR code on the
| screen. Use your iPhone camera to scan the QR code.
|
| the docs https://support.apple.com/guide/iphone/sign-in-with-
| passkeys...
| wilkystyle wrote:
| Definitely agree with concerns regarding the UX. While I'm sure
| many of us here can understand the following paragraph from the
| article...
|
| > _In fact, if you sign in on a device shared with others, you
| should not create a passkey there. When you create a passkey on
| a device, anyone with access to that device and the ability to
| unlock it, can sign in to your Google Account._
|
| ... I wonder about the general layperson, especially older
| generations who (in my experience) tend not to use very secure
| passwords or MFA. Historically, all they would need to do is
| use their username and password, and now they are into their
| account, regardless of which device or location they are at.
| With passkeys, they have to not only learn a new login
| paradigm, but also remember that it 's different if they are
| signing in at e.g. the library vs on a desktop at home.
| waboremo wrote:
| To the second point: windows hello supports a variety of
| methods, one of them being without a fingerprint or camera. You
| can add it right now to your account.
|
| For linux users, not entirely sure which environments support
| any form of "biometrics".
| lostmsu wrote:
| What I don't understand is why with a passkey they don't ask for
| the second factor anymore. I feel like I would want that.
| linuxdude314 wrote:
| With the passkey you provide a second factor. Instead of the
| second factor being hacked into the auth system it's pushed
| down the stack into the standards that power passkeys (WebAuthn
| and FIDO2).
| lxgr wrote:
| You can choose to be asked for your password in addition to the
| passkey, no?
| howinteresting wrote:
| The theory is that the two factors are something you have (your
| phone) and something you are (your biometric).
| hospitalJail wrote:
| I'm happy that my important stuff is behind both a password +
| my phone.
|
| Having both behind your phone makes it easy to drug someone
| and get inside.
| howinteresting wrote:
| I largely agree, though with something like 1password it
| definitely is convenient to not type in your master
| password each time.
| pphysch wrote:
| If someone has your phone, they probably have your
| emails/authenticators, which means they have most of your
| passwords.
|
| Passkeys simplify the email reset/OTP loop, for the most
| part.
| hot_gril wrote:
| Even people using 2FA are probably storing the passwords on
| the phone via a password manager. Those without a password
| manager are probably reusing passwords or choosing insecure
| ones.
|
| I'd maybe be worried about the drugging if I'd ever heard
| of it happening to someone I know.
| derefr wrote:
| > Even people using 2FA are probably storing the
| passwords on the phone via a password manager.
|
| Yes, but this is the reason that password managers
| encrypt your other passwords with a master _password_ ,
| rather than a master biometric. The master password is
| still the "something you know" factor.
| hot_gril wrote:
| Most don't ask for the master password by default. Mac
| Keychain for example is "unlocked" at login unless you
| change that. iPhone Keychain will input passwords from
| just FaceID, no passcode prompt. Desktop Chrome and
| Firefox just autofill passwords no questions asked.
| derefr wrote:
| Password managers are designed around the idea that after
| you fully authenticate with your something-you-know
| credential, then they'll _mostly_ trust that you 're
| "still there" for a certain period of time, requiring
| only a something-you-are factor for _re_ -authentication
| while the something-you-know credential remains cached in
| memory. This "safety interval" usually ticks down more
| slowly while the device remains active (because
| continuous use implies "you" didn't wander off such that
| someone else could slip in), and more quickly while the
| device is idle/locked.
|
| When the "safety interval" expires, _or_ if you fully
| shut off the device, _or_ if you manually trigger a
| "something unusual is happening" mode
| (https://www.idownloadblog.com/2017/08/21/how-to-disable-
| touc...), then the password manager will lose this cached
| "already mostly satisfied" state, and so will require you
| to present the "actual" something-you-know credential
| again.
|
| > Mac Keychain for example is "unlocked" at login unless
| you change that.
|
| That's because you _just fully authenticated it_ by
| providing your master password (which for the macOS
| _local_ keychain is your _local account 's_ login
| password, which you had to present in order to unlock the
| FDE disk at startup.) In fact, ignoring FDE, this is what
| "logging in" _means_ on macOS: decrypting the local-
| account keychain.
|
| You'll notice that this doesn't apply to your iCloud
| keychain, since that doesn't use the same password as
| your local account, and so you didn't present that
| keychain's unlock password when you signed in.
|
| Interestingly, this _also_ doesn 't apply if you set your
| FDE unlock password to be different than your local
| account sign-in password. The FDE unlock password will do
| some magic that gets you logged into your account; but
| you will end up in your account with your local-account
| keychain still locked -- which will cause a lot of
| annoying prompts on login. (I ran macOS like this for a
| while back in ~2013, because I wanted a really secure
| boot passphrase, but didn't want to have to type it every
| time I locked the screen, and TouchID didn't exist yet on
| Macs. Wasn't worth it.)
|
| > iPhone Keychain will input passwords from just FaceID,
| no passcode prompt
|
| Again, that's because you signed into your phone _with_ a
| password recently-enough to make it satisfied with you;
| and this safety interval is much _wider_ on a phone than
| on a PC, because people keep phones "securely" with
| them, rather than e.g. letting them sit turned-on and
| unguarded at work when they go home for the day.
|
| You'll find that companies that have confidentiality
| requirements, deploy MDM policies for employees' mobile
| devices which make this safety interval much shorter --
| if they even allow it at all. (I worked for IBM Canada,
| and my phone would force a password unlock after being
| locked for just 30 seconds.)
|
| > Desktop Chrome and Firefox just autofill passwords no
| questions asked.
|
| This is true, and because of this, security people do
| _not_ consider these browser "autofill" features to be
| "password managers." Don't use them! They don't encrypt
| your passwords at rest, either! Viruses can steal your
| passwords right out of these autofill databases, and many
| modern viruses _do_ do that!
|
| (I would note that Chrome _does_ prompt you for your
| [local-account login] password in order to be able to
| _browse_ your autofill passwords -- which is at least
| _something_. But this is just security theatre; you can
| still read the passwords right off the disk without
| knowing your login password.)
| hot_gril wrote:
| > That's because you just fully authenticated it by
| providing your master password (which for the macOS local
| keychain is your local account's login password, which
| you had to present in order to unlock the FDE disk at
| startup.)
|
| I booted my laptop maybe several months ago and unlocked
| the screen with TouchID at the moment.
|
| > Interestingly, this also doesn't apply if you set your
| FDE unlock password to be different than your local
| account sign-in password. The FDE unlock password will do
| some magic that gets you logged into your account; but
| you will end up in your account with your local-account
| keychain still locked -- which will cause a lot of
| annoying prompts on login.
|
| Haha, I've been there by accident before. Or before FDE
| was a thing, having a different keychain vs login
| password because of some migration gone wrong.
|
| > Again, that's because you signed into your phone with a
| password recently-enough to make it satisfied with you
|
| Not sure about this. Usually I use FaceID. Does that ever
| expire and need the passcode? I don't think it does; the
| only times it asks iirc is when I fail the FaceID auth
| repeatedly (it doesn't like my second pair of glasses).
|
| > This is true, and because of this, security people do
| not consider these browser "autofill" features to be
| "password managers." Don't use them!
|
| Yeah, it's jank, but people do use them. Personally I use
| Safari for important stuff just because I want Keychain
| instead, but otherwise, your only option is dealing with
| a third-party password manager.
| lostmsu wrote:
| This makes no sense. Two different factors are two different
| factors. I might want two devices to be involved to setup a
| new login to critical services. One I'd always have at home
| so only with access both to me and my home you'd be able to
| login.
| ricardobeat wrote:
| I think you can do exactly that by using a Fido key instead
| of face / touch authentication for your device.
| lostmsu wrote:
| But that's the problem. If I understood correctly, Google
| won't ask you for your FIDO key if you use their passkey.
| braincode wrote:
| Not supported on free Google "legacy" org accounts (pre-Google
| Workspace), greeted with "Passkeys aren't allowed on this
| account." message :/
| jrm4 wrote:
| Again, a reminder that this is an _across the board terrible
| awful idea._
|
| It's all the dangers of 3rd party passwords - namely, before you
| had two parties, now you have three and thus _inherently_ less
| safe - but worse.
|
| Now, it's just even HARDER for you to control your own keys to
| your own stuff.
|
| There's one and only one reasonable way to execute this, and
| that's to include huge liability for the 3rd parties. Unless
| they'll pay up or otherwise fix in the event of a breach, this is
| a non-starter.
| gjsman-1000 wrote:
| I think it's a nonstarter because the n00bs and n0rm1es will
| have no idea what to make of it, and will quickly go back to
| passwords because they just work predictably.
|
| To me it reeks of something that looked great, when you show a
| room of engineers. But for regular people?
| ewoodrich wrote:
| Perhaps, but I recently added passkeys for Apple and Google
| accounts and the actual enrollment process and login didn't
| feel much more complicated than using the built in password
| manager for Chrome plus Touch or Face ID which people are
| already familiar with.
|
| That itself may be too complicated for some but it
| essentially was a few automatic prompts and instructions to
| scan my finger to login after it was done.
| musictubes wrote:
| I don't understand your concern. How is it more difficult to
| control the keys? Why is it less secure than 2fa solutions?
|
| Every worry I've heard about passkeys can be leveled at 2fa
| schemes as well. The upside of passkeys is they can't be
| phished, can't be revealed in data breaches, and can't be
| forgotten. What third company is involved? Are you thinking
| about syncing services? With the exception of Linux (for now),
| you can have passkeys enabled on any modern device. It is just
| public/private key sharing right?
|
| A bad actor would have to have your device and be able to
| unlock it in order to get access to your accounts secured with
| passkeys. Every time passkeys are mentioned on HN the FUD
| starts flying and people lose their minds. Passwords are
| terrible with many weaknesses. There isn't perfect security,
| there are always weaknesses but I have yet to be shown how
| passkeys are worse than passwords for typical users.
| theknocker wrote:
| [dead]
| awinter-py wrote:
| can someone who understands the cryptographic basis explain how
| centralized this is?
|
| it sounds like an app can consume passkey logins without
| registering with a provider?
|
| do providers phone home when I log in? can providers block an app
| from using them?
|
| can I self-host a provider, or is there a shortlist of approved
| providers?
|
| is there any provider that allows me to backup private key
| without sending it to their cloud?
|
| is it similar to openid in that it shares email etc with the app
| on login?
| cma wrote:
| It will really be a shame if we got ssh-like public key
| authentication for the web, but can't self-host it.
| [deleted]
| hoppyhoppy2 wrote:
| Related discussion yesterday at
| https://news.ycombinator.com/item?id=35801392
| judge2020 wrote:
| However, this is definitely a better article and clears up a
| lot of peoples' misconceptions present in that HN thread.
| belter wrote:
| This looks like an ssh public-private key scheme but with the
| private key locked to your (Google) device only. What am I
| missing. Why all the fuss?
| kccqzy wrote:
| It's an industry standard with good cross-platform support. So
| you can also choose to have the private key locked to your
| Apple device (with iCloud syncing) and Windows too.
| danShumway wrote:
| > with good cross-platform support
|
| Not to rehash the entire previous post, but this should have
| a giant asterisk next to it. It's very technically cross-
| platform, but there is no batch interchange format. If you
| use Safari, your passkeys are _only_ synced to iCloud. You
| can share them via AirDrop... to other Apple users. If you
| lose your phone, you can recover them... if you buy another
| iPhone.
|
| You can use your iPhone to log in on a Windows device, that
| part is cross-platform. And you can add that device as a
| second authenticator. But there's no actual portability
| there. You have (limited) cross-platform support (there is no
| Open Source platform authenticator that I'm aware of, and I'm
| not aware of any platform authenticator for Linux). But you
| can likely use passkeys with whatever platform you want. It's
| just once you choose a platform, there's no way to export
| from that platform unless you per-site add a new
| authenticator.
| derefr wrote:
| Passkeys are already device-bound; there would be no point
| in cross-ecosystem sync. They're maybe _backed up_ to a
| provider 's cloud, but that's in case you reformat your
| computer and want to restore it from backup; not for moving
| the passkey around.
|
| Think of a passkey as a device identity credential. It
| gives credential X that you can register on your backend as
| belonging to _device_ Y; not to _user_ Y. You need to
| additionally keep in your backend a mapping from _devices_
| to _users_ -- where almost certainly, a user HAS MANY
| devices.
|
| You know how, in well-thought-out auth systems, you can
| "sign in with a password" _and_ "sign in with [SSO
| provider]", and those will result in signing into the
| _same_ account, where both the password credential and the
| IdP subject-claim are separate "credentials" _bound to_
| that account?
|
| Each passkey is a "credential bound to the account" in that
| sense. You create one for each device, and they all log you
| into the same account.
|
| In short, they're a "third-party-ization" of the thing that
| Apple, Google, etc already do with their "you're trying to
| sign into your Apple/Google/etc account from a new device.
| Confirm this on an existing device" workflows -- where each
| device creates its own separate credential, that is
| _enrolled_ to your cloud account. This is that, but for any
| third party website, rather than just the cloud service
| itself.
| danShumway wrote:
| > Passkeys are already device-bound
|
| No, they're explicitly not, they're synced to the cloud
| for both iOS and Android. Microsoft also plans to do
| cloud sync (if they don't already).
|
| _Yubikeys_ are device identity credentials. Passkeys are
| user credentials, they get backed up off device. That 's
| a really big deal that both Google and Apple have been
| heavily advertising about their implementations -- you
| make a passkey on your phone, lose your phone, buy a new
| phone, and you get your passkey back when you sign into
| your account. They are very much user credentials rather
| than device credentials; anyone who has access to your
| iCloud can use your passkeys.
|
| Passkeys aren't bound to your iPhone, but they are
| inexplicably bound to your Apple devices. That's the
| portability problem. The major companies (Google,
| Microsoft, Apple) got rid of device-bound keys. But they
| kept the platform lock-in.
|
| > where almost certainly, a user HAS MANY devices.
|
| Speak for yourself, I have exactly one device that will
| work as an authenticator, and even it only works as an
| authenticator because I've been too lazy to install
| LineageOS on it.
|
| Most people own one phone and a laptop, and they
| frequently travel with both of them at the same time. I
| think Google/Microsoft/Apple went the cloud-sync
| direction partially in acknowledgement of the fact that
| "use multiple devices" doesn't really work for everyone.
| derefr wrote:
| > Passkeys are bigger than that, they're not device
| bound. That's a really big deal that both Google and
| Apple have been advertising about their implementations
| -- you make a passkey on your phone, lose your phone, buy
| a new phone, and you get your passkey back.
|
| You're interpreting "device" differently than I am, here.
| Maybe let me use a different word.
|
| There's a physical hardware device (the device's "body")
| and then there's a particular _installation_ of an OS
| (the device 's "soul.") Unlike humans, these device
| "souls" can leave and come back (restoring from backup)
| or be reincarnated into a different body (transferring a
| backup to a new hardware device.)
|
| What Apple, Google, etc. are claiming is that passkey
| credentials are bound to the _soul of your device_ -- the
| unique installation session that resulted in a unique
| product-key "activation" in their servers -- rather than
| to the _body of your device_. So wherever the
| installation goes, the passkeys go along with it.
|
| But this does not mean that passkeys are portable between
| installations. They still inherently represent "devices"
| -- just _semantic, abstract_ devices, that may be
| incarnated at any given time in zero or one physical
| hardware devices.
|
| And, again, this is exactly how Apple's and Google's own
| device enrolment for sign-in to their respective cloud
| accounts works. I have devices listed in my iCloud
| account that currently have no "incarnated" form -- the
| hardware was wiped, sold, and is now being used by
| someone else! -- but those _unique installations_ do
| still "exist" and could be "reincarnated", as long as I
| keep my iCloud Backup of them.
| danShumway wrote:
| > There's a physical hardware device (the device's
| "body") and then there's a particular installation of an
| OS (the device's "soul.")
|
| This is an interesting theory of device uniqueness that
| would be potentially cool to build a service around, but
| it is inaccurate to how passkeys are implemented.
|
| iCloud sync is cross-device; if you make a passkey on
| your iOS device, it gets synced to your Mac. You can also
| share them with other iOS devices that aren't even linked
| to your iCloud account using Airdrop. They're very
| separate from the OS or "instance" of your device's
| software.
|
| And in fact, you actually can't use platform
| authentication in Safari unless you sign into an iCloud
| account to sync your keys. Not only is it not tied to the
| "soul" of the device, you're not _allowed_ to tie it to
| the soul of the device. Apple requires you to tie it to
| your account.
| [deleted]
| linuxdude314 wrote:
| It's just a new name for WebAuthn/FIDO2 credentials. It's
| easier to say, remember, and write the thus more marketable.
|
| This support has existed for a while, but not with this
| rebrand. I hope more companies will adopt this approach as it
| seems like an effective strategy.
| butz wrote:
| "They work on all major platforms and browsers"
|
| Is any Linux distribution, let's say Ubuntu or Fedora a "major
| platform"? Is Firefox a "major browser"?
| linuxdude314 wrote:
| It's going to be anything that supports WebAuthn/FIDO2
| credentials.
|
| There are PAM modules you can install and configure for Linux
| and OSX.
|
| Browser support is slightly different depending on the browser,
| but support for credential creation and assertion using a U2F
| Token (passkey) is supported by Edge, Chrome, and Firefox.
| danShumway wrote:
| Very important caveat, this is only for roaming
| authenticators like Yubikeys (https://webauthn.me/browser-
| support). There is not (that I'm aware of) any support for
| platform authenticators on Linux (which is what most users
| will be thinking of when they use the word "passkey").
|
| Roaming authentication is well supported on Linux, and you
| can cross-device sign in using your iOS/Android phone
| (assuming you haven't DeGoogled it), but the Mac/Windows
| experience of just having the computer itself act as an
| authenticator isn't supported. You're still going to need to
| use a locked down, proprietary device to log in, it's just
| that the proprietary device can help you log in on your Open
| device.
| aftbit wrote:
| Can you link to more documentation on this issue? Why can
| my Linux box not act as an authenticator, perhaps using TPM
| or just with software security?
| derefr wrote:
| It's probably because biometrics support (via fingerprint
| sensors et al) isn't a standard part of the Linux
| desktop/notebook "platform"; and so most Linux devices
| would just be prompting you for a _password_ to unlock
| your _passkey_ anyway (like prompting for an SSH
| passphrase to unlock an SSH key) -- at which point, why
| bother, if the whole goal was just to eliminate the
| possibility of being phished?
| danShumway wrote:
| iCloud syncing already has this problem though. If I lose
| an iPhone and I buy a new iPhone and sign into an iCloud
| account, my passkeys will get synced.
|
| So I'm not sure I believe that really strong stances on
| potential phishing attacks are the real reason here.
| Passkeys with cloud sync are phishable.
|
| > why bother
|
| A single master password would still be a massive
| increase in security and would still eliminate a ton of
| phishing attacks. The cool parts of passkey aren't really
| the biometrics, the cool parts are how they get shared
| with websites. That's where the real phishing protection
| comes from.
| rootusrootus wrote:
| > If I lose an iPhone and I buy a new iPhone and sign
| into an iCloud account
|
| Have you done that recently? What a godforsaken pain in
| the ass it is, _especially_ if you don 't have another
| Apple device handy that you are already signed in to.
| danShumway wrote:
| It has been a fairly long while since I've needed to sync
| an iCloud account to a new computer. I'm mainly going off
| of https://support.apple.com/en-us/HT204974 so it
| definitely could be oversimplifying the requirements.
|
| Though even ignoring SMS and recovery codes, I'm not sure
| that using a second Apple device as 2FA would change
| anything; we generally don't consider one-time codes to
| be unphishable.
|
| But again, that's only me looking at the docs. Is there
| something I'm missing about the process that would block
| a phisher from using an iCloud password plus an SMS
| hijacking attack or phished one-time code to log in and
| set one of their devices as trusted?
| lxgr wrote:
| Isn't an SMS-OTP as well as your old device's unlock code
| enough?
| danShumway wrote:
| > Why can my Linux box not act as an authenticator
|
| That is a really good question.
|
| For whatever reason, I'm not aware of a single Open
| Source platform authenticator for any platform. It seems
| to me like that would be a pretty big priority for an
| Open standard, but what do I know?
|
| Google has said they have "no plans" to support platform
| authentication on Linux[0]. I don't know if this is just
| them saying they don't plan to build a platform
| authenticator themselves, or if they're saying that if a
| Linux box advertises that it has a platform
| authenticator, they're not going to trust it.
|
| Either way, passkeys basically require you to either buy
| a Yubikey/dongle (which will not support cloud sync) or
| to use a proprietary OS as your authenticator.
|
| https://developers.google.com/identity/passkeys/supported
| -en...
| eikenberry wrote:
| If this is FIDO2, then it seems these projects might be
| useful on Linux...
|
| https://github.com/bulwarkid
|
| https://bulwark.id/
| lapcat wrote:
| https://news.ycombinator.com/item?id=35801392 (603 comments)
| lumb63 wrote:
| How is this, practically, any better than existing 2FA? A 2FA
| code is stored on a device just like a passkey is.
|
| Passwords had a security and a usability problem, I guess, and so
| the solution was to add 2FA, which allegedly improves security.
| Now, we're dropping the security of passwords to solve the
| usability issue. This doesn't seem to be a big improvement to me.
| hyperhopper wrote:
| It's different.
|
| 2FA just means 2 factors.
|
| Passkeys are just a factor. Usually a more secure factor than a
| password.
| m-p-3 wrote:
| and the Passkeys requires to be secured by a PIN or
| biometric.
|
| So Passkey = Something you have, PIN = Something you know.
| hot_gril wrote:
| It's less secure than 2FA and more secure than passwords. How
| is it practically better than 2FA, because it's easier.
| rootusrootus wrote:
| Given that most regular 2FA is implemented with SMS and
| doesn't even require stealing someone's device, I think
| passkeys are arguably more secure.
| hot_gril wrote:
| Oh totally. I was only thinking about the TOTP 2FA, for
| which I also have a giant rant about being user-hostile.
| divan wrote:
| > 2FA code is stored on the device
|
| That's not how 2FA works.
| lumb63 wrote:
| I understand, but your statement feels pedantic. Practically,
| if someone has access to your device, your 2FA codes are
| compromised.
| divan wrote:
| Yes, Passkeys do not offer much against rubber-hose
| cryptanalysis. Actually, it's a bit worse than passwords as
| it doesn't require captured human to be concious.
|
| I believe Passkeys are great for those whose threat profile
| doesn't include physical assault risks.
| devman0 wrote:
| You can use PIN for Passkey instead of Fingerprints
| quenix wrote:
| What? It is how it works. The TOTP secret is stored on device
| which can be used to arbitrarily generate codes.
| divan wrote:
| TOTP is not 2FA, but can be used for 2FA. What is the
| "secret stored on device" when SMS is used for 2FA?
|
| Passkeys are stored in Secure Enclave on Apple devices, or
| on YubiKeys. Not sure about Androids.
| ForHackernews wrote:
| > What is the "secret stored on device" when SMS is used
| for 2FA?
|
| IMEI number?
| hbn wrote:
| When you request an SMS 2FA code, they're blindly sending
| an auth code to your phone number over SMS, that's all
| they know. That number could be registered to any SIM
| card which could be in any device. Someone could have
| socially engineered a rep at your carrier to have that
| number transferred to their device, which is a real thing
| that happens.
| hnburnsy wrote:
| >Creating a passkey on your Google Account makes it an option for
| sign-in. Existing methods, including your password, will still
| work in case you need them, for example when using devices that
| don't support passkeys yet. Passkeys are still new and it will
| take some time before they work everywhere. However, creating a
| passkey today still comes with security benefits as it allows us
| to pay closer attention to the sign-ins that fall back to
| passwords. Over time, we'll increasingly scrutinize these as
| passkeys gain broader support and familiarity.
|
| So my password that I stupidly shared among my accounts and was
| then leaked, can still be used to compromise my Google Account.
|
| Wake me when I can create a Google Account without a password,
| email, or phone number, period.
| Andrex wrote:
| Probably not far off.
|
| Sounds like with other methods (SMS 2FA, USB hardware key,
| etc.) you may be able to eventually turn password sign-in off
| on your Google account and use passkeys exclusively.
| lxgr wrote:
| A phone number is both an authentication mode and rudimentary
| bot/sockpuppet protection. (It's pretty bad at both, but that's
| a different story.)
|
| Passkeys can substitute the former, but (by design) not the
| latter.
| rootveg wrote:
| "So long passwords, thanks for all the phish" that's pretty funny
| actually
| bt4u wrote:
| [dead]
| hnburnsy wrote:
| Click bait title, the password is not going away, unlike the
| dolphins who left earth...
|
| >Creating a passkey on your Google Account makes it an option
| for sign-in. Existing methods, including your password, will
| still work in case you need them, for example when using
| devices that don't support passkeys yet. Passkeys are still new
| and it will take some time before they work everywhere.
| However, creating a passkey today still comes with security
| benefits as it allows us to pay closer attention to the sign-
| ins that fall back to passwords. Over time, we'll increasingly
| scrutinize these as passkeys gain broader support and
| familiarity.
| lelandbatey wrote:
| How do I back these up in case of catastrophic data loss, such as
| my house and all my possessions burning down (there are
| approximately 350000 house fires a year in the USA, so it's worth
| worrying about when its your entire digital life)? I take my
| security safety, but I take the _durability_ of my digital life
| _much_ more seriously.
|
| Right now, I am able to back up all my personal passwords and all
| my personal TOTP secrets into printed paper form that I keep in
| tamper-evident packaging and distribute to a safe-deposit box and
| the basements/attics of different trusted friends/family members.
| The printed packet of paper has instructions on how to use it,
| the passwords and TOTP secrets themselves, and the brief source
| code for one program, one that lets you generate TOTP codes from
| all my secrets (TOTP is very simple, it's like 30 lines of
| python[0]). I've tested it all and it is sufficient to access any
| account I have. Since it's all recorded on paper, each packet
| will function for my entire lifetime; I don't have to worry about
| storing a device and that device's charging/power equipment, and
| I don't have to worry about that device's capacitors or battery
| going bad in 10 years.
|
| So in the world of "passkeys", how do I simply and durably record
| them so that if need be, someone who is not me, who I've never
| met, and who has access to none of my electronic devices, can
| authenticate as me given that this person is willing to put
| several days effort into dealing with my authentication archive
| (e.g. an estate lawyer)?
|
| I know that this is "possible"; it's all based on data and
| secrets recorded _somewhere_ , but I'm having a hard time
| understanding the FIDO description, and I don't see an Open-
| Source equivalent of what Google's offering here. Is there a
| "KeePassX" of the passkey world?
|
| [0] - https://github.com/susam/mintotp/blob/main/mintotp.py
| lxgr wrote:
| Register a Yubikey in addition to all the services supporting
| WebAuthN and put it in the tamper-evident envelope?
|
| > Is there a "KeePassX" of the passkey world?
|
| Both 1Password and Bitwarden have announced support as soon as
| OS support will become available, the latter being open source.
| hulitu wrote:
| > Unlike passwords, passkeys can only exist on your devices. They
| cannot be written down or accidentally given to a bad actor.
|
| Pegasus ?
| okasaki wrote:
| "So long passwords, thanks for all the phish"
|
| "The beginning of the end of the password"
|
| This is confusing. Is there some plan on Google's part to kill
| passwords that I'm not aware of?
| neuronexmachina wrote:
| That's basically the premise of the FIDO Alliance, which Google
| is part of: https://fidoalliance.org/what-is-fido/
| aksss wrote:
| Also relevant link - FIDO's press release about Apple, MS,
| Google commitment to passwordless sign-ins.
| https://fidoalliance.org/apple-google-and-microsoft-
| commit-t...
| kccqzy wrote:
| There is a plan to kill passwords, but the plan isn't just by
| Google. It's a unified plans across major players. In terms of
| marketing, anecdotally I see far more mentions of passkeys by
| Apple and related discussions.
|
| Apple: https://developer.apple.com/videos/play/wwdc2021/10106/
| https://developer.apple.com/passkeys/
| madjam002 wrote:
| Yet they still don't have a way to disable the 2FA prompt offered
| in the Gmail app (called "Google prompt").
|
| It's a shame that you can add hardware security keys to your
| Google account and all of that can be bypassed just by pressing
| "approve" in the Gmail app when you're trying to login.
|
| The attack vector that I'm thinking of here is your phone being
| stolen while in public while unlocked, it doesn't even prompt for
| further biometrics when approving a login from the app.
| explodingwaffle wrote:
| Yep. I complained about that on HN recently-
| https://news.ycombinator.com/item?id=35692884 though since then
| it has, at least started working again.
|
| I didn't mention it in that post but that is _exactly_ the
| attack vector I had in mind also- even if someone stole my
| phone, Touch ID should stop them from getting at my passwords.
| dheera wrote:
| > The attack vector that I'm thinking of here is your phone
| being stolen
|
| This is exactly why I'm a big fan of larger, heavier devices,
| such as my rack-mounted desktop PC, being their own 2FA device.
| It's pretty hard to steal my 4U desktop that is bolted down,
| there's no reason why it should depend on anything else for
| 2FA.
|
| Similarly, laptops should be their own 2FA device and not
| depend on a phone, since people are generally more careful to
| not take laptops into high-crime areas.
| lxgr wrote:
| > Yet they still don't have a way to disable the 2FA prompt
| offered in the Gmail app (called "Google prompt").
|
| There used to be a way to intentionally (after 2FA) add or
| remove devices to "Google prompt". These days, it just seems to
| be any device I'm logged in to, sadly.
| judge2020 wrote:
| https://landing.google.com/advancedprotection/
|
| AFAIK this removes the ability to use a phone prompt as 2fa.
| madjam002 wrote:
| Advanced Protection is nice but practically a non starter or
| very difficult in a lot of situations, e.g if you're
| travelling and all of your security keys get stolen and your
| backup security key is half way across the globe, you'll wish
| you had 2FA backup codes then.
| remus wrote:
| > Advanced Protection is nice but practically a non starter
| or very difficult in a lot of situations, e.g if you're
| travelling and all of your security keys get stolen and
| your backup security key is half way across the globe,
| you'll wish you had 2FA backup codes then.
|
| All security is a trade off. For a good chunk of people
| that is a rare enough occurrence that it is a good trade
| off for them.
| throw10920 wrote:
| > All security is a trade off.
|
| Irrelevant to the problem of "I want to just disable
| phone prompt of 2FA without everything else included with
| Advanced Protection" - there's no intrinsic "security
| tradeoff" here, just bad and overly restricting design
| decisions by Google.
| madjam002 wrote:
| Yeah for sure, which is why I'm not fussed about not
| being able to use Advanced Protection because I don't fit
| in with their target audience.
|
| But I do wish that people on standard accounts could just
| disable their forced "Google Prompt" authentication
| method and just use their own 2FA security keys with
| fallback to backup codes.
| TeMPOraL wrote:
| > _All security is a trade off. For a good chunk of
| people that is a rare enough occurrence that it is a good
| trade off for them._
|
| Except most people are operating under a flawed
| assumption that the trade-off with Google is like a
| trade-off with any other institution - that is, if the
| worst happens, you can get a human on the phone, or visit
| a branch office, and get the issue sorted out. This
| critical fallback is, unfortunately, missing for Google
| and many other on-line service providers.
| TheNewsIsHere wrote:
| My only complaint about the tradeoffs made in Google's
| current implementation of Advanced Protection is that I
| can't (even if awkwardly and with difficulty) allowlist
| any given third party OAuth.
|
| So, if I want to, say, authenticate my Gmail account with
| Fastmail or ProtonMail, I can't also be using Advanced
| Protection. [0]
|
| With Google Workspace, admins can allowlist OAuth
| applications registered with Google APIs for users who
| use Advanced Protection. Consumer accounts have no such
| feature.
|
| I am not arguing the logic; I understand it. I just wish
| it were different. I suspect that passkeys are one
| stepping stone on the road to increasing account security
| baselines to be more like Advanced Protection, which may
| ultimately give me what I want one day. Wishful thinking,
| perhaps.
|
| [0] These are OTOH examples, which may not be accurate as
| of this writing.
| toomuchtodo wrote:
| I have a trusted family member who maintains a copy of all
| of my recovery codes. In event of disaster, I call and
| provide a previously shared pass phrase, and recovery codes
| will be provided. Something to consider depending on your
| daily driver threat model and tail risk considerations.
|
| (frequent international travel while having strong opsec)
| madjam002 wrote:
| But if you enable Advanced Protection then
| recovery/backup codes are disabled right? (Maybe I'm
| wrong)
|
| So the only option to have recovery codes available is to
| not used advanced protection and then have this "Google
| Prompt" forced on you, which I'd like to disable as it is
| another physical attack vector which is undesirable
| especially when travelling.
___________________________________________________________________
(page generated 2023-05-04 23:00 UTC)