[HN Gopher] Passage by 1Password
___________________________________________________________________
Passage by 1Password
Author : lkurtz
Score : 26 points
Date : 2023-12-05 18:51 UTC (4 hours ago)
(HTM) web link (passage.1password.com)
(TXT) w3m dump (passage.1password.com)
| jiayo wrote:
| I'm very bearish on Passkeys as a concept. As a technologist and
| security advocate, I'm glad that it helps to defeat phishing
| attacks, and the problem of reusing passwords/credential
| stuffing. But the UX is just not there yet. I jumped on the hype
| train and set up Passkeys for my Google account using 1Password,
| from Chrome on my iPhone. At some point, the enrolment procedure
| "failed", that is to say, my passkey was set up, but I didn't
| know it, so I repeated the procedure. This meant I had two
| "identical" passkeys for Google in my 1password, and two passkeys
| to which to sign into Google.
|
| Neither Google nor 1password had any way to distinguish which key
| was which. There's no export functionality (yes, I understand
| this is by design). There's no (user facing) key IDs. So, my
| choices were: accept that I have two passkeys, and never know
| which is which; risk deleting one or the other, or abandon the
| whole notion and go back to hardware 2FA.
|
| This doesn't even get into the mess of: * browser based passkeys:
| what if I switch computers or phones? Now I have the "yubikey
| problem (have 3 so you can safely lose 1)" for every single
| device I own. * hardware security tokens (Yubikey): in the case
| of Google, they aren't accepted as a "sign-in" passkey, only a
| "verification" passkey. However, a browser passkey is accepted.
| Do I need hardware 2FA? Do I need a password? I have no idea.
|
| Let's be clear. There are absolutely solutions to all of the
| above. I am certain I made bad assumptions or mistakes here. But
| I also have been using computers with a bent towards security for
| my entire life. If I can't get this right, how is the average
| user being pushed to go "passwordless" on eBay going to deal with
| this mess in 3 years?
|
| If you're a company considering implementing this, I'd be taking
| a very hard look at the ongoing support costs dealing with
| confused and panicked users locked out of their accounts.
| peter_l_downs wrote:
| I'm a fan of passkeys and bullish on continued UX improvements
| but completely agree with you. Even basic things like "when I'm
| on a website, show all my passkeys for it and where they're
| stored (browser, 1password, macos keychain)" or "when I'm
| adding a passkey for a site, properly choose where it's stored
| and know what other devices it will be synced to or accessible
| from" are hard or impossible or confusing. Improvements needed.
|
| If I were maintaining an auth system right now, I'd make sure
| webauthn was supported as both a login and 2fa method, make
| sure i didnt require hardware-scoped keys, and leave them off
| by default. Advanced users can opt in and support themselves.
| 2fa defaults to the standard qr code. Logging in allows "send
| me a magic link" but defaults to email and password. No
| usernames. I feel like thats reasonable?
| keep_reading wrote:
| I'm bullish based on my experience, but I'm using Apple's
| implementation and my Yubikeys. It has been flawless so far
| donmcronald wrote:
| I'm bullish and I think Passkeys, or some variant of on-behalf-
| of attestation, could be on of the worst technology related
| things to ever happen to the average person.
|
| The reason I'm bullish is because _all_ of the entrenched tech
| players are pushing them. The reason I think it 's terrible is
| because the entire concept is dangerous. It's "one thing you
| have" (a key) that can attest to your identity. Whether or not
| that's attesting _for_ you or _against_ you is yet to be seen
| and I 'd bet the farm on _against_.
|
| As soon as tech companies have the ability to force you into
| using some type of device for authentication and authorization,
| I think the floodgates will open on abuse. It's a huge building
| block on the road to ensuring people never own anything,
| because per-use access can easily be gated now, and I think
| that's why big tech wants it so bad. They're going to get "a
| cut" for doing the auth, so why not, right?
|
| It doesn't matter if tech enthusiasts resist either. We've seen
| the same story play out over and over. Developers gave Apple
| the keys to the kingdom for app distribution and rolled over as
| Adobe started charging subscriptions for desktop software. As
| soon as enough uninformed users accept what they're being
| pushed, it'll become a requirement and your options will be
| capitulation or exclusion.
|
| Consider whether or not you'd want the right to use your car
| tied to a passkey that contacts the manufacturer, attests to
| your identity (authentication), and needs to get a token
| (authorization) before it'll start. People would never tolerate
| a password requirement to start their car, but a Passkey that's
| built in (ex: to a phone or watch) and works OTA via the cell
| network will easily be sold as good security, but it's really
| just to benefit the company leasing you the car because they
| can revoke access at any time.
| catoc wrote:
| This! Just this!
|
| Please take note of what @donmcronald says here - phrased
| before I could, and better than I could.
|
| The concept of Passkeys sounds great, but the way it will be
| implemented will result in a massively net-negative privacy
| impact that will be very hard to escape from.
| ivancho wrote:
| I mean, most of your arguments could be applied equally
| against credit/debit cards. It's "one thing you have" that
| unlocks access to your money. It can easily be revoked by the
| bank, gives them full view into your entire life (or at least
| the parts you pay for), and makes recurring payments really
| easy. And yet most people don't go around with chequebooks or
| wads of cash
| dbbk wrote:
| I've been a software engineer for 17 years and even I can't
| wrap my head around the UX of this. It's totally dead in the
| water until something changes.
___________________________________________________________________
(page generated 2023-12-05 23:02 UTC)