[HN Gopher] Passkeys: A shattered dream
___________________________________________________________________
Passkeys: A shattered dream
Author : nmjenkins
Score : 588 points
Date : 2024-04-26 04:36 UTC (18 hours ago)
(HTM) web link (fy.blackhats.net.au)
(TXT) w3m dump (fy.blackhats.net.au)
| md_ wrote:
| I use iCloud's Passkeys extensively and have never had saved
| Passkeys "wiped out". I am not disputing that data loss bugs can
| happen, but three times for one user sounds pretty weird given
| the maturity of the ecosystem.
|
| The most obvious explanations seem to me to be:
|
| a) Apple loses data (presumably not just Passkeys, but also
| photos, passwords, and other highly noticeable stuff) all the
| time, and I've been lucky for the last ten years. Hundreds of
| millions of Apple users just learn to live with this.
|
| b) The author is doing something weird.
|
| c) This is hyperbole.
|
| I'm probably picking nits, but it's like an article raising a
| bunch of legitimate criticisms of the internal combustion engine
| mentioning that the author's car has, while sitting in the
| parking lot, simply exploded on three separate occasions. Like,
| maybe?
| buildbot wrote:
| I was about to type something similar to this as well! I use
| passkeys pretty heavily, with iCloud sync. Never had an issue.
| The only similar issue I can think of is sometimes my Macbook
| will loose the contents of the on device wallet, including in
| one case an ssh key stored there. That was somewhat annoying!
| cjk2 wrote:
| Agreed. I'm not so sure that some of the iCloud data loss bugs
| people talk about are actual data loss bugs. I've had a few
| issues over the years.
|
| Firstly I spent weeks chasing down what I thought was a data
| loss bug in iCloud. After much effort I managed to reproduce
| it. Turned out it was an issue with TeXshop rather than iCloud.
|
| Secondly, the one time I had a photo lost, it wasn't lost. I
| just couldn't find it in the 12000 photos I had. It wasn't
| where I'd left it.
|
| The third one was a data loss bug, was reproducible, was
| reported to Apple and was fixed. This was due to how Numbers
| handles three devices and how it decides the winner of a
| conflicting change and was an edge case as number 1 awkward
| customer.
|
| YMMV but user testimony may be as reliable as eyewitness
| reports.
| md_ wrote:
| To be clear, I don't work for Apple. :) And I'm not
| discounting that there are usage patterns that might lead to
| persistent bad experiences (like your example with Numbers).
|
| But the implication that Keychain just kind of _forgets_
| saved Passkeys once in a while seems alarmist and probably
| unfounded.
| cjk2 wrote:
| Yeah exactly. It is possible that some expiry or provider
| specific bug may lead to revocation? I am not sure how it
| works entirely.
|
| I will say that there are some very well known backup and
| restore issues with keychain however so I keep anything
| critical in MacPass as the primary copy.
| jsnell wrote:
| It can't be hyperbole, their partner's car keeps exploding too!
| So often that they're switching back to a four horse carriage.
| flup wrote:
| One thing that comes to mind is with the earlier WebAuthn
| implementations in iOS, before they were stored in iCloud and
| called passkeys, there was no management interface for stored
| passkeys and 'clear website data' (to delete cookies etc.)
| would actually erase all credentials permanently. It was
| useless this way.
| usrusr wrote:
| Why useless? Not an authentication scheme to and all other
| authentication schemes, but certainly a (much) better
| successor to the login cookie?
| flup wrote:
| I do not mean passkeys in general but early iOS
| implementation was useless since it deleted passkeys along
| with your cookies and other website data. The passkey iOS
| implementation is useful in its current form.
| MichaelMug wrote:
| > I use iCloud's Passkeys extensively
|
| So what happens if you want to migrate away from iCloud for the
| storage of passkeys?
| 4ad wrote:
| I can't speak for OP, but for every service that I use
| passkeys with I enrolled both iCloud Passkeys (for
| convenience) and _several_ YubiKeys (for portability and
| backup).
|
| This is not different at all from a SSH public/private key
| combo. You are not supposed to duplicate SSH keys!
| md_ wrote:
| Your answer is totally reasonable, but I admit I don't have
| time for that in most cases.
|
| 1. Most services are not Passkey-only--most people are
| using it as a password alternative (e.g. eBay) or a second-
| factor alternative. So losing it won't lock me out.
|
| 2. A very small number (e.g. Google) let you configure
| Passkey as your sole second factor. For those, I am indeed
| careful to do what you do and have duplicates.
|
| I do think this is kind of bad? So the grandparent totally
| has a point here: services find it hard to do _only_
| Passkeys (and thus realize the security benefits).
|
| But, as a user, it's not something I worry about a lot, to
| be honest.
| drxzcl wrote:
| You generally enroll a passkey for a single device or
| connected group of devices. My icloud-syncing devices has a
| passkey. My windows laptop has another. My desktop has yet
| another. I have also enrolled my yubikey.
|
| I could stop using my idevices tomorrow and not be negatively
| influenced.
| nebulous1 wrote:
| > b) The author is doing something weird.
|
| The author is the main dev of an identity management platform
| and called kanidm, so yeah I'd wager their usage is fairly non-
| standard. That said, it should be almost impossible for it to
| happen anyway.
|
| Also, that doesn't apply to his partner.
| arianvanp wrote:
| It's not hyperbole. I recently (few weeks ago) got locked out
| of my GitHub account after iCloud Keychain thrashed my passkey
| and after analyzing the root cause it turned out to be a bug in
| webkit (that is now fixed in Safari technology preview after me
| raising it with the Webkit team)
|
| https://bugs.webkit.org/show_bug.cgi?id=270553
| cco wrote:
| Oof, the Passkeys ecosystem is incredibly complex. Even as
| someone that deals with it day in and day out at $CURRENT_CO, it
| can be a headache.
|
| As an exercise from a developer's perspective, try creating a
| chart of every device type (mobile, desktop etc), browser, and
| Passkeys platform provider (Apple, Microsoft etc). Then fill out
| how each behaves across each combination, it is a nightmare!
|
| I'm hopeful that we'll see more cooperation across Passkey
| providers to align both the devx and UX to increase adoption
| where it makes sense. Not holding my breath too much though.
| md_ wrote:
| Definitely this. I think the worst aspect of Passkeys is that
| the noble goals (public key crypto! unphisability!) seem to
| somewhat unavoidably wipe out one of the--in hindsight--really
| valuable aspects of passwords-in-a-password-manager:
|
| That you can always just copy them out, put them in a different
| password manager, or write them on a post-it.
|
| That said, I think this is a byproduct of the design space
| being complex (as you suggest) and not, as the author seems to
| feel, "thought leaders" or malice.
| rekoil wrote:
| I've been using Passkeys saved in 1Password, I thought that
| gave me the power to transfer them, but I just looked and
| apparently the export feature of 1P doesn't allow exporting
| the Passkeys, it just tells you you need to create new ones
| in your new password manager, so that's pretty crappy...
| dariosalvi78 wrote:
| I am exploring this now, actually got 2 students doing their
| thesis on this. It's very complicated and unnecessarily so.
|
| My conclusion so far is that it's a promising technology, but
| no way as mature as I'd like it to be. Unfortunately we are
| stuck with emails and passwords for the foreseeable future, at
| least as a back-up mechanism for credentials recovery, which,
| funnily, makes the whole thing pretty much pointless.
| knallfrosch wrote:
| Noone put any thought into the goals of passkeys and it
| shows.
|
| You have to beat email/password with optional password
| manager (syncing, remembering , autofilling) and optional MFA
| (physical proof)
|
| passkeys cant beat that in any area because they have no
| goals
| IshKebab wrote:
| Yeah I agree. I am familiar with crypto and public key
| authentication and password hashing and so on, and I cannot
| follow all of the terms and use modes. To the average user it's
| going to be a complete black box. They won't have a clue what's
| going on.
|
| With passwords it's fairly obvious. Even if you don't know
| about password hashing, semantically it is the same as how you
| would obviously expect. Same with password managers. It's
| obvious what they're doing.
|
| So I think this would fail even if it didn't have all the
| problems the author mentioned - it's simply too complicated for
| normal people to understand and trust.
| cmdli wrote:
| Honestly, I think a big part of the problem is that passkeys have
| been tied to hardware devices and they don't have to be. A
| passkey is just a public key credential, and it can easily be
| provided by software as well as by hardware. You would still get
| many of the benefits (better UX, automatically secure, prevents
| phishing) and the overall customer experience could be a lot
| better. Imagine if passkeys could be saved, transferred, and
| imported as easily as a PDF. Instead, we get a bunch of walled
| gardens where Apple/Google/Microsoft/etc are trying to be the
| only provider you use.
| renewiltord wrote:
| I have my passkeys in bitwarden.
| minebreaker wrote:
| Does BitWarden support passkey export now?
| renewiltord wrote:
| Export to JSON and then grep for `fido2Credentials`
| austinallegro wrote:
| Johnny Hates Jazz.
| echoangle wrote:
| Is the author suggesting he's not traveling to the US out of
| security concerns? Is that really a thing?
| youngtaff wrote:
| Yes, there are plenty of people who avoid travelling to the US
| echoangle wrote:
| I know that, but I didn't think it was because of security. I
| don't think of the US as particularly dangerous, but maybe my
| perception is wrong...
| RVuRnvbM2e wrote:
| The homicide rate is 8x Australia's, so yeah it is by
| comparison.
| _ZeD_ wrote:
| I know that US is vast, and there are millions of good
| places where one could feel safe, but I assure you, from
| the outside sometimes is seems you live in a mad max
| alternate universe
| echoangle wrote:
| I'm from Europe, but I would have no problem going to a
| tech meeting with some google engineers in Silicon
| Valley.
| JonChesterfield wrote:
| It's the guns and the police.
|
| People get angry or frightened. It's better for everyone
| else if they're not carrying a firearms at that point.
|
| Policing a nation where everyone is armed means the police
| are heavily armed and the non-insane ones very frightened
| all the time. See above.
| lambdaone wrote:
| Worse than that, having a gun doesn't make you safer; it
| increases the risk to everyone in your household. But I
| can absolutely understand why fear drives people to own
| guns -- it's a vicious circle as increased gun ownership
| drives fear, which in turn drives even more gun
| purchases...
| bildung wrote:
| Homicide rate is 10x the rate of EU and over 30x the rate
| of Japan:
| https://independentaustralia.net/politics/politics-
| display/a...
|
| Rape rate is about 3x the rate of EU: https://www.civitas.o
| rg.uk/content/files/crime_stats_oecdjan...
|
| People killed by police (population adjusted) is about 30x
| the rate of Germany:
| https://www.statista.com/statistics/585152/people-shot-to-
| de... https://polizeischuesse.cilip.de/?p=1&year=2023
| echoangle wrote:
| Sure, but those rates are also really low. That's a bit
| like saying you're scared of using your car because a
| plane is much safer. The chance of getting hurt while
| visiting a meeting in Silicon Valley is still one in a
| million.
| UberFly wrote:
| Likely out of ignorance of actual violent crime statistics.
| rob74 wrote:
| Apparently... of course, the threat of "mass casualty violence
| and terrorist attacks" is real, but you're probably still more
| likely to die in a plane crash while getting to the US (or in a
| car accident while there) than in a shooting or terrorist
| attack. And if you insist on only travelling to countries that
| have a lower level of violent crime than Australia, you
| probably won't get around much
| (https://worldpopulationreview.com/country-
| rankings/violent-c...)...
| squigz wrote:
| Oops, you forgot the other 2 travel advisories the author
| quoted in that part:
|
| - "Violent crime is more common in the US than in Australia"
|
| - "Medical costs in the US are extremely high. You may need
| to pay up-front for medical assistance"
|
| I think some Americans don't realize that, outside of
| America, many people don't ever consider the risk of gun
| violence in their day-to-day lives, or owing thousands of
| dollars for visiting a hospital.
| rob74 wrote:
| Actually, I specifically addressed the violent crime
| thing...
|
| As for the medical costs - if you want to be on the safe
| side, you can (actually you should) get travel health
| insurance.
| vbezhenar wrote:
| I've heard horror stories about hospitals not accepting
| insurance. Wouldn't want to be in a situation of being
| ill and having to pay more than I can earn in a lifetime.
| cjk2 wrote:
| They will accept it. The cover has to be specifically for
| US hospitals otherwise the insurer won't pay out and they
| know that and won't accept it. You have to avoid insurers
| who only cover certain providers as well.
|
| You have to read your insurance contract and info sheet
| properly rather than go for the lowest price.
| Semaphor wrote:
| > As for the medical costs - if you want to be on the
| safe side, you can (actually you should) get travel
| health insurance.
|
| Though you might need to get a US specific one. Mine
| contains a clause that specifically excludes the USA from
| coverage, and that's not uncommon.
| hbossy wrote:
| Every medical travel insurance I ever bought had a clause
| that it doesn't work in the US.
| cjk2 wrote:
| To be fair I've been to the US a few times and I've never
| been shot and I did end up in hospital and it was smooth as
| butter. Because I didn't hang around where I was likely to
| get shot and actually checked my insurance cover and had
| the cert on me.
|
| Note I live in London and everyone tells me I'm going to
| get stabbed too and die from the pollution...
| lambdaone wrote:
| London's homicide rate is (roughly, depending on which
| source you use and year you take) about one-fifth of the
| average US homicide rate; you are safer in London than in
| almost anywhere in the US.
| cjk2 wrote:
| 13 per million per year in London. 60 per million per
| year in New York.
|
| That's an 0.006% chance of getting murdered killed in NY
| every year.
|
| And that doesn't account for (a) putting yourself in a
| good position to get killed like being a gang member and
| (b) the aggregate reduction in risk by only travelling
| there.
| acheron wrote:
| We don't actually consider that in the US either, you
| probably shouldn't get your views of the US from Reddit or
| the Guardian.
| squigz wrote:
| I know several Americans who consider both of those
| things.
| noirscape wrote:
| That second one needs to be pointed out in particular - the
| US healthcare system is so expensive that if you have
| healthcare insurance as a foreigner, they're typically
| excluded from the international plan. You have to
| specifically go out of your way (and pay more) to make your
| local health insurance cover the US.
|
| Quite a few people don't want to deal with that.
| lambdaone wrote:
| The homicide rate in Australia is particularly low. But in
| terms of overall homicide rate the United States is higher
| than the vast majority of other developed countries, and
| indeed most developing countries.
|
| Most of the world sees the United States as a dangerous
| country.
|
| For example, using the source you've just given, the US
| homicide rate is over 5 times the homicide rate of the United
| Kingdom, France and Germany, and over 10 times that of
| Norway.
|
| Granted, you're more likely to die in a car accident than to
| be murdered in the US, but that's no reassurance; this is
| partly because the vehicle accident mortality rate is so high
| in the US, at over four times the rate in the UK. And your
| comment about dying in a plane crash is completely wrong: the
| air travel mortality rate is very close to zero, with under
| 200 deaths for over 800 annual million air travellers; a rate
| of less than 0.025 per 100,000 per annum.
| isodev wrote:
| Indeed, the author is not alone. It may be subjective but there
| are worries one needs to reconcile when planning a trip to the
| US (both for work as well as private trips). It's often that we
| choose another destination or "can we find a way to make this
| remotely".
| _ZeD_ wrote:
| well... yes. I, for one, am slightly worried to go to the US.
| aden1ne wrote:
| Yes, this is a thing.
| cjk2 wrote:
| I think it's a hefty chunk of paranoia. The US is absolutely a
| non-issue unless you have previously pissed them off. This is
| the same for every country.
|
| What is not is walking 30km in the middle of nowhere in Central
| Asia because you didn't have enough cash to pay the driver's
| bribe. Stuff like that is a far more realistic concern than the
| security border paranoia stuff that goes on. Know where you are
| going, plan ahead and stay out of obvious trouble. That applies
| everywhere. The US is not special.
|
| (Incidentally when I got to the first town, the guy in the shop
| laughed at me and invited me in for tea and dinner on him and
| his wife and I got to learn all about their history under
| Russia - it's not all bad)
| hug wrote:
| The last time I was in the US, specifically in Seattle, there
| were two separate shootings within blocks of where I was at the
| time, and one at a bar an hour after I left it.
|
| As an Australian, seeing it on the news the next mornings made
| me very, very uncomfortable.
|
| I understand that these shootings are unlikely to ever involve
| me, and I'm not discomforted to the point that I won't go back
| to the US, but it is worth understanding that gun crime in the
| US is seen as uncomfortable and concerning to many. That my US
| friends who were at the same venues with me were completely
| blase about it left me a little nonplussed.
| eesmith wrote:
| From
| https://github.com/orgs/community/discussions/54450#discussi...
| :
|
| "I'm Australian so I wont be attending either (I am not
| comfortable to enter the US due to a preexisting medical
| issue)."
|
| That's the "Medical costs in the US are extremely high. You may
| need to pay up-front for medical assistance" part of the text.
|
| I do not know if travel health insurance generally covers
| complications from a pre-existing condition, and as other
| mentioned, getting travel insurance which covers the US is
| already a special case.
| vbezhenar wrote:
| Passkeys are pretty useless for me. At first I was somewhat
| hyped, but it seems that everyone just ignores them. Chrome does
| not support them. I set it up on mac, today I tried to login to
| icloud using passkey, but it just didn't work. Few websites
| implemented them, but overwhelming majority of websites don't.
|
| So, yeah, useless technology for now. Passwords and TOTPs are the
| way.
| dariosalvi78 wrote:
| Chrome supports passkeys
| vbezhenar wrote:
| It does not. Not for Linux, anyway.
| test20201 wrote:
| It is because desktop linux does not have passkey interface
| built into the OS. There needs to be TPM, systemd, etc need
| to talk altogether.
| wiktor-k wrote:
| Linux most definitely has a TPM interface, it's called
| /dev/tpmrm0 and plenty of libraries for accessing it (eg.
| https://github.com/parallaxsecond/rust-tss-esapi/ full
| disclosure: I'm co-maintaining it). Systemd is not needed
| for that.
| lll-o-lll wrote:
| So where are things falling down? I seem to be unable to
| get passkeys to work in linux; Chrome or Firefox. I'm
| suspecting the issue is something to do with bluetooth.
| serpix wrote:
| Just logged in to iCloud using chrome on a mac. Scanned a QR
| with iPhone and boom that was that.
| vbezhenar wrote:
| I tried to log in using chrome on fedora. Scanned QR code
| with iPhone, waited like 20 seconds looking at "Connecting"
| and gave up. Does not work.
| cjk2 wrote:
| I still use Keepass (well MacPass) and naively "cache" what I use
| regularly in Keychain because I completely distrust anyone else
| handling the keys to my castle. Whenever I get a Passkeys
| notification it's an irritation as I don't actually see what the
| supposed benefits of this are and I'm not really interested in
| changing how I work. Just feels like I'm being dragged into
| something complex I will never be able to escape.
| BillinghamJ wrote:
| Password managers can store the passkeys just like they store
| passwords. 1Password has had strong support for them for quite
| a while now
| cjk2 wrote:
| Yeah probably can. But why do I need Passkeys?
| jf wrote:
| If you're asking in earnest: For the majority of users,
| Passkeys offer a pragmatic alternative to passwords that is
| far superior in terms of security.
|
| For you, based on what I've read in your comments, I would
| say that Passkeys are the first workable alternative to
| passwords. They are built on WebAuthn which (roughly
| summarized) was the standard developed by Google and Yubico
| in direct response to the Operation Auora attack.
|
| While the Apple/Microsoft/Google implementations of
| Passkeys likely won't meet your personal standards, they're
| built on a proven and well designed open standard. Which
| means you can benefit from the technology without buying
| into a corporate ecosystem.
| 4ad wrote:
| If you use a software-based password manager, passkeys
| are indistinguishable from passwords both from a UX
| perspective and a security perspective.
|
| If you store passkeys in hardware, then yes, passkeys are
| more secure, but you lose portability.
| javawizard wrote:
| > If you use a software-based password manager, passkeys
| are indistinguishable from passwords both from a UX
| perspective and a security perspective.
|
| That's not correct. Passkeys use public-key cryptography
| and a challenge-response authentication mechanism, so an
| adversary in possession of a read-only copy of the
| database of the service you're trying to authenticate
| with won't be able to authenticate as you - which is very
| much a security improvement over passwords, even when
| both are stored in a password manager.
| AnonC wrote:
| > an adversary in possession of a read-only copy of the
| database of the service you're trying to authenticate
| with
|
| True, but GP is referring to the private key on the
| (user's) device or computer being stored in a password
| manager. The main protection that passkeys offer in such
| a case is that there's no case of passkey reuse across
| services and accounts, which is something that's possible
| with passwords even if one used a password manager
| (albeit poorly by not generating unique passwords for
| each account).
| stavros wrote:
| This is wrong, as a MITM or keylogger can't steal a
| passkey, while they can steal a password.
| AnonC wrote:
| Since the passkey is the private key in the private-
| public pair, if it's stored on a password manager it can
| definitely be stolen by malware (if you could have a key
| logger, you could have something else too). The only
| solution is to have the passkey (actually private key)
| reside in hardware or be protected by dedicated hardware.
| hanikesn wrote:
| Strong mitm and phishing protection.
| ezfe wrote:
| 1: Phishing protection
|
| 2: Protection against data breaches since Passkeys are not
| reused
|
| 3: Ability to login to devices you don't own without
| entering a password (QR code scanning)
| DecoPerson wrote:
| Try Keepassium on iOS. It removed my need to "cache" anything
| in the keychain.
| Filligree wrote:
| Do you know how to turn the dratted thing off, by any chance?
| saagarjha wrote:
| The biggest issue with passkeys is that I just can't trust the
| companies offering them. They are locked into the platform for
| reasons that are ostensibly security but often indistinguishable
| from platform lock-in. If you make a passkey on an Apple device
| as far as I can tell it will never leave that device, ever, and
| there is no way to change this. Of course this means you can
| never be phished for your credentials but if Apple decides to
| delete your key or you want to leave your iPhone behind, what are
| you supposed to do?
| sevanteri wrote:
| This is why services need to support multiple passkeys per user
| just like they _should_ support multiple 2FA methods...
| Nextgrid wrote:
| Big problem with this is that enrolling the secondary passkey
| requires the authenticator to be present. This is super
| inconvenient and risky as it always requires both
| authenticators to be present at the same machine/physical
| location, exposing both to local, physical threats (faulty
| USB ports on your machine frying anything you plug in?
| Congrats, you've now fried your main and any backup
| authenticators before you realized what was happening).
|
| Ideally, you should be able to get an authenticator's public
| key and be able to enroll one without presenting the
| authenticator itself, allowing you to keep it in a safe/etc.
|
| This would enable an easy workflow - enroll main
| authenticator as normal, then enroll your safely-stored
| backup by pasting its public key. If you lose your main, go
| to your safe, get your backup and "promote" it to primary and
| enroll a new backup one which goes in the safe.
| 4ad wrote:
| This is why you need to enrol the secondary passkey at the
| same time you enrol the first one, not later when you might
| not have the authenticator present.
|
| In reality websites should not allow setting up a single
| passkey.
| cuu508 wrote:
| Enrolling both at the same time still requires both
| authenticators to be present at the same machine/physical
| location.
| e12e wrote:
| Problem remains when you lose one, and need to block and
| enroll a new backup?
| PaulHoule wrote:
| It always struck me that 2FA is a corporate suicide pact.
| Some percentage of users are going to lose their keys per
| year so your user base is going to decay like a radioactive
| element.
| jorvi wrote:
| That's why most 2FA's are 1.5FA by default where you can
| recover via SMS, delayed e-mail, etc, and you can
| (sometimes) only disable this by clicking through three
| scary screens and saving your 10 backup codes.
| JoBrad wrote:
| The services that I use passkeys for (MS, AWS) do. I have
| separate passkeys for 2 browsers and on my phone.
| bonton89 wrote:
| The trouble is if it is on the service to do the support,
| they can revoke support at any time. They could use start
| tightening the screws on device attestation tomorrow for
| business reasons and drop support for your browser or
| phone.
| jdiff wrote:
| Do they typically not? My only contact with passkeys has been
| the 2FA service (Duo) at my place of work, and I've got a
| passkey on my phone and laptop, as well as OTP push
| notifications, OTP SMS, or recovery code from IT. It's
| particularly handy with the Chromeboxes hooked into the big
| presentation displays since I can scan a QR code with my
| phone to use the passkey stashed inside it.
| sevanteri wrote:
| Slightly poor wording from me maybe. There have been cases
| where for example only one hardware key could be set up but
| other methods were available at the same time.
|
| I remember AWS having some weird choices at some point too,
| not sure how they are currently.
|
| But yeah, typically I think most services have had multiple
| choises available at the same time.
| Double_a_92 wrote:
| Yes, this is crucial. So far all the services that I use do
| though.
| tjoff wrote:
| This is alone a big enough reason that there never has been any
| reason to be hyped about passkeys. The hype train on passkeys
| has been insane.
| gehsty wrote:
| I thought passkeys were shared across Apple keychain (like
| passwords?) so you make a passkey on iPhone your iPad can use
| it.
| vbezhenar wrote:
| Yes, that's correct, they're stored in Keychain and shared
| using iCloud.
| saagarjha wrote:
| Ah, yes, poor choice of words on my part. They are in
| iCloud Keychain (I think this is required?). But if you
| only have one device it's basically the same thing, or if
| you're trying to leave the ecosystem.
| whereismyacc wrote:
| Are they not private keys that shouldn't be synced across
| devices? I thought icloud facilitated automatic creation of
| passkeys for each device, not actually sharing the same
| passkey across devices?
| advael wrote:
| Honestly platform-locking has so frequently and consistently
| been the intent of security-washing rhetoric and major breaches
| have become so commonplace that I now view "security" in the
| press to be a euphemism for lock-in first and foremost, with
| other usages being anachronistic or niche
| lynx23 wrote:
| Dont forget the euphemism "For your security" ==
| "surveillance" -> EDR
| dimitar wrote:
| Use a different factor of authentication and setup a new
| passkey?
| red_trumpet wrote:
| Do you have to do this for every account? Like changing my
| password on every account?
| dimitar wrote:
| yeah, I agree this is not a good experience
| cassianoleal wrote:
| I agree. So far I think KeePassXC is the only one that allows
| you to export your Passkeys. I believe Bitwarden are working on
| it as well. That said, it's unclear whether this will provide
| any portability of passkeys between providers.
| Tempest1981 wrote:
| Once you export your passkeys, is there anything that can
| import them?
| cassianoleal wrote:
| I assume each provider will have the ability to import as
| well as export. The question is whether you can do that
| across providers. That's not too different from the status
| quo for passwords and other fields though.
| jasonjayr wrote:
| ... and they are getting warned about that feature existing:
| https://news.ycombinator.com/item?id=39698502
| mdaniel wrote:
| untrue, 1Password stores the private key just like any other
| key material, and one can export it or get the private key
| from the bamboo menu "passkey": {
| "type": "webauthn", "createdAt": 1696352105,
| "privateKey": "eyJrdHkiOiJ...", "userHandle":
| "cafebabeDeadBeef..." },
| madeofpalk wrote:
| I think it is true that you can's export passkeys stored in
| Apple Keychain. However, the statement is false in two ways:
|
| - Apple's iCloud Keychain syncs across devices
|
| - Apple has APIs that allow third party apps to create and
| offer passkeys, presented as a first-class option in Apple's
| authentication system. I use this to sync my passkeys between
| my Mac, Windows PC, and iPhone.
| ajsnigrutin wrote:
| > - Apple's iCloud Keychain syncs across devices
|
| ...as long as you always keep buying apple.
| kiwijamo wrote:
| How do you sync it to your Windows PC? Is it native Apple-
| Microsoft sync or does it require e.g. installing an Apple
| application?
| bitlevel wrote:
| I would also like to know how this is achieved.
| tssva wrote:
| Apple's iCloud for Windows includes an iCloud Password
| app which allows accessing and managing your keychain
| stored passwords on Windows. They also have a browser
| extension for Chrome and Edge which does autofilling in
| those browsers on Windows. I haven't used them in a long
| time so I don't know if they have added passkey support
| to them yet.
| sooheon wrote:
| I had to turn off apple passwords/credit card autofill
| because it clashes with 1password - how donI enable the 1st
| class integration?
| Tomte wrote:
| Enroll another passkey. Password manager can also do that
| (Bitwarden, for example), so I really don't see a reason for
| all the agitation.
| pricechild wrote:
| Bitwarden (& vaultwarden) also offer passkey which seem to work
| pretty well.
|
| I've not had a problem registering both this and my phone on
| any site.
| kiwijamo wrote:
| I've found the Bitwarden to be hit and miss. Some sites work
| fine with it, others don't work. I haven't debugged it enough
| to work out whether the problem is on the Bitwarden end or
| the website end or something else altogether. Given I'm wary
| of the benefits (or lack of) of passkeys I haven't really
| looked into it in depth as I have other 2FAs I can use
| instead.
| michaelt wrote:
| If you've _already_ got a password manager, what benefit do
| you get from passkeys?
|
| Avoiding the risks of short, weak passwords? The risks of
| reusing passwords across sites? The inconvenience of
| remembering loads of passwords? The frustration of having to
| type passwords manually? The risk of getting phished or
| typing one site's password into a different site? Remembering
| and typing usernames? The password manager takes care of all
| that for you already.
|
| And if your objective is to have a second factor _just in
| case_ your password manager gets compromised? A physical
| button just in case someone takes over your mouse and
| keyboard? Or a credential stored in a secure element that 's
| (somewhat) protected even if you use it on a compromised
| machine? Putting it in a password manager (or OS keyring)
| removes those advantages.
| mid-kid wrote:
| Automation.
|
| Password managers should be the default authentication
| method, and the current hack of having it type text into a
| password field is both unwieldy and completely avoidable.
| posix_monad wrote:
| Very easy to put the a password into the wrong place when
| doing it manually.
| javawizard wrote:
| The risk of your password getting stolen in between your
| browser and whatever hash algorithm the service you're
| authenticating with puts your password through before
| storing/verifying it.
|
| That's the benefit you get from passkeys that no password
| manager will otherwise be able to give you.
| masklinn wrote:
| If your TLS connection has been MITM'd, you have much
| bigger problems than your unique randomly generated
| password being sniffed out.
| hal0x2328 wrote:
| It's very easy to fall prey to an Evilginx or similar
| AITM phishing attack. Passkeys or TLS client certificates
| are the only guaranteed defense. Relying on the user
| noticing the different domain or the lack of autofill by
| the password manager, not so much.
| thinkharderdev wrote:
| It is not required that your connection has been MITM'd.
| The service you are authenticating can accidentally log
| the plaintext password, they can store it with an
| insufficiently secure hash function or not salt it. A
| malicious browser extension can scrape it directly from
| the input form. Etc, etc, etc.
|
| Passwords are reasonably secure since we've been using
| them for a long time but there is in fact a huge chain of
| trust required to keep them secure and links in that
| chain frequently break.
| knallfrosch wrote:
| If they control the information flow can't they simply
| steal the passkey too?
| javawizard wrote:
| Nope.
|
| Passkeys use public-key authentication wherein the server
| only stores the public half of a keypair and the client
| authenticates by correctly signing a challenge sent by
| the server, which the server then verifies using the
| public key.
|
| At no point is the private key ever sent over the network
| or otherwise exposed to any infrastructure or code
| controlled by the server.
| tzs wrote:
| No, because they never see anything that needs to be kept
| secret.
|
| Pass _words_ are based on symmetric cryptography. When
| you log in to a site using a password you give the site
| your password in plain text, hopefully over an encrypted
| communication channel such as HTTPS so that no one
| between you and the site can see the password.
|
| The site then takes that plain text password and decides
| if it matches the plain text password you gave them when
| you created the account or most recently changed your
| password. If the site is following good security
| practices they aren't actually storing a copy of the
| password in plain text. They will store a hash of it and
| compare a hash of the password you just send to see if
| the hashes match.
|
| Pass _keys_ are based on asymmetric cryptography, also
| known as public-key cryptography. When you set up an
| account at a site to use passkeys your device generates a
| public key and a matching private key. The site is given
| the public key and your device keeps the private key.
|
| When you want to log in later the site sends your device
| some data, your device does a computation on that data
| that involves the private key and sends the result to the
| site. The site can recognize that whatever did that
| computation had access to the private key that
| corresponds to the public key the site has on file.
| jorvi wrote:
| Passkeys can't be phished, or shoulder peeped, or entered
| on a malicious domain. And for the layman, it means they
| can't forget their password.
|
| Technically the place where you store your passkeys can be
| hacked into, but there is no technology that protects
| against that. You could give a tech layman 5FA and he'll
| give all 5 factors to the nice man on the phone call.
| masklinn wrote:
| > Passkeys can't be phished, or shoulder peeped, or
| entered on a malicious domain. And for the layman, it
| means they can't forget their password.
|
| Neither can passwords if you're using a password manager
| to handle them.
|
| So again, if you've already got a password manager, and
| would put your passkeys in a password manager, what is
| the benefit of passkeys?
| brabel wrote:
| You're wrong, with password managers you can definitely
| be phished. Unless it's literally impossible to extract
| the password to enter it manually, but I don't think
| password managers make that impossible (and if it's
| possible, users will do it).
|
| With passkeys it's literally impossible.
| makeitdouble wrote:
| Could you expand on how to trick a password manager to
| enter the password on a fake domain ?
|
| I'd see having the user add the domain themselves, or get
| the user to copy/past the password themselves on some
| other form. But the phishing is not happening on the
| password manager side, and these use cases still exist
| even after you chose passkeys (i.e. I'd still need to
| somewhat log into Google's auth from my Nest hub for
| instance to have it show the calendar)
| barnabee wrote:
| It happens to me very regularly that a password in my
| password manager is needed on a different domain. Maybe
| the logon process is at id.domain.com and password is
| pinned to domain.com, or maybe the password was created
| at signup.domain.com and so it doesn't pop up on
| domain.com, or you have to log in to a hotel's site with
| the password from their reward scheme (different domain),
| etc...
|
| In any case users are trained by the internet to need to
| search for the right password outside the pinned domains.
| Most of the time I guarantee people don't add the extra
| domains to the password records. So when a phishing site
| pops up they'll do the same: search for the site
| name/domain that they think they're logging into and go
| from there.
|
| Password managers solve password reuse, weak passwords,
| etc. but IMO do not solve phishing, especially not for
| the kind of user who's most susceptible t it (little
| technical understand, hates this stuff, just wants to
| follow instructions and not deal with it), but passkeys
| _might_.
| nightski wrote:
| At least on Bitwarden you can just edit the domain if
| that comes up a lot for you (or even add multiple domains
| to a password). I'd rather do that than copy/paste on a
| regular basis. Honestly I can't say I ever copy/paste.
| barnabee wrote:
| Yeah, I do this too, but many people I know wouldn't even
| think about the fact that they could do that, or why they
| would. They just know that whatever password manager they
| use doesn't find the password but if they search for it,
| it's there. So they do that and get on with their lives,
| inadvertently opening up an avenue for phishing.
| makeitdouble wrote:
| I'm totally with you.
|
| These issues won't be solved unless passkeys work
| absolutely everywhere the user has to authenticate. Logon
| required or weird and funky domains is currently due to
| service providers being a mess themselves (I'm looking at
| you, Microsoft). So should we expect them to miraculously
| get their act together and have each of these system
| flawlessly work with their passkey auth. from now on ?
|
| That's where I think we're stuck with that class of issue
| for as long as there are multiple auth systems, passkeys
| or not.
| mrmanner wrote:
| Also autofill is just broken by some sites and app login
| screens, so users are used to looking at and typing their
| passwords every now and then.
| Aeolun wrote:
| > With passkeys it's literally impossible.
|
| I dunno about you. But I _like_ being able to get my
| passwords out of the password manager. How is not being
| able to do so a feature?
| brabel wrote:
| Because that opens you up for being phished.
| mikestew wrote:
| The metaphor might be a bit esoteric, but that's similar
| to wishing that Hardware Security Modules (HSMs) allowed
| you "get your <private keys>" out of the HSM. As sibling
| comment says, that's how you get phished. The whole point
| of an HSM (and a passkey) is that the super-secret
| private part never leaves the HSM no matter how nicely
| you ask and no matter how compromised the machine is.
|
| A password manager, OTOH, is happy to hand out your
| private key ("password" in this case) to anyone that has
| access to it.
| Atotalnoob wrote:
| Yes, but I don't want vendor lockin.
|
| I want to move my passkeys where I want and use tools I
| want.
|
| Not allowing anyway of changing passkeys is terrible.
| Imagine someone switches from IOS to android. How do they
| use their passkeys?
|
| Even if they had a big "warning don't do this" sign it
| would be better than not allowing it in anyway.
| pseudo0 wrote:
| It cuts out the necessity for a password manager browser
| extension to handle stuff like autofill, password
| generation, etc. Those extensions have had fairly
| significant vulnerabilities in the past. So you're
| reducing the attack surface, as well as getting a
| cryptographic guarantee against phishing (the signature
| the client returns include the domain that sent the
| challenge).
|
| Edit: The other great part is that the server just stores
| your public key, so it's idiot proof on their end. It
| makes a breach effectively useless, since offline
| cracking is impossible.
| packetlost wrote:
| >> Passkeys can't be phished, ..., or entered on a
| malicious domain. > Neither can passwords if you're using
| a password manager to handle them.
|
| This is absolutely not true, it depends heavily on usage
| patterns of the password manager and its features. Not
| all are browser extensions that autofill, and even if
| they did, sites change their domains for auth
| occasionally that break this functionality (or more
| often, signup is on a different domain from auth) meaning
| you must manually copy-paste your password somewhat often
| if you don't meticulously, and manually, maintain your
| domain list for a credential. The average person is *not*
| going to do that, they're going to go "huh, it broke
| again" and copy paste their randomly generated password.
|
| Please, do not give security advice you are not equipped
| to handle.
| afavour wrote:
| The actual implementation of password managers is really
| messy. Browser extensions that try to guess which field may
| or may not contain your username, copy the 2FA code to the
| clipboard in the hopes that you'll easily be able to paste
| it on the next page... passkeys offering a standardized API
| to provide this information makes it worth considering
| alone IMO, even without considering the extra security
| compared to plaintext password.
| bradley13 wrote:
| KeepassXC says that it is adding (has added) passkey support. I
| haven't tested this yet, but if it works, that would avoid
| platform lock-in. Assuming, of course, that the platforms don't
| somehow intercept the passkey requests and refuse to allow
| KeepassXC to do its job.
|
| The big tech companies (Google, Apple, MS) have all become
| evil.
| bonton89 wrote:
| > Assuming, of course, that the platforms don't somehow
| intercept the passkey requests and refuse to allow KeepassXC
| to do its job.
|
| My understanding is the ability to do that is built directly
| into the spec with the attestation feature. The only thing
| that might slow it down is Apple choosing to not implement it
| and zero out their device string. Others can piggy back on
| that to protect themselves behind Apple's skirt, at least
| until Apple changes their stance anyway.
|
| Platforms of course could just not allow Apple passkeys and
| only allow Apple users to use other 2FA options as well. Rest
| assured that small players like KeepassXC will be the first
| ones to have their passkeys blocked or not supported.
|
| The whole thing is a trap IMO.
| frantathefranta wrote:
| I've tried it and it works on GitHub. Sites seem to be hit-
| or-miss for now. Tip if you want to use it with the browser
| add-on, it needs to be manually enabled and you also need to
| remove any YubiKeys from the system because it will
| prioritize them over KeePassXC
| stavros wrote:
| Store your passkeys in BitWarden.
| JTyQZSnP3cQGa8B wrote:
| I love Bitwarden but they still don't support that on mobile
| phones.
| JaneLovesDotNet wrote:
| I think it's very close to landing into the release
| version. I've seen people discuss it working in the
| testflight/beta release on iOS
| troupo wrote:
| > The biggest issue with passkeys is that I just can't trust
| the companies offering them. They are locked into the platform
| for reasons that are ostensibly security but often
| indistinguishable from platform lock-in.
|
| On MacOS you cannot enable passkeys (or using TouchID with
| them?) without enabling iCloud Keychain.
|
| I'm fine with iCloud Keychain. But to enable it, you have to
| enable "autofill form password" which enables it in Safari.
| Disabling it in Safari disables the global setting and disables
| iCloud Keychain.
|
| WTF.
|
| https://twitter.com/dmitriid/status/1782787035637375050
| triblemaster wrote:
| You can always use passkeys like Yubikey or others which are
| much more multi-platform.
| crote wrote:
| This isn't a viable option in practice, because Passkeys use
| "Resident Keys". This means the credential needs to be stored
| on the Yubikey - which has a limited number of key slots.
| Need to log in to more than 25 (I believe) websites? Tough
| luck!
| AlexandrB wrote:
| It didn't have to be this way, but the hype train won over
| practical considerations:
| https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-
| tu...
| navigate8310 wrote:
| You could use YubiKey to unlock Bitwarden that can
| practically store unlimited keys
| int_19h wrote:
| I'm curious as to why the number of slots is so small.
| Surely this is not some kind of fundamental limitation on
| what's possible (or cheap) with hardware?
| whywhywhywhy wrote:
| The platform lock in attempt is wild, my initial experiences
| with Passkeys were great on iOS and Safari, either getting
| pushed to touch-id or scanning a QR with my phone. But then in
| Chrome I couldn't get into GitHub because chrome would only
| push me to use their manager and wouldn't offer a QR code.
|
| Seeing this more and more with Chrome, like Credit Card numbers
| used to just save and autocomplete in browser but then they had
| some popup that was worded in a weird way that tricked me into
| saying it into Google Pay. Then I had to like type in the CCV
| to retrieve the card but then it also charged my bank account
| 1c for the privilege of autocompleting the card each time. Took
| me good 20 minutes to delete my card, get it saved back in the
| free local auto completely and shut down my Google Pay account
| I never knew I had.
| Groxx wrote:
| Yep, this is why I don't use passkeys.
|
| I tried. The power-grabbing garbage was immediately apparent
| and sent me straight for "heck no, I'll just use passwords
| until they figure this out, at least that can't control my
| password manager".
|
| In principle I should be very in favor of them, but the wild
| variety of lack of support for basics, and the built-in-the-
| spec ability for site X to control how I store and sync stuff
| is utterly bonkers. It's feeling like the OpenID promise ->
| OAuth platform lock-in cycle all over again, but compressed
| into v1.
| sroussey wrote:
| I use 1Password which supports Passkeys, and don't have an
| issue across mobile or desktop.
|
| I don't get what the issues people have really are. I never
| experience them (fortunately!).
| marssaxman wrote:
| > and shut down my Google Pay account I never knew I had
|
| Google loves that nonsense, don't they? It's as though they
| think so highly of themselves that they cannot imagine they
| might not be strictly doing us all a favor by signing us up
| for their services.
|
| Fifteen years later, I _still_ have friends occasionally
| sending messages to a GMail address I never asked for, never
| used, and didn 't even know about for most of a year while it
| was virally spreading through people's address books,
| silently diverting mail away from my actual address. The only
| time I used this account, after I discovered that it existed,
| was to delete it - but GMail apparently still suggests it
| when people type my name, because I get an "oops, sent this
| to the wrong address" forward every few months.
|
| No I will not be knowingly using any Google passkey service,
| but perhaps I will someday find that they have signed me up
| for it anyway.
| Atotalnoob wrote:
| Why don't you setup the Gmail account to forward? I know
| it's a hassle, but will resolve the issue
| macintux wrote:
| That seems like an invitation for long-term pain if
| Google changes their policies, requiring someone to log
| in every X months or have their gmail account locked, for
| example, or some AI enforcement tool locks the account
| for inscrutable reasons.
| marssaxman wrote:
| The account doesn't exist anymore.
| matheusmoreira wrote:
| The issue is not forwarding the email. The issue is
| people sending email to the Google address in the first
| place. As someone who just set up email on his own
| domain, I'm starting to wish I could search every
| database and contacts list for my old Google address and
| replace it with the new one which is actually mine.
| twobitshifter wrote:
| Same thing with google app on ios. My wife saved a password
| to a site on her phone and we were trying to find it to log
| in again. Since she had navigated to the site through the
| Google app, the password ended up in her google account
| instead of the iPhone keychain - unlike in every other app on
| the iPhone.
| lapcat wrote:
| > If you make a passkey on an Apple device as far as I can tell
| it will never leave that device, ever, and there is no way to
| change this.
|
| That's not true. Passkeys actually require iCloud Keychain,
| which is obnoxious, because you can't use the OS passkey
| support without using iCloud. And you can't even manually
| export passkeys from iCloud Keychain, which is totally opaque.
|
| So it is still platform lock-in, just not in the way you
| described.
| xcrunner529 wrote:
| So use a password manager still (1P). You can have multiple
| passkeys for different devices or keychains but no entering
| passwords or credentials. Still an improvement and far less
| vulnerable.
| lapcat wrote:
| 1Password is a platform, one that has gotten worse over the
| years. They've taken a bunch of venture capital, switched
| to rental pricing, and apparently now demand that
| everything be in the "cloud". No thanks. I prefer to be my
| own password manager.
| teeray wrote:
| This is why I'm not interested in passkeys unless I can use it
| with my password manager (which I probably can at this point).
| It would also be nice to see the spec for these specifically
| address lock-in and provide anti-lock-in measures.
| tomschlick wrote:
| Not sure what your password manager is, but 1Password
| supports them and its a pretty smooth experience.
| frantathefranta wrote:
| KeePassXC has support for passkeys now. However I've only
| managed to make it work with GitHub. Bitwarden does not work
| for now (although their passkey implementation for log-in is
| reportedly in beta).
| Double_a_92 wrote:
| The idea of a passkey is that it's bound to a device, and you
| can have more than one passkey. Think of a YubiKey, just that
| you can use your Phone or your PC instead. You basically have
| designated hardware that is always allowed to just login to
| your account...
| troyvit wrote:
| I've had a link to OnlyKey's user guide bookmarked for about a
| year[1]. They're an open hardware company that offers a key.
| Despite that I still can't be bothered to go through with it.
| The article we're talking about includes many of the reasons.
|
| I feel bad for the author. They put a lot of their heart into
| something that could have been awesome.
|
| [1] https://docs.onlykey.io/usersguide.html
| Double_a_92 wrote:
| As I understood it, that's exactly the purpose and not an
| issue. You are supposed to create a new passkey on each device
| you have. The fact that they can roam around within e.g. the
| Apple ecosystem is just some _added_ function that Apple
| offers.
| al_borland wrote:
| If I first signup for a service on my iPhone, then want to
| login on a Linux desktop, for example, how would I login if
| the passkey is not on my system, and I can't login on the
| desktop to say I'm me?
|
| Maybe they sorted all this out so it "just works", but there
| seems to be so many potential pitfalls, that I feel like I'd
| need to spend weeks researching stuff and testing edge cases
| before I could feel safe using it. No one is going to do
| that.
|
| With a password, I know it works now, and it will work in 40
| years. I don't have that same kind of confidence with a
| passkey. Even if it's great, if people don't adopt it in
| mass, it will fade away and be removed, so how deep do I want
| to go? This isn't something I want to be an early adopter on,
| at least not for anything I care about.
| int_19h wrote:
| You get a link (or more commonly a QR code) that you open
| from the device on which you already have the passkey to
| grant access to the new device. Then you add the passkey
| for the new device.
|
| FWIW I don't think that this makes passwords redundant in
| general, but with passkeys, password becomes a last-ditch
| safety valve to regain access to the account. Meaning that
| it can be generated, very long, and stored in a way that is
| optimized for safety and security over ease of access
| (like, say, an encrypted text file on multiple USB sticks
| stored in different physical locations).
| tzs wrote:
| > If I first signup for a service on my iPhone, then want
| to login on a Linux desktop, for example, how would I login
| if the passkey is not on my system, and I can't login on
| the desktop to say I'm me?
|
| What's supposed to happen is when you tell the site you
| want to use a passkey and one is not available to your
| Linux desktop's browser you are shown a QR code that you
| can scan on your phone. The login will then take place via
| the phone using your passkey that is on the phone for that
| site.
|
| If you want to test to see if your browser handles this
| right you can do so at <https://www.passkeys.io/>.
|
| Once you are logged in with your passkey from you phone you
| should be able to go to your account settings on the site
| and somewhere in there find an option to add another
| passkey. You can then add a passkey generated by your Linux
| browser or your Linux password manager if you use a
| password manager that supports passkeys.
|
| Some will object that this is not good enough because they
| might want to login to some desktop they have never logged
| in from before when they do not have their phone handy.
|
| That's probably not as big a problem as they expect though
| because unless you are using passwords you have memorized
| the same problem applies to passwords. I've got over 400
| accounts in my password manager, almost all with long
| random unique passwords. That means I'm not going to be
| logging in somewhere new to any of those sites unless I've
| got access to my password manager, which in practice means
| unless I've got my phone or tablet with me.
| al_borland wrote:
| I have over 300 in my password manager, and I know there
| is no way for me to remember all do that, but when I
| travel I do like to have enough with me so if something
| happens I can get up and running again.
|
| Once on vacation I shattered my phone. Only time that's
| ever happened and I happens to be away from home. I was
| able to get a new phone at the local Apple Store, but the
| only reason I was able to get setup and running again was
| I happened to bring my iPad, by sheer dumb luck. Other
| than using it for 2FA to get my new phone setup, I didn't
| use it at all.
|
| In my most recent trip I brought my recovery key with me,
| and know my password for that 1 account. As long as I can
| get into that, I can get everything else setup from
| there. But I need someplace to start to make myself whole
| again. It seems like PassKeys make that more risky.
| sheepscreek wrote:
| There is a way around this. Password managers. I use 1Passwords
| and it acts as the vault for all my Passkeys. Can access them
| on all devices. Super happy with it.
| Pfhortune wrote:
| Is there a way to export a passkey from 1P to use in a
| different manager? (Legitimately asking, I haven't tried
| passkeys yet due to portability concerns, and this would be
| good to know)
| pkzip wrote:
| If you want portability, then you can use HW security keys
| that support passkeys.
| sholladay wrote:
| You are able to share an Apple passkey to any nearby Apple
| device at any time using AirDrop. Passkeys can also be used
| cross-platform during sign in via an NFC/Bluetooth handshake
| initiated by QR code.
|
| Additionally, passkeys are just a synced-via-cloud
| implementation of FIDO2, an open standard that has other
| implementations you may feel more comfortable using.
|
| For someone who requires being able to sign in to, say, GitHub
| from multiple different operating systems or platforms, you
| have a few options.
|
| 1. Use a passkey on your primary device, say an iPhone. You can
| still sign in to GitHub on a Windows computer or Android phone
| but you must have your iPhone with you. During sign in, there
| is an option to show a QR code on the Windows/Android, which
| you will point your iPhone at, and the two devices will do a
| secure handshake to sign you in. This is probably the worst
| option from a UX standpoint if you sign in on lots of devices
| that are not your primary.
|
| 2. Use a physical security key to store a FIDO2 key instead of
| a passkey. These devices are inherently cross-platform.
| Remember, a passkey is just a type of FIDO2 key. No one is
| forcing you to store it in the cloud. You can buy something
| like the YubiKey 5C NFC to store your keys completely offline
| and under your own control. The tradeoff is you will need to
| have it with you and you will need to plug it in every time you
| create an account or sign in.
|
| 3. Add multiple passkeys to your GitHub account, one for each
| platform you want to be able to sign in on. Unlike passwords,
| where an account generally only has one password at a time,
| it's normal and even recommended to have at least one backup
| FIDO2/passkey registered with an account.
|
| And of course these aren't mutually exclusive, you can mix and
| match these techniques, perhaps depending on how important the
| account is or how/where you typically access it. Maybe you only
| use a single passkey on your primary device for your bedtime
| social media scrolling, but use a passkey with a backup FIDO2
| security key on GitHub.
| nevi-me wrote:
| This is quite concerning, because I've recently started a project
| that uses webauthn-rs. I want to minimise spam on the project
| while I don't want to collect PII like emails for login.
|
| I wonder if it means that the author will stop working on the
| library after their next release, and more importantly, if the UX
| is going to be horrible with people unable to log in and other
| issues they mention.
|
| On a tangent, I share their discomforts about travelling to the
| US. The last time I was there, I felt uncomfortable being out on
| the streets alone. Maybe the portrayal of police brutality
| towards POC is a factor (for me).
| wiktor-k wrote:
| > I wonder if it means that the author will stop working on the
| library after their next release,
|
| Just FYI it seems the library will still be maintained:
| https://infosec.exchange/@firstyear/112337225055591544
| keepamovin wrote:
| Question for the author regarding:
|
| _within a business where we have policy around what devices may
| be acceptable the ability to filter devices does matter._
|
| Is a solution to this on desktop to use GPO policy to add a
| mandatory "attesting" extension (that you build yourself which
| just verifies the device is what it says it is), and on mobile to
| use a webview inside an app with similar attesting info injected
| into the page context??
| politelemon wrote:
| > At this point I think that Passkeys will fail in the hands of
| the general consumer population.
|
| Actually, I think it might be worse. The predators like
| Apple/Google have already pounced on passkeys as a consumer
| capture mechanism, so they'll ensure it doesn't fail.
| throwawayqqq11 wrote:
| Just you wait for governments to require platforms to only
| accept gov-signed keys.
|
| I was sceptical about something-you-own auth vs. something-you-
| know auth from the beginning and recieved backlash from my tech
| peers for it. I hate to be able to go "told you so" on this
| one. Lets hope im wrong about the government involvement, but i
| dont think i will.
| DyslexicAtheist wrote:
| not to diminish your point, but since at decade or so I'm a
| more worried about corporate surveillance capitalism than I'm
| about government surveillance.
| pcthrowaway wrote:
| I mean, same, but only because I realized a new undesirable
| thing was becoming a tacit reality that we'd have to accept
| on top of _already undesirable thing_
| ajsnigrutin wrote:
| With a bit of a change, you can mostly avoid most of those
| corporations... you lose out on some tech goodies, but you
| can still live quite normally.
|
| You cannot avoid the government.
| thejohnconway wrote:
| You can't avoid these corporations if you want to remain
| active on the internet. They keep shadow profiles. They
| sell and share your data from one service to another (I
| stoped using Facebook for example, but Netflix shared its
| watch data with Facebook.)
|
| I don't think it's possible to avoid them. Confuse them
| maybe.
| spacebanana7 wrote:
| Why? Governments can do so much harm by incarcerating,
| fining or even killing you.
|
| Don't get me wrong - corporate surveillance can be very
| annoying, especially in insurance / credit scoring / price
| discrimination etc, but it seems a comparatively lesser
| danger.
| bonton89 wrote:
| Probably because governments can just buy the corporate
| surveillance results, bypassing any shoddy protections
| that even exist completely. So corporate surveillance is
| government surveillance.
| threatofrain wrote:
| They're a consumer capture mechanism insofar as password
| management tools are, and we want users to use those because
| they make security tolerable. The problem is that it turns out
| the OS vendor was in the best place to win the password
| management game.
| pseudalopex wrote:
| Password management tools allow export.
| m0dest wrote:
| The lock-in situation with passkeys seems far worse than with
| password managers, though. There is no "export" option for
| iCloud passkeys - despite being cloud-synced across your
| Apple devices.
|
| If you decide to switch from an iPhone to an Android phone,
| you're looking at an arduous process of enrolling a new
| passkey for every single site.
| _nalply wrote:
| I can't help feeling this... In an adverse world software and
| electronic data is too ephemeral to entrust with authentication
| and authorization. What if we had something solid like a Yubikey,
| but:
|
| - credit card sized
|
| - completely airgapped
|
| - standardized
|
| - controlled by a non-profit association
|
| - hard- and software open sourced
|
| - built-in camera to scan data
|
| - built-in display to show data
|
| - configuration mode: scan human-readable configuration
|
| - data is QR code or something like Base58 to copy by hand
|
| - backup by supporting applications: scan and print out data
|
| - browser integration by an extension using a webcam
| arch-choot wrote:
| If you ignore the last 6 points about cameras and displays,
| then this is kinda what "Smartcards" are, I think?
|
| https://en.wikipedia.org/wiki/OpenPGP_card
|
| In fact the Estonian Id-Card is one of these if I'm not
| mistaken
| _nalply wrote:
| The problem with smartcards is: I don't see what's on them.
| wiktor-k wrote:
| Just to clarify Estonian Id-Card most certainly implements
| the PIV applet while Yubikeys implement both PIV and the
| OpenPGP Card (the latter has a benefit of natively supporting
| ed25519: https://github.com/wiktor-k/age-plugin-openpgp-
| card).
| vaylian wrote:
| > But of course, thought leaders exist, and Apple hadn't defined
| what a Passkey was. One of those thought leaders took to the FIDO
| conference stage and announced "Passkeys are resident keys", at
| the same time as the unleashed a passkeys dev website (I won't
| link to it out of principal).
|
| I'm trying to follow the developments in the 2-factor-auth space
| and this was one thing that confused me a lot. I've read a lot of
| hype on Passkeys being the next big thing but it was really hard
| to find an actual explanation what they are and how they work.
| And once I found out that these are keys that are stored on the
| security key, I was rather disappointed, because I really like
| the idea of generating keys on the fly based on the domain name
| that I'm authenticating against. This way I can "store" an
| infinite number of keys. The upside of Passkeys is supposedly
| that you do not need to remember which username you have on a
| website, but I think that's a minor upside.
|
| Related question: What is the official name for the
| (FIDO2-based?/WebAuthn-based?) technology that calculates and
| reconstructs keys on the fly based on the domain name of the
| service that I'm authenticating against? It is really difficult
| to learn the right terminology in the area.
|
| Edit: I think I found the answer here:
| https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
|
| A key that is reconstructed on the fly is called a "non-resident
| credential".
| tucnak wrote:
| > I really like the idea of generating keys on the fly based on
| the domain name that I'm authenticating against.
|
| You could do it on a USB cryptoprocessor, and securely, too.
| https://tillitis.se/
| macrael wrote:
| Passkeys can't actually replace passwords, right? I will always
| need a username and password with a website, then can generate a
| passkey as a separate auth mechanism, which if I lose, I will
| recover by setting up again using my username and password? I
| don't get how we can get to a place where passkeys are all, how
| do you get a passkey on a new device when you only have passkey
| auth on some other device enabled?
| arianvanp wrote:
| They are stored in your platform's password manager. So they're
| available on all the devices you're logged into.
|
| If you're enrolling a new device (say you buy a new android
| phone) you can scan a QR code from your previous phone go log
| in.
| macrael wrote:
| I see, so you can use one device to auth and create a passkey
| on another
| Filligree wrote:
| "My platform"? So, like, the BIOS? What if I want to use both
| a PC and an iPhone?
| arianvanp wrote:
| Platform as in "ecosystem". iCloud Keychain, Google
| Password Manager, Bitwarden, 1Password, your Yubikey.
| Anything that can store passkeys.
|
| If you want to use both you simply enroll both your PC and
| your iPhone. There's nothing stopping you from doing this.
| You can register multiple passkeys from different providers
| to the same account.
|
| You can also log in to your PC with your iPhone by scanning
| a QR code. And then afterwards enroll your PC as a
| secondary passkey.
| nusl wrote:
| This is how I'm using them. Still have a username/password,
| with a passkey as an additional factor. I use 1Password for
| passkeys rather than Apple's solution, which enables me to use
| them wherever I have 1Password.
| bradley13 wrote:
| That's not the idea, no. The idea is that - instead of a
| password - you have a cryptographic key. Like an SSH key. This
| key is managed for you, so you never have to see it or type it.
| You _ought_ to be able to either have just a few keys, or else
| a different key for every service you use.
|
| Unfortunately, the big players are trying to force this (really
| excellent!) idea into platform dependency. They want to store
| the keys on physical devices, which (a) eliminated portability
| and (b) restricts the number of keys you can have. If your
| device fails, you will also be faced with account-recovery
| problems.
|
| Great idea, but the implementations are looking...not great.
| whereismyacc wrote:
| Wouldn't transferring the keys around just massively increase
| the attack surface? There's a security reason why we want
| them stored on-device and never moved, right?
| bradley13 wrote:
| The KeepassXC file is encrypted (granted, only with a
| password). Sure, that file is now on multiple devices, so
| somewhat more vulnerable.
|
| The problem with storing on-device comes when you use
| multiple devices. I have three devices (PC, laptop and
| phone) that I use regularly and interchangeably. What am I
| supposed to do, if the keys are tied to a single device?
| Worse, what do I do if that device dies, or is stolen?
| skybrian wrote:
| Both iOS and Android sync to other devices in the same
| ecosystem, so there is at least a limited form of device
| portability.
|
| If you have both, register two passkeys with each account and
| that's even better, since they back up each other if the
| vendor somehow deletes your account.
| brabel wrote:
| They can, and hopefully will.
|
| To get a new passkey on another device, the provider needs to
| allow you to prove you have possession of your other device
| first. They can do that by sending you a one-time code, for
| example, when you authenticate using your existing device,
| which you can then type in the new device, and that lets you
| associate your new device-generated key with your existing
| account.
|
| With iCloud, you don't need event that because Apple can, and
| does, sync your keychain across all your Apple devices. So as
| long as you use the same Apple ID on different devices, all
| passkeys are automatically sync'd.
|
| If you lose ALL your passkeys, you may be in trouble and for
| that reason, it's common that when you register your first
| passkey, you should also be given a long recovery code which
| you must keep privately in a very secure physical location (as
| that will allow anyone who can get it to reset your account).
| You could say that IS a password, and perhaps you're right, but
| there's a difference in my mind that's pretty big: you're never
| supposed to use that "password", nor keep it easily accessible
| or even anywhere in digital form.
|
| Finally, a lot of people in this thread are missing that
| passkeys prevent phishing, and are basically the only way we
| know to prevent phishing. And phishing is extremely high in the
| ranking of security issues we currently have to try to solve.
|
| If you know a better solution to phishing than passkeys, please
| let us know (Passwordd Managers are not that if they allow the
| clueless user to extract the password and manually enter it
| anywhere)!
| ezfe wrote:
| Long recovery code is definitely a password lol. Needs to
| just have email recovery and call it a day.
| dogman144 wrote:
| There's more to phishing threat models than strictly
| credential theft, as you seem to imply.
|
| If passkeys are around, phishing will certainly still exist,
| and shift to dropping malware on endpoints or w/e vs going
| after logins
| brabel wrote:
| I don't think you know what phishing means. By "dropping
| malware on endpoints" I think you mean having a website
| serving malware? That's not phishing. For an attack to be
| "phishing", the website needs to be pretending to be some
| other website that the user trusts. Passkeys completely
| prevent the user from logging in to another website than
| the one they've created an account with.
|
| Your attack only works on people who basically "trust any
| website" at all. For those, yeah there's no salvation.
| shepherdjerred wrote:
| It depends on the implementation. Some sites use it to replace
| both 2FA and passwords, some use it for just 2FA.
|
| > how do you get a passkey on a new device when you only have
| passkey auth on some other device enabled?
|
| You'd use a sync service like a password manager.
| vanburen wrote:
| Usernameless always seemed like an optimization too far to me.
|
| I think it's totally reasonable, and probably a good thing for
| users having to use their username at login. Especially as it
| reminds them what username they are using for that service.
|
| I could totally see a situation where a user uses a Usernameless
| passkey for years to access a service and for some reason loses
| access to the Usernameless passkey, and then has also forgotten
| the username for the service, so cannot even start an account
| recovery process.
| klabb3 wrote:
| > Usernameless always seemed like an optimization too far to
| me.
|
| I think it depends on the service. But aside from the
| occasional forum or social site, usernames are just an extra
| step. I don't want or need one for
| banking/administration/ordering a product. For better or worse,
| email is usually a better identifier, assuming you already need
| one for other reasons (like you say recovery is typically
| needed).
|
| > Especially as it reminds them what username they are using
| for that service.
|
| Like passwords, forced usernames are hard to remember, if you
| use different ones. If you use the _same_ , then it leaks
| privacy across services. (Technically usernames can be private
| but the expectation from decades of social sites is they are
| public)
|
| > [...] loses access to the Usernameless passkey, and then has
| also forgotten the username for the service
|
| Correct, no identifier at all can't be recovered. Hence, email.
| knallfrosch wrote:
| There's no account recovery process for passkeys. I thought
| they _are_ your identity?
| frereubu wrote:
| I've had Apple silently delete music from Music when I had iTunes
| Match, and I've stayed paying for Dropbox despite wanting to use
| iCloud, which would be no extra cost for me, because their
| mechanisms for dealing with conflicts are different - Dropbox
| saves a version with "Name's conflicted version 2024-04-26" in
| the filename, whereas AFAIK iCloud silently decides what to keep
| and drop so you can't manually decide how to merge a conflict.
|
| I too find it hard to imagine how someone can lose _all_ their
| passkeys three times, and I guess they may be doing something
| funky given their profession, but I think many of these events
| just happen too easily in the Apple ecosystem and my trust in
| them managing things like that is relatively low - hence my use
| of 1Password instead of iCloud keychain. The Music thing in
| particular really stung as I never got a good handle on what was
| missing - I 'd just occasionally come across a "this file is
| missing" error when I tried to play a song, and I'm left with
| this kind of cloud of unknowing when it comes to my Music
| library.
| myspy wrote:
| I think I'm a tech guy and know my fields. I still have no real
| clue how passkeys work, how it is better, what it really is.
|
| When your security feature is not as simple as - remember a name
| and a password and store it somewhere safe - it doesn't work.
|
| Something about keys that are on devices. But what happens when I
| use a phone and a pc? How to get access then? Do I need a User/PW
| for the first time? Or do I need one of those keys I have to plug
| into the device first?
| 4ad wrote:
| Passkeys are _exactly_ like SSH keys. You should use them
| exactly like you use SSH keys.
| tux3 wrote:
| "Exactly" is under a lot of strain here.
|
| SSH is nice because you don't have to think about it. Your
| private key sits in your .ssh folder, and then everything is
| transparent. You _can_ put an SSH key in a smartcard if you
| want, but you have to opt-in to this kind of pain. And even
| if you do, almost all SSH servers will support that login
| method without issue.
|
| Passkeys don't sit in your .passkey folder. Your browser
| doesn't look for passkeys in a standard folder at all. You
| don't just do passkey-keygen like you would ssh-keygen and
| forget about it.
|
| Websites might support various combinations of FIDO/U2F/TOTP
| security keys, your USB security key might support various
| combination of FIDO2/CTAP/WebAuthn, and the user will be left
| confused what any of this mess means, why there are so many
| competing standards, and why they're asked to scan a QR code
| when they plug in their dongle, and it _doesn 't just work_
| at all.
| bradley13 wrote:
| Passkeys _ought_ to be exactly like SSH keys.
| Unfortunately, they are not.
|
| The attempts to restrict when and how they are stored, and
| how you can access them - those are going to cause a _lot_
| of pain and confusion.
|
| I have all of my SSH keys stored in KeepassXC, which (imho)
| is a lot more secure than having them hang around in my
| .ssh directory. Open KeepassXC, and the keys are available.
| Close it, and they're gone. Synchronizing the KeepassXC-
| file across devices means that I have access to the keys on
| all of my devices.
|
| The big companies pushing passkeys are trying very hard to
| _prevent_ this kind of convenience.
| brabel wrote:
| They shouldn't be exactly like SSH keys. With SSH keys,
| you can go and copy/paste your private keys on a
| scammer's website because they asked you nicely. People
| will totally do it as they don't understand what they're
| doing. The main thing with passkeys, and key dongles in
| general, is that you simply can't do that as the keys are
| inaccessible and you can only prove possession of a key
| when asked by a domain you've explicitly registered with
| (the proof-of-possession is never sent to any other
| domain than that which you registered with). What OP says
| is that opens the possibility for key providers to lock-
| in users, as that seems like an unavoidable side-effect
| of the legitimate goal of preventing phishing (phishing
| is the biggest security issue today, to increase security
| means making phishing impossible, so I still support
| passkeys as the best solution for that).
| Spivak wrote:
| There's a big difference between "can't just hit the copy
| button and paste in the key" and "can't export the key as
| part of a backup." Physically preventing users from ever
| accessing their own keys is an absurd user-hostile
| proposition. Even more absurd when the they're software
| keys stored in a database the user can decrypt. The FIDO
| alliance is just ensuring that password managers will
| require 3rd party backup tools to be useful.
|
| Password managers have prevented phishing just fine by
| binding passwords to particular domains, ssh keys prevent
| phishing with IdentitiesOnly and passkeys are bound in
| the same way as regular password managers.
| brabel wrote:
| Any security solution that involves lay people having
| access to keys is NOT secure. What you call "absurd user-
| hostile" is actually basic security in the real world
| with non-technical people.
|
| Technical people can already be secure using appropriate
| protections, but even for them it's very difficult to do
| it properly.
|
| Lay people will, without understanding what they're
| doing, ask the password manager to give them their
| password to enter manually on any phishing website as
| they'll think that it's not working because it's
| "broken". So , absolutely no, password managers do NOT
| prevent phishing.
|
| If you think I am exaggerating, well, I work with this
| and I assure you it's even worse than that.
| vel0city wrote:
| > ssh keys prevent phishing with IdentitiesOnly
|
| There has been a pretty insane number of times I've asked
| someone for their SSH public key and I get a response of
| ---- BEGIN RSA PRIVATE KEY ----. From people employed in
| tech jobs. Now imagine someone who barely understands how
| to use a computer, they're an easy target to get their
| identity phished.
| Spunkie wrote:
| I would say the exact opposite, traditional ssh key
| management should eventually give way to resident keys.
| Aka, treating them just like passkeys.
|
| We've been storing ssh keys directly on our yubikeys
| since before passkeys were a thing.
|
| Not only is it clearly more secure it's also been a
| usability lift. Plugin your yubikey, start an ssh agent,
| and run ssh-add -K to get all your resident keys added to
| your current session.
| vaylian wrote:
| What about storing/backupping/managing passkeys versus SSH
| keys?
| 4ad wrote:
| It's the same, you should not store or backup SSH Keys.
| redeeman wrote:
| and then the real world comes knocking
| carstenhag wrote:
| So I should get locked out of all services when my device
| breaks?
| dwattttt wrote:
| You should produce a key per device, and produce a backup
| key that is safely stored & not used anywhere.
|
| You can recover if you lose all devices via your break-
| glass backup key, and you limit the blast radius of "my
| key got stolen" from rotating all your keys to just a
| single device (or maybe the more likely "I screwed up and
| pushed my key somewhere public")
| crote wrote:
| ... which is completely nonviable if you connect to more
| than a single service.
|
| I agree that you _should_ use a different key per device,
| but when you connect to over a dozen different services
| /machines it quickly starts to become a serious chore to
| add another key. Have fun spending an hour enrolling your
| new device - provided you can even _remember_ every
| single usage it should be enrolled with.
| 4ad wrote:
| SSH certificates solve this issue.
|
| AFAIK there is no equivalent for Passkeys.
| red_trumpet wrote:
| I have to store them on my disc, in order to use them
| tomorrow.
| fellerts wrote:
| Can you elaborate on this? Why not?
| cyborgx7 wrote:
| If they are _exactly_ like SSH keys, then why not just keep
| using SSH keys. Clearly, there is something else to them.
| whereismyacc wrote:
| SSH keys are clearly not a feasible authentication method
| for non-technical users. Passkeys are here to replace
| passwords, not ssh keys.
| cyborgx7 wrote:
| I understand this, but the person who responded said
| Passkeys are exactly the same as SSH and used the same,
| when asked what they are. If that was true, then we would
| just teach non-technical users to use SSH Keys.
| planede wrote:
| For me that means having multiple keys in `authorized_keys`
| for the same user and never transferring private keys between
| devices. From what I gathered from the discussion here, this
| is not a given.
| nottorp wrote:
| So how can i scp my passkey to another machine?
| landmass wrote:
| Why would you want to? Just create a new passkey on the
| other machine. If you're saving them in a password manager,
| just create a new entry, "Another Machine's Passkey."
| vouaobrasil wrote:
| Passkeys are horrible because the design encourages the need for
| a smartphone, which is itself a disaster.
| threatofrain wrote:
| Passkeys only encourage the need for a password management
| tool, which is funny because if everyone had password
| management tools to begin with then we wouldn't need passkeys.
| vouaobrasil wrote:
| True, the technical aspect of passkeys does that. But in
| practical Apple and others want to heavily push for the
| smartphone as that tool, because it locks people further into
| that system.
| arianvanp wrote:
| This is not true.
|
| Passkeys still protect you from additional things that
| password managers don't protect you against:
|
| 1. Your credential can't be phished as it's cryptographically
| bound to the domain. You could stil be tricked into entering
| your password and TOTP into a malicious website.
|
| 2. Your credential can't be leaked by sloppy servers as it's
| public key crypto. This makes your security not depend on
| believing the website your logging into does proper password
| hashing and doesn't accidentally log password in plaintext.
| nottorp wrote:
| > Passkeys only encourage the need for a password management
| tool
|
| The _dependency_ on a password management tool.
|
| Be it Yubikey or Apple secure enclave or whatever, it's a
| shit piece of hardware that will eventually break. Have fun
| replacing all your credentials at the same time when your
| phone dies.
| vel0city wrote:
| > Have fun replacing all your credentials at the same time
| when your phone dies.
|
| I won't have to, because I've got passkeys on my desktop,
| my laptop, on my security token, etc. Losing one device
| won't lock me out.
| nurumaik wrote:
| Why couldn't passkeys just be a user-friendly wrapper around
| assymetric key pairs tech people already using?
| Shank wrote:
| That's basically what they are?
| michaelt wrote:
| They kind of are, except...
|
| 1. SSH keys, as they're normally used, let you be tracked
| between hosts. That's fine for SSH, because nobody's trying to
| SSH into their Grindr account. But for web login stuff you want
| a different key pair for every site.
|
| 2. Adds a bunch of 'attestation' features that corporate types
| think they need.
|
| 3. _Tries_ to make it so an attacker who gets access to your
| machine can 't make a copy of the credential. The success of
| this is implementation-dependent.
|
| 4. With barely any setup, Google/Microsoft/Apple will keep a
| backup copy, in case you lose your phone. This is useful for
| non-technical people.
| FdbkHb wrote:
| > With barely any setup, Google/Microsoft/Apple will keep a
| backup copy, in case you lose your phone.
|
| Not Microsoft. Their implementation has no synchronisation
| feature and provides no way to back it up or transfer to
| another device either. You lose the computer you lose the
| passkey.
|
| Their implementation is very daft and goes counter to the
| point of passkeys since you will need a less secure way of
| authentication to remain enabled on the accounts you use a
| Windows Hello passkey for, for the sake of being able to
| recover those accounts.
|
| Remember, the best security schemes are only as secure as the
| least secure scheme that is available to access the account.
| If you're still on an account that can be recovered by
| sending a 2fa code to email or SMS/texting then you have
| achieved nothing.
| frizlab wrote:
| My biggest issue with passkey is not passkey itself, which, when
| it works, is great, but more the implementation of it done on
| most websites.
|
| Use a passkey on https://www.passkeys.io and it works great! On
| google too. But use it on PayPal, it does not anymore. Who's to
| blame?
| larsnystrom wrote:
| I've added a few passkeys to 1Password. It works pretty well on
| github.com, and sometimes on google.com. But apparently,
| passkeys.io bypasses 1Password and asks the OS for passkeys? So
| passkeys.io doesn't actually work for me, unless I want to
| store the passkey in the OS keychain. Which I don't, because I
| don't want to be locked into that.
|
| How can it be that the website decides which password manager I
| should use to store the passkeys? That's crazy and goes against
| all intuition.
| vbezhenar wrote:
| My assumption is that there's no proper browser API for
| third-party passkeys, so this extension probably monkey-
| patches website JavaScript which is not reliable.
| frizlab wrote:
| Interesting. What OS/browser do you use?
| droopyEyelids wrote:
| Paypal has a really obnoxious failed implementation of passkeys
| where if you have totp configured, their login flow takes you
| to TOTP after your passkey auth.
|
| If you want your passkey to "just work" you have to turn off
| TOTP. But thats a bad idea because passkeys are an alternate
| method of auth with paypal, not a replacement for passwords. So
| then you are left with the option of a password only sign in
| (no TOTP) or a passkey.
| graton wrote:
| As someone who happily uses Yubikeys, I really don't want to use
| a Passkey. I want to still use a username/password and the
| Yubikey. Not just username and Yubikey.
|
| Google tries to force use of passkey now that if you enroll a
| Yubikey it will now be a Passkey, instead of a second factor.
| With no option to disable it. I have to run the Yubikey Manager
| tool and then disable "FIDO2", so that I can force it only be
| used as a 2nd factor.
| Jnr wrote:
| Yubikey + PIN works as a very nice passkey
| eloeffler wrote:
| You can open your Firefox about:config and set
| security.webauthn.ctap2 to false.
|
| This will cause a fallback to FIDO/U2F where possible and your
| browser will appear to not support FIDO2. I've observed this
| with the default Keycloak flow for Security Tokens. May be a
| bug, too...
|
| I don't know if this works with Google but if you try it, let
| me know :)
|
| This needs no restart of Firefox, so you can use it to quickly
| disable it instead of fully disabling it on your Hardwaretoken.
| stavros wrote:
| > I want to still use a username/password and the Yubikey.
|
| Why?
| brabel wrote:
| Definitely not for security... so yeah, seems quite
| pointless.
| crote wrote:
| Because of the whole "multi-factor" thing, and not making
| account recovery impossible?
|
| Passkeys are _always_ going to be less secure than username +
| password + Webauthn, why would you intentionally make your
| account less secure and give yourself a massive failure mode
| in the process?
| vbezhenar wrote:
| Password and other factors are not going anywhere. You can
| set password, TOTP, email, phone and passkey at the same
| time. And use passkey because it's convenient. But use
| other combination of factors, if you need to access website
| without passkey. At least if website owner allows it. But I
| think that most websites will allow it.
| sedatk wrote:
| If you can recover your account solely with your username
| and password, then what security does your Yubikey provide?
| patmorgan23 wrote:
| Account recovery is a separate issue. There's nothing about
| a pass key that makes account recovery any harder or easier
| than if someone loses their MFA TOTP device or forgets
| their password.
| mmsc wrote:
| Using a direct link to Google's 2FA setup will allow a Yubikey
| to be setup as 2FA instead of a Passkey, too:
| https://joshua.hu/enrolling-hardware-keys-2fa-google-workspa...
| karlkloss wrote:
| Did you know that you can turn every $2 Raspberry Pi Pico clone
| board into a FIDO2 stick, and even make it Yubikey compatible?
| https://www.picokeys.com/
|
| Well, not as secure as a commercial key, because the Pico doesn't
| have encrypted storage, but still much more secure than
| login/password.
| hlandau wrote:
| I've never tried to use passkeys, but determined a while ago my
| hard, non-negotiable, a priori requirements which would have to
| be met for me to be willing to use them:
|
| 1. I can, if I choose, have a passkey in software (no hardware
| enclave, no captive key, no TPM) even if the security of that
| sucks: => Implication: I can backup and copy a
| passkey without restriction, e.g. putting the key
| material in an airgapped password safe, and without that
| being visible to a website. => Implication: Websites
| can't discriminate by whether I have a passkey in
| software or have any part in deciding whether I get to backup,
| copy or transfer a passkey.
|
| 2. I can disable any attestation functionality to do my part to
| prevent any online service from making it mandatory.
|
| I haven't looked into this yet, so: do, or can, passkeys, or the
| contemporary WebAuthn implementations in Firefox or Chrome on
| Linux, meet my requirements?
| ezfe wrote:
| 1Password includes Passkeys in archive/exports of the 1Password
| database. Safari developers have stated that it is a planned
| feature to support Passkey exporting (but not currently
| supported) including between apps.
|
| I'm not aware of any restrictions at this time on your second
| point. I also haven't seen any examples of attestation and
| Passkeys being used in practice.
| vluft wrote:
| > 1Password includes Passkeys in archive/exports of the
| 1Password database.
|
| They explicitly do not.
| TacticalCoder wrote:
| > I can backup and copy a passkey without restriction ...
|
| We were so very _nearly_ there with U2F... I did extensive
| testing and you can have a U2F (Fido2 /webauthn) device
| deriving it's private keys, never leaving the device's HSM,
| from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down
| (out of a dictionary of 2048 words) and with these words, you
| can _always_ reinitialize another Ledger Nano (a cryptocurrency
| hardware wallet but I didn 't care: I was after the U2F "nano
| app").
|
| It just worked. It was beautiful. My seed were written on paper
| sheets which I'd store in a safe at the bank / at my parents'
| home, etc.
|
| As a bonus the hardware device would display, on its little
| screen, if you were enrolling or login (a useful info) _and_ ,
| for known provides, it'd display the name. For example _" login
| to google?"_ / _" enroll to dropbox?"_.
|
| Pure beauty.
|
| Then sadly this trainwreck that passkeys are happened, greatly
| lowering not only the security of 2FA (someone is in control of
| all your keys and they can be "backed up": what a concept!) but
| also making you lose the ability to backup your own keys/seed.
|
| I do really hope at some point we see a future "passkeys nano
| app" for hardware devices on which the _user_ is in control of
| the master seed used to derive the keys. It worked for FIDO2
| /webauthn. I hope it'll work again at some point in the future
| for passkeys.
| vanburen wrote:
| Totally agree with this.
|
| I wish Yubikey allowed users to import their own
| FIDO2/webauthn seed and overwrite the factory generated one,
| and then also allow the resident passkey functionality to be
| disabled.
|
| It should be up to the user if they want to have multiple
| duplicate hardware authenticators and be able to backup their
| seed however they wish.
| agwa wrote:
| Firefox and Chrome display a permission dialog when a website
| requests attestation, and you can deny it. If you deny it, the
| website has no idea how your passkey is stored, allowing you to
| use a pure-software solution if you so desire. The website
| could discriminate against you for denying attestation, but
| note that Apple always denies attestation for passkeys, so
| websites intended for the general public are unlikely to
| discriminate against users who deny attestation.
|
| So yes, I believe your requirements are met in practice.
| donatj wrote:
| The problem with passkeys, beyond the painful UX that will scare
| any casual users away and the fact that they are being wielded as
| an extreme vendor lock-in mechanism is just that the design and
| implementation is so over complicated with second system
| syndrome.
|
| If you're going to push a replacement for passwords and want it
| to be universal, it should be EASY to implement. Even if the
| backing cryptography is complex, the actual handshake /
| implementation shouldn't be. TOTP as an example is insanely easy
| to implement. Password auth of course is as well, despite needing
| to know what you are doing to get it right. Both can easily be
| handled entirely without JS.
|
| I should quite frankly be able to just <input type="passkey-
| public-key"> in a standard POST form for registration and be able
| to call it a day. It doesn't justify how complex it is to set up.
|
| A fitting password replacement should just be as smooth and easy
| as ssh. I give a website a public key, I use my private key. I
| manage my private keys however I see fit. I don't need a third
| party involved holding my private keys hostage.
| Mindless2112 wrote:
| If you want passkeys without Javascript, leave a thumbs-up on
| [1].
|
| [1] https://github.com/w3c/webauthn/issues/1255
| joshstrange wrote:
| I've avoided passkeys so far because I just don't have a good
| mental model of them. All my passwords are randomly generate and
| stored in a password manager so I really haven't felt the need to
| switch or felt constrained by my existing set up.
|
| I fully understand username/email + password and remembering the
| pain of things like "app specific passwords" makes me worry that
| some tools (open source, cli, etc) might not integrate well with
| password less so it's best to stay where I am until things settle
| out better.
| geertj wrote:
| Nice phrasing, I lack that mental model as well. Anyone here
| willing to distill down the whole thing to a few sentences? Who
| stores what kind of secret, and is there some kind of
| challenge/response at auth time?
| triblemaster wrote:
| A physical device which is not your computer stores some
| secret information which can authenticate you. This can be
| passwords, passkeys, GPG keys, your retina etc.
|
| The physical device can be password protected. So you have
| two step authentication: 1. your physical device 2. your
| password to that device
|
| Phones are currently being promoted for various reasons, but
| I believe something like Yubikeys or other FIDO2 fobs will be
| a better device. You can have multiple of them, you can store
| one of them in your bank safe. Someone stealing it of you is
| proper theft which can be traced in a usual manner by police.
| Stealing is not enough because you still need the password.
| The difficulty of asking you for password remains equal to
| difficulty of hitting you with a wrench. You don't need to
| remember stuff anymore, because you can just use your
| physical keys. You will need to travel with those keys, but
| its just same as your house keys. It is probably an extra key
| in your key fob.
|
| To add to it, the U2F/FIDO2 standard will make it vendor
| independent, and so no lock-in.
| vbezhenar wrote:
| Safari on macOS uses passkeys without phone. So unless you
| consider security chip inside macbook a separate device,
| that's not true, that's just one of modes.
| triblemaster wrote:
| Security chip inside macbook is a separate device for
| authentication purposes if it needs to be unlocked and
| cannot be bypassed by the OS.
| fauigerzigerk wrote:
| What I find rather confusing is what happens on each
| device. There appear to be multiple places where passkeys
| can get stored (iCloud Keychain, Google account, Chrome
| profile, Bitwarden, ...?) and depending on where it's
| stored it may or may not get synced to various other
| devices, browsers and apps.
|
| So my problem is that I keep forgetting which device,
| browser or app I used when I created a particular passkey.
| I'm never asked where I want to store a particular passkey
| and where I want it to be available. This is all an
| implicit function of a combination of factors apparently.
|
| It's like misplacing my keys has been taken to a whole new
| level of abstraction :-)
| Huppie wrote:
| Back when I implemented webauthn for the first time I
| remember the interactive tutorial webauthn.me provided by
| Auth0 was very helpful in wrapping my head around the
| process.
| kriops wrote:
| Most important feature imo: The effective "password" being
| sent over the wire is essentially some hash(secret, uri).
| Think about the consequences for phishing!
| dboreham wrote:
| Not true.
| pseudo0 wrote:
| The signed assertion includes the clientDataJSON, which
| contains the origin of the relying party. Assuming the
| server properly validates that assertion, it should
| prevent the use of a phished assertion by a third party.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Authent...
| triblemaster wrote:
| The mental model is very simple. If you use things like
| Yubikey, it is exactly like a key you use to start your car. A
| single password protected key maybe. In essence, it is your
| password manager but something that everyone can use. And
| something that doesn't need to be on the cloud.
| alt227 wrote:
| Apologies I dont mean to be rude, but this does not help me
| conceptualise passkeys in the slightest.
| triblemaster wrote:
| https://news.ycombinator.com/item?id=40168230
| jve wrote:
| Well that doesn't help understand: How passkeys can be backed
| up? Where/how they are stored? What if I loose my phone,
| computer? How can I login to some app using pc/mobile?
|
| I haven't been into passkeys as you see, but some easy login
| like that leaves me with a lot of questions.
| triblemaster wrote:
| https://news.ycombinator.com/item?id=40168230
| pseudo0 wrote:
| The TL;DR version in my opinion is that passkeys are quite
| similar to a SSH key pair, like one you'd use on GitHub.
| Basically you generate a key pair, the server stores the
| public key, and the client stores the private key. When you
| want to authenticate, the server sends a challenge, you
| sign it with your private key, and send it back. The main
| debate is over how to manage those keys after generation.
|
| - Backups: It depends. It seems like the big players
| (Google, Apple) are pushing an implementation where your
| passkeys are backed up either in the Google Password
| Manager or iCloud keychain. That way if you lose your
| device, you can recover your passkeys the same way you
| recover your other phone data.
|
| - Storage: It depends. Google and Apple are pushing phone
| implementations where passkeys are protected by a hardware
| security module of some sort, either the iOS keychain or
| Android Keystore. The private keys can't actually be stored
| in the HSM though, because you need to be able to back them
| up. So the passkeys are stored encrypted on disk, and the
| decryption key is stored in the keychain/keystore. Other
| options include passkeys actually stored in hardware (eg.
| Yubikeys, but then you can't back them up) or 3rd party
| password managers.
|
| - Login: It's pretty seamless, just click "login with
| passkey". The browser handles finding the right passkey,
| and part of the signed challenge includes the domain the
| passkey is for, preventing MITM-style attacks. There's also
| a whole separate thing for authenticating a session on a
| different device via scanning a QR code or Bluetooth.
|
| Here's a good fairly high-level breakdown of how it all
| works, if you want some additional detail:
| https://webauthn.wtf/how-it-works/authentication
| thesuperbigfrog wrote:
| The big problem is that most passkey providers do not
| support actually giving users their passkeys.
|
| As the article stated: "I want you to remember this quote
| and it's implications. Users should be able to use any
| device they choose without penalty."
|
| As you've pointed out:
|
| >> Backups: It depends. It seems like the big players
| (Google, Apple) are pushing an implementation where your
| passkeys are backed up either in the Google Password
| Manager or iCloud keychain. That way if you lose your
| device, you can recover your passkeys the same way you
| recover your other phone data.
|
| and again:
|
| >> Storage: It depends. Google and Apple are pushing
| phone implementations where passkeys are protected by a
| hardware security module of some sort, either the iOS
| keychain or Android Keystore. The private keys can't
| actually be stored in the HSM though, because you need to
| be able to back them up.
|
| How can I get my passkeys and back them up on my own
| storage media? (e.g. USB drive, encrypted cloud storage,
| burn to a disc, etc.)
|
| How can I import passkeys generated elsewhere?
|
| If you cannot backup or import the passkeys, then you do
| not control them. They are not your passkeys--they belong
| to Google or Apple, etc.
|
| And as the article states, in most cases these passkey
| providers do a piss poor job of managing _their_ passkeys
| that they claim belong to you.
| pseudo0 wrote:
| Agreed, they unfortunately seem to have gone the vendor
| lock-in route. The big players don't have export
| utilities for passkeys, despite it being technically
| feasible and pretty straightforward to implement. That's
| a pretty major gap in the spec, there should be a
| standard export/import format, and vendors should be
| required to implement it in order to be compliant.
|
| It's probably possible to extract passkeys from a rooted
| Android device, but it would definitely be out of the
| grasp of 99% of users. I have not looked into it in
| detail, but I'd expect a Frida script hooking the
| keystore decryption function would get the raw data, then
| it would be a question of interpreting whatever
| proprietary format Google is using for their password
| manager.
| jerf wrote:
| This has always been my objection to them, as a user, as
| they have been presented. As an employee, I don't care.
| Businesses have sufficient relationships and mechanisms
| to self-serve any issues that come up, like lost keys.
| But as a user, I do not. It is a drop-dead requirement
| for me for any authentication material that I have some
| way of backing it up and modifying it in case of
| compromise.
|
| Besides, give the Silicon Valley venture capitalists and
| Harvard MBA bros a whiff of the possibility of full
| control over something as important as your primary
| authentication material and before you can whisper
| _Richard Stallman_ they 're out having a happy
| Bacchanalia toasting the name of Portunus [1], whom I
| will now resurrect out of our ancient past to name him
| the God of Platform Lockin, and us users aren't going to
| get a word in edgewise over the debauchery and slides
| projecting Total Addressable Markets.
|
| Fortunately it seems they all got a little too drunk with
| power this time, but honestly it's only a matter of time
| before they arrange another Portunus summoning lock-in
| party again. This target is irresistible and the
| annoyance people have with passwords is too good an angle
| to pass up.
|
| [1]: https://en.wikipedia.org/wiki/Portunus_(mythology)
| And yes, I am aware of the stream-crossing between
| Bacchus and another god here. But who knows what a
| Portunalia even is any more?
| SAI_Peregrinus wrote:
| > The private keys can't actually be stored in the HSM
| though, because you need to be able to back them up.
|
| Every actual HSM I've ever used allows some sort of
| encrypted export. But actual HSMs are expensive and
| PKCS#11 is a terrible API so they suck to use.
| makeitdouble wrote:
| I reread your analogy a few times, and while I think it's
| probably accurate, there is absolutely nothing simple in it.
| It reminds me of the "It's like Uber, but for mortgage
| insurances" kind of startup pitch. It perfectly encapsulates
| the concept, but the concept itself is just crazy niche.
|
| To note: the key to start a car is provided with the car with
| no specific operation, is locked to no other device, doesn't
| care about who's handling it, can be duplicated and passed
| around. It would be closer to the traditional password system
| in all of its aspects IMHO.
| triblemaster wrote:
| https://news.ycombinator.com/item?id=40168230
|
| See this and let me know if it makes more sense.
| makeitdouble wrote:
| I understand passkeys as authentication through a
| private/public key generated by the client when creating
| the credential, with the private key staying client side
| and the public key kept server side, with some more
| details around it to make the whole thing
| discoverable/automatable.
|
| To me the best explanation was just to go to the
| passkeys.io site, the subject is complicated enough that
| analogies tend to introduce a lot of cognitive noise
| IMHO.
| triblemaster wrote:
| Good idea. I didn't know of that site.
| cuu508 wrote:
| It is like a key to start your car, except you can register
| it with multiple cars. And it has 25 or so "slots" for car
| registrations. If you lose the key, you cannot order a copy
| from the car manufacturer. You also cannot make a copy
| yourself. But you can (usually) register multiple keys with
| the same car. You do this by plugging two keys into the same
| car, and the car learns both keys belong to the same owner.
| You just have to be careful and keep track of which car is
| registered with which key, and vice-versa. Sometimes the key
| will not work with a particular car. Also, after you plug in
| the key, the car will not start right away. It will first ask
| you to select which key to use. If you use Bitwarden, it may
| hijack the key insertion interaction and will offer to use
| its soft-key instead. So, some small differences ;-)
| mavhc wrote:
| That is how you add new keys to my car, have 2 existing
| keys present to add a third
| throwaway48476 wrote:
| What happens if you lose one and buy another?
| mavhc wrote:
| Dunno, go to an official dealer I guess
| xoa wrote:
| > _All my passwords are randomly generate and stored in a
| password manager so I really haven't felt the need to switch or
| felt constrained by my existing set up._
|
| The basic logic here is pretty clear imo. Passwords are still
| symmetric factors, and they're also completely unstandardized.
| So you still have to do a significant amount of manual
| management crap that should not exist, deal with UI that should
| not exist, and you still have to do some stuff if the other
| side (service provider) gets hacked. If we used bog standard
| pub/priv keys instead, then everything could become universally
| better. There'd be no need to worry about password policies,
| whether there is a character limit or not, how well and
| consistently individuals handle it, or anything like that ever
| again. Nor care if a site is breached, literally no action
| required because the site would only have the public key, they
| could publish it in clear text and it still wouldn't help
| attackers authenticate a single iota. Plus things like phishing
| and so on go away, because same thing, if the user has their
| agent browser to a malicious link or the like, and then it
| presents their pubkey, it still wouldn't do anything and the
| agent can't be fooled by similar looking to humans domains or
| anything. The agent would expect the service to present the
| proper signed request and anything else wouldn't work.
| Conceptually everything could be automated and standard without
| any sort of silo, all software could speak the same standard
| simple key format and everyone could back that up and sync it
| any way they wanted.
|
| Unfortunately as is so often the case these days there's a lot
| of perverse incentives and players who can't resist the urge to
| try to add extra functionality in on top rather then just going
| for the low hanging fruit in a solid way first. So we've seen a
| confusing muddle, of existing players with financial interests
| who make money by helping lower the pain of the garbage that is
| password based mutal auth, those who see new chances to try to
| silo, those who want to shove in attestation and differences in
| password backing for good and bad reasons, mixing in concepts
| of hardware backing that are unnecessary, etc. I'm still
| hopeful something will come out of it in the end but it's been
| a real bummer to see how it's played out.
| joshstrange wrote:
| Thank you for that description. I do understand at a high
| level that it's similar to SSH keys with the pub/private
| aspect.
|
| I think I really need to implement it myself at least once to
| really grasp it. Maybe that's stupid/slow of me but that's
| how I learn best.
| Twisell wrote:
| Yes but what I'm still confused about is that: 1) Is one/some
| of your public key reused on different services 2) Or is
| there a different public key for each service
|
| 1) In the first case what will prevent different services to
| track users by comparing public key... and if so I would be
| more at ease with a site specific randomly generated password
|
| 2) In the second case when one service is breached you'd
| still have to manage rotation of public key somehow, how
| trivially is that done with current implementation ?
| ezfe wrote:
| Not reused, each service has a different key
|
| To rotate, you go to the key management page of the service
| and delete/add a new key.
| gruez wrote:
| >2) In the second case when one service is breached you'd
| still have to manage rotation of public key somehow
|
| Why would you need to rotate your keys? If they're storing
| passwords/hashes it makes sense to rotate because they
| might be able to brute force the hashes on a GPU cluster,
| but you're not going to be able to brute force a randomly
| generated public key.
| Twisell wrote:
| If I have any fear that the associated private key have
| leaked. For instance if my off-site encrypted backup is
| stolen. I sure would want to rotate my private key
| because my secret would be only as safe as the encryption
| method at the time the backup was stolen. I'm still not
| entirely sold on the "quantum will break any current
| crypto" but better safe than sorry.
| UncleMeat wrote:
| The whole point of a public key is that it is not secret. A
| breach where a service leaks the public keys of its users
| does not harm your security posture at all.
| michaelt wrote:
| _> I've avoided passkeys so far because I just don't have a
| good mental model of them._
|
| OK, so the simplest way to understand is to first know about
| the previous generation.
|
| U2F keys are designed to be used alongside a username and
| password, as a more secure replacement for phone apps showing
| 6-digit codes.
|
| In U2F the key has a hardware 'secure element' where secrets
| can't be extracted, even if you plug it into a compromised
| machine. You get a separate public/private key pair for every
| account and website (so it can't be used to track you between
| websites) and that key pair can be used to authenticate with
| the website. A physical button has to be pressed to
| authenticate, keeping it secure even if an attacker has control
| over your keyboard and mouse. The browser integration takes
| care of letting the USB key know which website is asking to
| authenticate. U2F keys have to be used alongside a username and
| password.
|
| For a variety of reasons U2F keys never really took off. Partly
| cost, partly the 'what if I lose it' issue, partly lack of
| uptake by websites, partly difficulty using them on mobile,
| partly competition from 'log in with google' type systems.
|
| So the trade group behind U2F said "Hey, maybe we could just
| emulate the hardware secure element in the smartphone's OS? And
| while we're at it, we could save the username, and use
| fingerprint/faceid instead of a password, eliminate that
| tedious button press, and automatically back up the
| public/private keypairs to the cloud". They kept a USB option
| about for the sake of tradition, but it's on life support.
|
| So that's the mental model of a Passkey: It's _like_ an
| impossible-to-clone USB hardware secure element that does
| challenge-response authentication to websites. Except it 's
| emulated in OS software, and is no longer impossible to clone.
|
| Another way of thinking of it is: It's very similar to using
| the 'Log in with Google' / 'Log in with Apple ID' buttons you
| see on many websites, you're authenticating to a service by
| proving you have access to a cloud account. The implementation
| details in the background are very different, but the result is
| broadly the same.
| chrisweekly wrote:
| > "and use fingerprint/faceid instead of a password"
|
| This is the part that makes absolutely no sense to me. An
| essential aspect of passwords is that they can be changed. If
| someone manages to fake the digital representation of my
| fingerprints or face, what now? Security guru Bruce Schneier
| has written about this w/ much more eloquence and authority.
| throwaway48476 wrote:
| The unstated value of a USB key is the functional
| similarity to metal keys for ordinary people.
| c0wb0yc0d3r wrote:
| This is exactly how I describe them to many as well. I
| just wish there was a USB key with the durability of a
| metal key.
| vel0city wrote:
| Somewhat personal ancedote, but I've had pretty good
| experiences with Yubikeys. I've had one on my daily
| keychain for over a decade now. Its been run through
| clothes washing machines too many times to count, I've
| left it out in rainstorms, its been baked in the sun on
| hot summer days multiple times, its been dropped in
| pools, its been run over by a car, I've dropped it some
| pretty significant heights while hiking. It is still
| working just fine. That and a PNY 16GB metal keychain
| flash drive have taken a ton of abuse and are still
| working just fine. Other than a higher melting point or
| ability to take high energy RF I don't imagine there is
| much more abuse a traditional metal key would have
| compared to what I've done to my Yubikey.
| vel0city wrote:
| The fingerprint/faceid is just a local proof to unlock the
| actual asymmetric encryption key. It is not your actual
| identifier to the remote server. So if you need to redo
| your auth, you just rekey and stash the new key in your
| authenticator (or have your authenticator originate the key
| material and never expose it to main memory at all).
|
| Think an SSH key protected by a passphrase. Your passphrase
| isn't the thing that actually logs you into the server, its
| just what you use to unlock your actual key material you
| use in your SSH handshake. Your fingerprint/face identity
| is just your local unlock of the actual key material stored
| in some other secure enclave.
| selykg wrote:
| The biometric stuff is simply allowing access to the keys.
| It's not being used for anything else.
|
| Your face or fingerprint being out there isn't a concern
| because that's not, ultimately, the thing being used to
| generate the keys or anything.
|
| It's an ease of use function.
|
| On iOS for instance, as I understand it, these are being
| stored in iCloud Keychain. Which has a password. The
| derived key for iCloud Keychain is stored in such a way
| that the system has access if you allow biometrics to be
| used.
|
| Biometrics then simply allow access, in essence, not part
| of the encryption process. The password for iCloud Keychain
| is necessary to add those items on a new device. Your
| biometrics aren't stored by Apple anywhere other than in
| the device.
|
| Honestly I am blown away how few people on this site
| understand how this stuff works. It's fascinating and I'm
| surprised more people aren't interested in understanding
| it. But so many people assume the biometrics are being used
| in the encryption process and that if your face is somehow
| stolen your whole life is doomed. These features have been
| on Apple devices for what.. a decade almost at this point?
| More? The process for Face ID is the same as Touch ID.
| Developers make zero distinction between the two in code,
| as that whole process is passed off to the system and
| effectively results in a bool value (or access to the
| secure item requested). At no point does a developer ever
| get your biometrics data.
|
| I don't know how Android or Windows do it but it is similar
| enough I suspect.
|
| The FUD around passkeys feels like some sort of propaganda
| campaign to discredit it.
| pixl97 wrote:
| "A pass key is an ssh key with more steps for the user to
| fuck up and get locked out of their account"
|
| I mean there is plenty of FUD, but at the end of the day
| it's not terribly exciting technology.
| m3kw9 wrote:
| This is the part where you have people dismissing a
| security from a simple assumption and reverting back to
| another assumption of their current state. Is still
| dangerous
| m3kw9 wrote:
| Your faith in humanity seem low, because this would never
| be pushed worldwide by security experts who eats and sleeps
| it, if it was so easily broken where you just figures it
| out during a comment
| taeric wrote:
| Your fingerprint/faceid/whatever is used to access the
| passkey. It is not the passkey. To that end, yes, if you
| are worried about clandestine access to your phone (if that
| is your passkey), then you probably don't want to allow
| access using fingerprint/faceid. And if someone can copy
| your passkey off of your phone, you are again compromised.
| NoMoreNicksLeft wrote:
| This sounds, to me, like a really bad and convoluted way of
| storing pub/priv in a password manager, and hoping the
| software implementation gets it right when it's trying to
| manage these things for me because I'm too dumb to manage
| passwords and too hobbled by bad IT policies that want to
| change my passwords every 4 weeks.
| whartung wrote:
| The big question I have is are the keys device/browser
| specific?
|
| Seems to me I need to be able to log in with a password from
| any place (my phone, my machine, my office, my wifes phone,
| her laptop, my friends laptop, etc.).
|
| I mean, who knows when I'll want or need to get into
| Something.
|
| Also, my wife and I share accounts (such as Amazon). So, it
| needs to work seamlessly across all of her devices.
|
| Then there's always the "F-with it factor" that I loathe. At
| least I understand passwords. Can (mostly) always recover a
| password (I recall trying to recover my Apple ID password --
| they bluntly said "ok, but you have to come back in 2 weeks",
| so I was locked out for 2 weeks).
|
| And, of course the level of patience my wife has with
| Technology is less than zero.
|
| I rely on my Safari auto fill, when I use another browser, I
| just copy the pw from Safari.
|
| And I don't use any of the cloud services. I have an iPhone,
| but don't use iCloud.
| acheron wrote:
| Yeah I'm not sure what's going on either. Is this just a
| rebranding of mutual-auth SSL client certs?
| dboreham wrote:
| Kind of. With the sharp edges filed off. There's no CA
| though. The web site provisions and authorizes the client's
| key at onboarding.
| acheron wrote:
| ohh, I see. that's clearer than any other explanation I've
| seen, thanks.
| UncleMeat wrote:
| It is a different technology with some different edge cases
| so I wouldn't call it a rebranding but in the broad scope
| yes. The problem with this stuff was always the integration,
| not the tech.
| stetrain wrote:
| You can store passkeys in a password manager as well:
|
| https://1password.com/product/passkeys
|
| The super simple explanation is: SSH keys for websites.
|
| You have a unique private key for each website account stored
| on your device, in a local password manager, or in a cloud
| synced password manager (iCloud account, Google account,
| 1Password, etc).
|
| The website only gets the public key, so unlike password auth
| your secret is never given to the website.
|
| When accessing that website, the website can send a challenge
| which your browser answers using your private key associated
| with that specific domain.
|
| (I'm not a passkey expert and there are a lot more technical
| details to this, but this is my 10,000ft mental model of what's
| going on)
| MadVikingGod wrote:
| I currently use the 1Password passkeys, and when they work,
| it's pretty good. I get all the fun of showing up on a
| website, and with three clicks, I'm in. But I've used them on
| just a few websites (email and GitHub), and they work
| correctly maybe 10% of the time.
|
| First, I had to figure out how to get the website to request
| the passkey. Then I had to figure out that I didn't want to
| use the browser's passkey but 1Password's, which is different
| on different browsers and platforms. And good luck if I'm on
| mobile, I don't think it's ever worked.
|
| At this point I'm taking a break from signing up new
| passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
|
| PS: Why is it that no financial institution lets you use
| anything more than a SMS U2F?
| rcarmo wrote:
| It's still not a great multi-platform/multi-device story. I
| use multiple machines regularly (and I've migrated away from
| 1Password to the KeePass ecosystem, by the way) so syncing
| passkeys from my Mac(s) to my iPad, to my Fedora machines and
| my Windows working environment is simply not happening any
| way I look at it.
|
| Passkeys are great for consumers who use one or two devices
| (or browsers - I also switch browsers frequently). For anyone
| with more than one platform or one device in their lives they
| suddenly become added complexity, because even though you
| _can_ have more than one passkey per account per service, in
| practice there are all sorts of weird edge cases.
|
| They're just not mature yet, period.
| vel0city wrote:
| You shouldn't ~~necessarily~~ need to "sync" your passkeys
| across all your devices; each device should have its own
| passkey. Then if you lose a device (or that one device gets
| compromised), you revoke the one key and everything else is
| fine.
|
| Similar to SSH keys. No reason to use the same key on all
| your machines, use a different key from different places.
|
| The passkeys on my laptop are different from the passkeys
| on my desktop which are different from the passkeys on my
| phone which are different from the passkeys on my main
| yubikey which are different from the passkeys on my backup
| yubikey.
|
| Edited due to acknowledging people may choose a variety of
| alternative workflows.
| abadpoli wrote:
| Great in theory, but in practice there are still a
| frustrating amount of websites and services that put a
| low upper limit (usually just one or two) of the number
| of keys you can enroll.
|
| This effectively makes it impossible to do what you're
| saying. It sucks.
| vel0city wrote:
| I hear this a lot but it hasn't generally been my
| experience. The only site I've personally come across
| that supports webauthn/passkeys but doesn't support
| multiple is the AWS management page. Which I essentially
| bypass by just configuring SSO and using an IdP which
| does support it.
|
| Every other site I've come across that supports these
| things supports multiple. What common sites support only
| one or two?
| cuu508 wrote:
| AWS now supports multiple MFA devices per account.
| vel0city wrote:
| That's awesome to hear, thanks for sharing!
| NoMoreNicksLeft wrote:
| > You shouldn't necessarily "sync" your passkeys across
| all your devices; each device should have its own
| passkey. Then if you lose a device (or that one device
| gets compromised), you revoke the one key and everything
| else is fine.
|
| If he's storing his passkey in his password manager, it
| wouldn't matter that he lost the device. They can't get
| to it, it's AES-somebigassnumber-ed up the wazoo. If the
| passkey is cached outside of the password manager, then
| passkeys are a horrible idea, where you have to "go home
| and call the 800 numbers to cancel the credit cards", and
| worse still, people with few devices might end up in
| circumstances where they have no valid devices left to
| bootstrap access.
|
| I am resigned to the fact that I will die with humanity
| never having solved the problem of passwords adequately,
| but being that I will live another two decades minimum, I
| will get to see two more of the stupidest possible non-
| solutions.
| cgeier wrote:
| How do I then get the passkey for my second device
| accepted by the service? Do I mail the public part to
| myself and insert it from my first device?
| rcarmo wrote:
| Actually, I much prefer to use the same SSH key for
| deployments from any of my machines, so that example
| doesn't really work for me (I do have multiple keys).
| Macha wrote:
| I use far more sites than I ssh into servers, which makes
| this much more of a pain. Like, every time I sign up to a
| site I need to grab all 5+ devices I might ever use and
| add them to every site, or I can't e.g. log into my D&D
| game while travelling because I forgot to generate a key
| on the work laptop? If all my devices are destroyed in a
| house fire again, I'm locked out of everything? These
| have been my big concerns.
| vel0city wrote:
| > every time I sign up to a site I need to grab all 5+
| devices I might ever use and add them to every site, or I
| can't e.g. log into my D&D game while travelling because
| I forgot to generate a key on the work laptop?
|
| You don't _need_ to log in to _every_ app on _every_
| device the instant you register a new account. Just make
| a passkey on a couple of devices that you 're likely to
| have around and you'll probably have what you need when
| you need it. When I register on a new site that uses
| passkeys, I might create a key on whatever computer I'm
| on and a portable authenticator like my phone or my
| security token.
|
| So, say I'm at home on my deskop, and TotallyCoolService
| has the option for a passkey. I'll make one on my
| desktop, and then go ahead and make one on my security
| token. Later I'm out and I want to check in on
| TotallyCoolService on my phone. No worries, I just tap my
| security token to my phone and I'm logged in. Later I'm
| in the garage working on my motorcycle and want to
| reference something on TotallyCoolService on my laptop
| and my USB token is in my backpack inside. No problem, I
| can sign in with my phone. Now I've got security tokens
| on most of my common devices and its not like I had to
| spend time gathering all of them at account creation.
|
| I don't instantly run home to my desktop and log in the
| moment I sign up for a new site while out and about. But
| I do go and sign in _eventually_ , even if only to ensure
| there's a backup key there.
| Macha wrote:
| This really doesn't contradict the problem of needing to
| sort out M sites x N devices, where M can be very large.
|
| Whether you do it eventually or do it straight away.
| Unless you can predict which devices you will have and
| which sites you will need access to at any given point,
| then it degrades to needing everything authenticated just
| in case.
| landmass wrote:
| I've installed KeePassXC on my Mac and Linux machines and
| it stores Passkeys. Low-tech syncing is by Signal Notes to
| Self. If there were an audited app for iPhones I'd still be
| using that method; there isn't, so I've moved to Bitwarden.
| Passkeys seems to work fine on Bitwarden.
| nindalf wrote:
| How do the private keys get synced across my devices? What's
| the default in the Apple, Google and Microsoft ecosystems?
| Devices get lost after all.
| stetrain wrote:
| By default they go in your cloud synced password manager
| for those platforms. iCloud Keychain etc.
|
| Or you can use a third party password manager like
| 1Password or KeePassXC.
| mixmastamyk wrote:
| How do you back up the private key? With ssh I know to back
| up .ssh with the rest of my home folder. With a passkey I'd
| have no idea where it was, and get the feeling the "modern"
| software won't tell me on purpose, so that it can manage/sync
| it for me. Which leads to a lack of a mental model.
| stetrain wrote:
| The same way you would back up passwords stored in iCloud
| Keychain, 1Password, KeePassXC, etc.
| Timothee wrote:
| I'm in the same place.
|
| I feel like most of the replies to your comment talk about the
| technical aspect of it.
|
| What's stopping me is that I don't have a mental model of the
| management of the passkeys for the whole lifecycle of my
| account. Can I use it cross platform? Can I allow someone else
| to use the same account? What happens if I lose or don't have
| access to my phone or laptop? What if I die, can my spouse log
| in my accounts?
|
| With username/password, it's very clear what I need. I could
| write it on paper and give it to someone and it'd work. I feel
| more at risk of losing access to my accounts if I were to
| switch to passkeys, because I don't fully grasp their long term
| lifecycle.
| yunwal wrote:
| > I feel more at risk of losing access to my accounts if I
| were to switch to passkeys, because I don't fully grasp their
| long term lifecycle.
|
| It's my understanding that you can't switch password managers
| without generating a new passkey for each individual service
| you use (I'm not an expert here, so someone feel free to
| correct me). That's already enough for me to not switch.
| OkGoDoIt wrote:
| That's my problem with TOTP second factor authentication.
| I've used Authy for years because it works on Windows and
| mobile, but now they've decided they aren't going to work
| on Windows anymore (but they still force update a perfectly
| working Windows app and there's no way to opt out). I have
| no way to export my 30+ TOTP accounts to a new system. I
| often don't want to have my phone around when I'm trying to
| focus and get work done, but now I have no choice. It's
| infuriating. Is there any cross-platform TOTP system that
| has the ability to export your keys? Is that even a thing
| that's technically feasible?
| mrtesthah wrote:
| This is why, for me, the problem is not the passkey model
| per se as much as it is the inability to
| export/backup/convert my iCloud Keychain database to
| another account or platform. Apple could arbitrarily delete
| my data or lock me out of my own account. Or it could just
| randomly _break_ with no solution besides deleting the
| database and starting fresh. And according to the author,
| this has already been occurring!
|
| > _Externally there are other issues. Apple Keychain has
| personally wiped out all my Passkeys on three separate
| occasions. There are external reports we have recieved of
| other users who 's Keychain Passkeys have been wiped just
| like mine._
|
| So those are the real risks.
| pimlottc wrote:
| Nice to hear I'm not the only one. Part of the problem is that
| it's always presented post-login when I'm already in the middle
| of doing something. And my password manager works well, so I
| don't see a clear benefit and I'm not really motivated to
| investigate vague claims.
| flkiwi wrote:
| I agree, plus the added abrasion from passkeys being
| implemented inconsistently and seemingly in a way that
| promotes vendor lock-in. Do I need a different passkey for my
| iPhone and an android tablet? Do I need a different passkey
| between iOS devices? Why does this service allow me to use a
| passkey in Bitwarden, but that service doesn't? These are all
| questions I've never had to ask about a complex password in a
| password manager.
| m3kw9 wrote:
| Having a mental model of encryption has never improved security
| dfabulich wrote:
| People keep trying to answer this question, so I'll try, too,
| but I'm going to do a better job than anyone else. ;-)
|
| _Passkeys are randomly generated passwords that are required
| to be managed by a password manager._ All the major password
| managers support them, including Apple, Google, Microsoft,
| Mozilla, and 1Password.
|
| _By requiring the passkey to be managed by a password manager,
| you get some anti-phishing protection._ A passkey includes
| metadata, including the website domain that created it, and the
| password managers simply won 't provide the passkey to the
| wrong domain. They provide no way for you to copy and paste the
| passkey into a website, as you can with a password; there's no
| social-engineering technique someone can use to get you to copy
| and paste your passkey to an enemy.
|
| _A passkey manager is morally required to do an extra factor
| of authentication_ (e.g. fingerprint, Face ID, hardware keys,
| etc.) when you login to a website, but the website has no way
| of knowing /proving whether that happened; they just get the
| password.
|
| _You reset your passkey the same way you reset your password,_
| because passkeys are just passwords that have to be managed
| with a password manager. Some sites make it easy to reset your
| password, some make it hard. You know the drill; there 's
| nothing new or different there.
|
| _If you 're happy with your password manager, there's no real
| need to switch,_ but even very "sophisticated" password users
| have been known to fall prey to social-engineered phishing
| attacks.
|
| Are you _sure_ you 're never going to copy-and-paste your
| password into the wrong hands? I don't trust myself that much.
|
| _Passkeys can make it harder to switch password managers_
| because the password managers are designed not to let you copy-
| and-paste a passkey, including from Google 's Password Manager
| to Apple's Password Manager. I think all the password managers
| kinda like that, and there's something good and bad about it.
| CogitoCogito wrote:
| Do you know if there an open source self-hosted
| implementation available?
| caconym_ wrote:
| Bitwarden, which you can self-host (I do this) seems to
| have at least partial support now, and I know they're
| working on improving it. However, I'm not sure if their
| client and server are both fully FOSS.
| khimaros wrote:
| vaultwarden at the very least is libre
| zie wrote:
| They are, but you have(?) to have a license to run the
| OSS server code.
|
| https://github.com/bitwarden/server
|
| Like the other commenter mentioned, vault warden is the
| independent server version that doesn't require any of
| that.
| t0asterb0t wrote:
| KeePassXC supports passkeys in its latest version:
| https://keepassxc.org/blog/2024-03-10-2.7.7-released/
| ar-jan wrote:
| https://github.com/protonpass
|
| Also see https://proton.me/blog/big-tech-passkey
| pixelHD wrote:
| I use selfhosted vaultwarden [0] instance (its a rust
| implementation of the bitwarden server), and the bitwarden
| apps (i point the apps to use my server instead of
| bitwarden).
|
| Vaultwarden + bitwarden client apps (for desktop/browsers)
| have passkey support, and i've been using them for a month
| or two without any issues.
|
| That being said, bitwarden client apps for android and ios
| are going through a rewrite (from xamarin to native iirc),
| and are yet to support passkeys. However, the bitwarden
| folk said passkeys are the next feature coming to these
| apps.
|
| [0]: https://github.com/dani-garcia/vaultwarden
| iknowstuff wrote:
| Strongbox for iOS/macOS. Uses the keepass file format
| yonatan8070 wrote:
| So passkeys are essentially like SSH keys but for web/app
| logins
| red_admiral wrote:
| ... with some of the functionality of SSH keys removed,
| like being able to use one key for many accounts, or many
| keys (on many machines) all for the same account.
|
| At least that's how I understand it.
| Xelynega wrote:
| Unless I'm missing something these are nothing like SSH
| keys. They would be closer to regular password auth with
| SSH where you store the password in a file that's only
| readable by SSH.
|
| SSH keys are asymmetric such that I can make a public
| half available publicly and then use that to generate
| signatures of any challenge the server sends.
|
| With passkeys either the server needs to store the value
| raw(making it susceptible to data breaches or malicious
| actors), or store the hashed value(making it impossible
| to do a challenge-response, and making it susceptible to
| MITM/replay attacks).
|
| It seems to be all the downsides of SSH keys(aka losing
| it having implications), with none of the upsides, plus
| additional downsides(hardware devices can only generate
| 25 unique ones instead of using 1 and sending the public
| to all services with confidence it hasn't exposed any
| private info).
| toomuchtodo wrote:
| They are a pleasant and improved UX for the equivalent of
| X.509 PKI primitives.
|
| https://en.wikipedia.org/wiki/X.509
| zie wrote:
| Well, different anyway.
| depingus wrote:
| > Passkeys can make it harder to switch password managers
| because the password managers are designed not to let you
| copy-and-paste a passkey, including from Google's Password
| Manager to Apple's Password Manager.
|
| This part right here is what I fear the most about Passkeys.
| I've read too many horror stories of people getting banned
| from Google (often for no valid reason) and losing access to
| all of their data. It is absolutely insane to hand over all
| your passwords to a company like this.
| mingus88 wrote:
| I have been using passkeys for a while in the form of
| yubikeys
|
| Best practice is to register two keys to every website.
| Keep one physically in a safe.
|
| With password managers I would say the same basic practice
| applies. Make sure you have a working offline backup of
| whatever secrets you hold dear.
|
| There are some sites that only allow you to register a
| single passkey for an account (AWS Console last I checked)
| but these should be getting fixed as it becomes more
| popular
| Thrymr wrote:
| > Best practice is to register two keys to every website.
| Keep one physically in a safe.
|
| Well, this sounds convenient. Keep the second one in a
| safe, but register a key to it for every website you use.
|
| Is this a practice we actually believe users will carry
| out?
| red_admiral wrote:
| I'm assuming tech people would also like to know that a
| passkey is not just "a really long password" but also one
| that's never sent to the server directly - instead it's used
| in a challenge/response protocol (like SSH keys). Which
| requires software, either the browser or an external password
| manager, to run.
|
| I think that's what you're getting at in paragraph 3?
|
| There's no reason you couldn't have an open source passkey
| manager that allows you to backup and view the key if you
| really want to. SSH works just fine that way.
| Xelynega wrote:
| It's up to the server whether it uses it in challenge-
| response or not. That's application-specific behaviour
| that's past the definition of passkeys themselves.
|
| The reason you couldn't have an open source passkey manager
| that allows backup is that it wouldn't be a "passkey
| manager" then, just a password manager. To be a passkey it
| seems to require that it can't be exported/viewed other
| than by the website it was created for(even by the user).
| kxrm wrote:
| > even by the user
|
| Perhaps this is something I shouldn't be feeling, but
| this bothers me and I do not know why.
|
| I can see that you might not want it exposed to the user
| to prevent social engineering but at the same time, if I
| can't view then I don't feel like I actually own it. Is
| there a mechanism that might exist to help me not feel
| this way? I am totally new to passkeys as a concept as
| well, but I understand the larger goal.
| sodality2 wrote:
| Personally it bothers me, and I don't want to feel any
| different. If I can't back it up or share it, it's not
| something I want to use. It's different than something
| like TOTP where even though I can't functionally hand-
| calculate it, I can still move the secret anywhere I want
| closeparen wrote:
| Passkeys are signing a challenge using a captive secret,
| right? The relying party doesn't get the secret.
| mac-mc wrote:
| > By requiring the passkey to be managed by a password
| manager, you get some anti-phishing protection. A passkey
| includes metadata, including the website domain that created
| it, and the password managers simply won't provide the
| passkey to the wrong domain.
|
| There are so many apps that don't get this right. Make a
| login on the website, store it in 1password, and then try to
| login in their mobile app and it doesn't show up as a
| password because the associated URL is mismatched on the
| mobile app. Like mybank.com and auth.mybankmobileapi.com
| mingus88 wrote:
| 1password has a URL field. All you have to do it add the
| extra URLs
|
| Better yet, while on mobile, search for the entry of the
| desktop site and have it fill. 1password will ask if you
| want to update the entry for this site
| torstenvl wrote:
| > _there 's no social-engineering technique someone can use
| to get you to copy and paste your passkey to an enemy_
|
| This is a deep, fundamental flaw in passkeys. It's just
| another example of enshittification disguised as denying end-
| user control "for their own good." There is no for-profit
| organization anywhere that I trust more than I trust myself,
| and there's no threat model where it's more likely I'll be
| socially engineered into giving up my long random password
| than that I'll suffer data loss.
| iknowstuff wrote:
| Then use a password manager that allows it
| Angostura wrote:
| Thank you. Very helpful
| al_borland wrote:
| I have been using 1Password for over 15 years and it has the
| ability to only show/fill passwords when on the correct site.
| The issue is, over time, companies shift their strategies on
| the web. URLs change, while the accounts stay the same. I
| have had to update these details many times. I've also run
| into situations where the browser plugin isn't functioning,
| for whatever reason, and the only way in is to copy/paste.
| There are also times where I'm not on my computer. For
| example, I usually piggyback on my dad's copy of TurboTax
| each year. When I'm over there, I will often need to pull up
| a password on my phone and type it into TurboTax as it logs
| into my bank to download the tax forms. Passkeys don't sound
| like they can solve that problem. I'd question if the
| Passkeys would work in TurboTax even if I was running it on
| my own computer.
|
| With passwords and logins, it seems like there are far too
| many edge cases to draw a hard line to say they are locked in
| the password manager forever. Having a way to copy it out, or
| export, is also a way to ensure portability, if the password
| manager being used ever becomes bad and a different option is
| needed.
|
| Password managers put users in a vulnerable position, as once
| a user is invested, they've got you by the short hairs. The
| thing that keeps this from being a big problem, is that there
| is always a way out. Eliminating this way out, or raising the
| barrier to exit, can temp these password managers to extort
| their users, which is not good.
| caconym_ wrote:
| A few weeks ago, I was unable to log in to Google on a new
| device with my 2FA token (Yubikey) because Google insisted on
| authenticating with a passkey/resident key, but the token had
| only been set up with non-resident TOTP or whatever it's called
| (and had been working properly in this mode for over a year). I
| was able to log in on another device and register the Yubikey
| with a passkey/resident key, but it was really scary! There is
| so much complexity here, and so little visibility and control
| afforded to users, that I feel very uncomfortable trusting it
| as my only login method for any moderately important service.
|
| It's possible this was a Mac OS problem, but I don't think it
| really matters. Either way, this stuff needs to be absolutely
| rock solid and frictionless if normal people are going to use
| it safely, and it obviously isn't.
| tptacek wrote:
| The problem Passkeys (and FIDO2 and WebAuthn and U2F) solve is
| phishing. The core concept is mutual authentication: not just
| you to the service, but the service to your authenticator.
| nomagicbullet wrote:
| I agree, framing it as a mental model makes sense.
|
| Here's the issue: when a site rejects my password, I understand
| the potential reasons--wrong site, wrong account, or forgotten
| password update. But what does it mean when a passkey fails?
| How can I resolve this? Is it even fixable?
|
| My lone attempt to use a passkey for login involved an
| unrecognized fingerprint authentication, leading to repeated
| failures and ultimately, a return to traditional passwords due
| to the opaque nature of passkeys.
|
| For now, I'll stick with what I understand.
| dwaite wrote:
| The primary advantages of passkeys are phishing resistance,
| uniqueness per site, and breach resistance.
|
| Phishing resistance is improved over what a good password
| manager can provide (unique passwords per site, checking web
| origin before providing options). Since WebAuthn is a protocol,
| the origin of the requesting site is stamped into the
| authentication response; even if the user had the option to
| override a passkey to be sent to a different malicious domain,
| it is meant to be rejected if replayed on the legitimate
| website. WebAuthn really needs an attacker to compromise the
| legitimate site or to compromise DNS and TLS infrastructure for
| phishing to be successful.
|
| The uniqueness is really two benefits in one - you don't need
| to think of multiple unique passwords (if doing manual password
| management), or suffer with password complexity rules (if doing
| either manual or automated password management). It is just a
| public key, usually a P-256 curve point. The security of the
| user authentication process is abstracted upstream, so it is
| secured with the local password/biometric or via an activation
| PIN (same as password managers).
|
| The breach resistance means that if XSS gets onto the page, if
| a hacker gets read-only access to the password database, it is
| still infeasible for them to leverage anything they gain to
| answer future authentication challenges. If your passwords
| aren't unique, a breach is a big deal and can create a lot of
| lateral movement. Even if they are unique, attacker visibility
| of the password means account compromise. The private key in a
| passkey is separate from the website infrastructure, so that
| attacker is not going to be able to authenticate from anything
| they observe.
| pbnjeh wrote:
| What the parent says. I'm hoping this HN thread will help
| clarify this.
|
| Currently, I view the entire paradigm as asking me to trust
| resources (software, hosting, etc.) that I am not ready to
| trust. Both from a knowledge standpoint, or lack thereof on my
| part, and out of experience. Re the latter, third party
| resources die, go bad -- technically or morally -- and... just
| observing the nature of "online" resources over years and now
| decades.
| riedel wrote:
| Totally agree. I have used fido2 and webauthn before and I
| liked it. Particularly with a hardware key the mental model is
| quite straightforward. Now with that Microsoft, Google and
| syncing business I am left totally confused. Why the hell
| should alI store a private key in some cloud?? What happens if
| that provider decides to terminate my account, if it gets
| pressured to release the key? Also how does this all work with
| Windows Hello and other things in between??? I know a bit of
| crypto and security protocola but the passkey concept and
| possible attack vectors totally escape me.
| cosmosgenius wrote:
| I wanted to use Passkeys from the initial spec stage. The UX
| seemed far more superior (the closest I think is passwordless via
| email).
|
| But the more I wanted to use Passkeys are more scary it got,
| basically the gut feeling of losing control.
|
| If we could use something akin of derived, reproduceable-ish
| (???) Passkeys maybe then.
|
| As of right now it feels wrong.
| cosmosgenius wrote:
| (derived, reproduceable-ish) sounds like a security horror O_o.
| knallfrosch wrote:
| You can set up a new Ledger (crypto wallet) and
| deterministically recover your keys using a sheet with 24
| words written on it.
|
| I've got my sheet in my gun safe, but you can also hide it
| anywhere in your house.
| jchw wrote:
| Yeah, unfortunately passkeys are confusing and the UX is
| generally fucking awful. I hesitate to _just_ blame the tech
| companies for being greedy, as a result of my experience with
| passkeys I 'm starting to wonder if maybe they've legitimately
| just lost the skills and knowledge necessary to actually make
| usable software.
|
| What's most disappointing is, password managers have already
| solved the problem of syncing credentials securely between
| multiple devices across different form factors and ecosystems,
| and they're perfectly usable for providing software passkey
| support. So _of course_.. there 's no standard API for them to
| implement it. Instead, vendors are patching the WebAuthn APIs
| using WebExtensions.
|
| This is sabotage.
| arianvanp wrote:
| FWIW: MacOS and iOS allow third party password managers to
| ingrate directly into AuthenticationServices and list passkeys
| in the native passkey UI through a "Credential Provider"
| extension. And it's documented how:
| https://developer.apple.com/documentation/authenticationserv...
|
| This is the same Credential Provider API they already have to
| integrate with to show the password autofill in iOS so there is
| already _some_ code for this.
|
| 1Password _could_ just integrate with the native UI. But they
| chose not to. This however means shipping a native app which is
| a lot more heavy-weight than shipping a web extension.
|
| I opened an issue in the webauthn repo about giving an API for
| WebExtensions to hook into the passkey autocomplete but there
| hasn't been any traction or appetite for it unfortunately :(
|
| https://github.com/w3c/webauthn/issues/1976
| jchw wrote:
| > 1Password _could_ just integrate with the native UI. But
| they chose not to. This however means shipping a native app
| which is a lot more heavy-weight than shipping a web
| extension.
|
| I mean, I kind of understand this; they're going to have to
| do the WebExtension either way, since there's no standard API
| across platforms.
| arianvanp wrote:
| On the other hand. They already integrate with this API for
| their iOS app as it's the only way to do password
| autocomplete on iOS. Why not extend that use to MacOS?
| jchw wrote:
| Maybe they will eventually, but the macOS app is a cross-
| platform Electron app, isn't it? I'm guessing none of the
| code is shared.
| G3rn0ti wrote:
| Hm. The main criticism is you get locked into a cloud platform
| storing your private key(s) when using ,,passkeys". This can be
| convenient as you can use your favorite smart phone to
| authenticate everywhere or even choose to rely on local TPM
| storage on your laptop or PC through MS Windows. This trades
| convenience with the risk of a vendor lock-in. But AFAIU the
| FIDO2 protocol you are free to use a dedicated USB key storage
| instead to store your private key (protected by a PIN or
| passphrase) on your own. This a bit less convenient but gives you
| peace of mind if you hate MS/ABC/Apple.
| tux3 wrote:
| >you are free to use a dedicated USB key storage instead to
| store your private key
|
| As long as the server supports the device/protocol/options you
| want, and doesn't enforce attestation against a small list of
| enterprise vendors.
|
| For instance Microsoft Azure AD's Entra ID authentication
| service, the one that keeps changing name, has a hardcoded list
| which you can consult here: https://learn.microsoft.com/en-
| us/entra/identity/authenticat...
|
| In theory there's no vendor lock-in. As long as Azure adds your
| vendor to the Azure-approved list, and as long as every other
| provider refrains from making their own list.
|
| For the Apple/Google ecosystems specifically, it's also
| important to keep the compatibility matrix for each service in
| mind. For instance with Azure again:
| https://learn.microsoft.com/en-us/entra/identity/authenticat...
|
| In theory any FIDO2 implementation could work with any service
| that accepts passkeys. In practice, compatibility matrices and
| allowlists are the reality.
| dudeinjapan wrote:
| At TableCheck we rolled our own passkeys SP implementation
| primarily for our internal users, so they can access admin-level
| accounts without passwords.
|
| Personally I love the convenience of passkeys (coupled with
| 1Password pw manager), however, for whatever reason it doesn't
| "feel" like Passkeys _replace_ passwords but rather they
| _complement_ them. I treat Passkeys as ephemeral--it is lovely
| when they work, but sometimes I still need to fallback to trusty
| ol' password login.
| PaulHoule wrote:
| Passkeys always had a bad smell to me.
| crabbone wrote:
| Somewhat related: last New Year the company I work for gave us,
| the employees, presents. Something I assumed to be a USB disk.
| Couple weeks ago I had to migrate from my old personal laptop to
| the desktop I finally put together and needed a USB key to put an
| OS on the new computer.
|
| I recalled I had what I thought was a spare USB key... plugged it
| in only to discover it wasn't a USB disk. Wasted some time trying
| to figure out what it was only to discover it was some form of
| electronic key. Not sure how exactly it works... but, of course,
| Linux had no drivers for it, so it couldn't even recognize the
| device.
|
| I tried to think about any possible uses I could want from it and
| whether it's worth the effort of trying to find an out-of-kernel
| driver for it... and after some time pondering this idea, I
| realized I have no use for this thing. There's no scenario in
| which I would like to have a device to perform this function. So,
| bundled it with the broken pieces of my old laptop and together
| they went to the garbage dump.
|
| Passkey would be virtually the same thing. I cannot imagine what
| problem does it solve, no matter how it works. Everything about
| this idea seems like a bad idea. So, I'm kind of happy it's a
| shattered dream now. Better late then never, I guess.
| crote wrote:
| The part I hate most about Passkeys is that it essentially killed
| the FIDO1/U2F ecosystem.
|
| Just about every website which implemented Passkeys removed the
| option to use hardware tokens with "non-resident" credentials.
| This means you're stuck using your Yubikey as either an insecure
| TOTP token, or as a practically-useless Passkey.
|
| We had the _perfect_ 2FA method with U2F hardware tokens, why did
| they have to take that away?!
| TacticalCoder wrote:
| > We had the perfect 2FA method with U2F hardware tokens, why
| did they have to take that away?!
|
| It deeply saddens me too.
|
| But I _think_ we shouldn 't discard one of the obvious reason:
| the U2F system was _too secure_.
|
| Let's not forget this: the original U2F system even had a way
| for the user to know if its device had been cloned, for they'd
| be using a counter. And they silently removed this.
|
| When Apple+Google+MSFT team up to lower security, I'm pretty
| sure three-letters agencies and their backdoors aren't very
| far.
|
| The whole concept of passkeys that can be copied around is
| honestly hilarious. FFS: we had the perfect solution...
|
| I don't think it's only incompetence at work here: there has to
| be mischief or at least mischief shouldn't be discarded.
| kmlx wrote:
| > Apple Keychain has personally wiped out all my Passkeys on
| three separate occasions. There are external reports we have
| recieved of other users who's Keychain Passkeys have been wiped
| just like mine.
|
| i have been using passkeys on apple since they launched it. i
| have also converted all of my 2fa's to passkeys (where supported)
| or enabled them as password alternatives. a lot of website
| support passkeys nowadays. i never encountered what the author
| encountered and it seems like something seriously wrong happened.
|
| did anyone encounter this issue? is it logged somewhere?
|
| i seriously considered dropping passwords completely for future
| projects, but it looks like there are still issues...
| aktuel wrote:
| This was so obvious from the start. Whenever big tech creates
| "standards" now you already know it's going to be total horse
| shit. Look back at the old threads when passkeys launched. HN was
| full of fanboys thinking it's the best since sliced bread and
| passwords are so yesterday. Managing your passwords takes a bit
| of effort like everything in life where you don't want do give
| away control completeley to some corporate aholes. Whenever you
| let someone else manage your stuff you set yourself up to getting
| ducked.
| nottorp wrote:
| Translation: the solution is overcomplex and has so many failure
| points that it has already proven to be worse than passwords.
| AlexandrB wrote:
| I've noticed a few websites I frequent have quietly started using
| passkeys (or something very similar) outside of the normal
| channels. My bank now asks me to go through a second factor on my
| phone app that seems very similar to how passkeys work and
| Outlook has a similar login flow but with an additional 2 digit
| challenge code for some reason.
|
| With both of these I have little sense of what is going to happen
| if I lose my phone or switch to a new one. So typical passkey
| problems.
| 8organicbits wrote:
| I gave up on passkeys after running Google's passkey demo and
| getting started example. They impement session expiration client
| side only. I reported it, but they said it had been reported
| already and they didn't intend to fix it. Seems a little careless
| for a tool promising improved security.
| noirscape wrote:
| The main thing that hurts Passkeys was how the implementation was
| so deeply tied to letting the browser do stuff rather than making
| it something like TOTP where any password manager can implement
| it and it's usable, agnostic from the browser. Everything about
| Passkeys is defined around using your browser as the agent that
| authenticates.
|
| The problem is that browsers are _infamous_ for randomly losing
| things like localstorage, settings and saved passwords. It 's way
| too volatile software to do authentication with besides a "stay
| logged in" checkmark. In both of the main desktop browsers, a
| corrupt profile is often only "fixable" by just nuking it and
| having the browser recreate it.
|
| That's what killed Passkeys; people you want as early adopters
| (technical folks) don't use it because browsers aren't a
| trustworthy storage and the implementations all severely stalled
| in providing alternative methods that are tied to more reliable
| storage mechanisms. The hyper aggressive vendor lock-in is also
| not helping much (to the point where KeePassXC got yelled at for
| providing an export mechanism).
| shepherdjerred wrote:
| Here's my opposing view: I love Passkeys.
|
| I use Firefox as my browser and 1Password as my password manager.
| On my iPhone, I use 1Password + Firefox.
|
| I look at https://passkeys.directory/ every so often and switch
| my logins from passwords to passkeys. This has included a lot of
| my common logins like GitHub, Google, and Microsoft.
|
| There is a lot of confusing terminology. For some reason sites
| will say "login with Touch ID" or "login with Windows Hello"
| instead of "login with Passkey".
|
| Aside from that quirk, I love it. 1Password syncs my passkeys
| between devices. I can use them both on my laptop and my phone.
| It would be inconvenient if I needed to login to a shared
| computer e.g. at a library or friend's house, but I don't do that
| often enough to care (though of course some people do, which is
| totally valid).
| sedatk wrote:
| I went through passkeys.directory site and it's underwhelming.
| Too few sites implement it, and many implement it
| inconsistently:
|
| - PayPal only allows one passkey and don't support logging in
| with it on Firefox on Windows. You still have to use your
| password.
|
| - Twitter only offers it if you pay for a subscription.
|
| - Playstation Network doesn't implement usernameless, and still
| asks for your email to log you in with a passkey.
|
| It seems like we still have some way to go before we figure it
| all out.
| kstrauser wrote:
| I'm with you on that. Also, 1Password's built-in Watchtower
| tells you which of your saved accounts could have passkeys
| added to them.
| m3kw9 wrote:
| You use it because a concensus of security experts is cool with
| them, a normal person has no way of analyzing it properly. I see
| a few post regarding "I rather stick to generated passwords and
| have a program memorize it for them" it's rather funny the way
| they rebuke new vetted tech
| powera wrote:
| Please, stop with the "anything that happens that I don't like is
| _enshittification_ " trend.
|
| Please.
| m3kw9 wrote:
| Passkeys has a good UX and security balance. The other method
| would be to memorize a 20 length random password all inside your
| head or let grandma create a "password" so she can easily
| memorize it.
| exabrial wrote:
| How about we stop reinventing the fricken wheel every 3 years and
| let users adopt something? U2F keys were pretty danged good and
| they were easy to explain to my 70 year old parents "This is like
| your front door key to your house, it's a physical key to your
| Google account".
| formerly_proven wrote:
| > Within enterprise there still is a place for attested security
| keys where you can control the whole experience to avoid the
| vendor lockin parts. It still has rough edges though.
|
| Just use PKI / X.509 with hybrid smartcards for enterprise use
| cases. Sure, it's "legacy" and you need an PKI expert to set it
| up, but it actually works and is genuinely platform-, vendor- and
| protocol-agnostic. FIDO is smelly poo poo in comparison.
|
| Also, smartcards had usernameless for 30 years.
|
| Edit: actually we've been here before. Remember the <keygen> tag?
| Platforms (browsers) could generate a key pair for you, store the
| private key in their key store (I think <keygen> actually
| supported smartcards as well), and forward the public key to the
| server for enrollment. The server then sent the signed
| certificate back. That's pretty much exactly passkeys. This was
| somewhat widely used for "high security" applications at its
| peak, circa 2007.
|
| Similar problems like passkeys caused issues, it was difficult
| for users to get their keys and back them up, most people were
| just one hard drive crash away from loosing access.
| jslakro wrote:
| I suppose this means OTP's would continue gaining traction as an
| alternative to password managers, a convenient approach but a
| risky single point of failure
| tunesmith wrote:
| Every time I see a long inscrutable discussion about Passkeys, I
| see a weird avoidance of the "something you know" part of
| security. Here in the US, courts and law enforcement have every
| right to get your username, fingerprint, retina scan, face ID,
| whatever. But they don't have the right to extract something from
| your brain. Unless I'm missing something basic (which at this
| point, I don't think is my fault since this whole thing appears
| incredibly difficult to explain), Passkeys skips past that whole
| thing in favor of making it a heck of a lot easier to replace
| "something you know" with "something you have". Which is a
| security nightmare.
| victor106 wrote:
| > But they don't have the right to extract something from your
| brain.
|
| Most folks store passwords in password managers and don't use
| their brains to retrieve them.
| SkyPuncher wrote:
| But my password manager locks....requiring something stored
| in my brain.
| Fire-Dragon-DoL wrote:
| Doesn't your password manager use biometrics to unlock
| though?
| fabrice_d wrote:
| Not necessarily. I use bitwarden with a master password
| to unlock the vault.
| doubled112 wrote:
| I stick with passphrases so nobody steals my retina or
| thumb.
| SkyPuncher wrote:
| Yes, but that's locked behind an OS level pass screen.
| noahtallen wrote:
| Which is exactly where your passkeys can be stored too. Put
| them in a password manager like 1Password, disable
| biometrics, and law enforcement would have to enter a
| password to access them
| LamaOfRuin wrote:
| Keys can require a pin (or maybe a password depending on
| implementation).
|
| But in general I haven't felt these are secure enough for the
| reason you say.
|
| While my practical threat model today would make passkeys seem
| great, the theoretical future threat model in my head does not
| support it.
| kevincox wrote:
| PINs and passwords on HSM keys like this are typically very
| secure as they will wipe themselves or at least lock
| themselves after a small number of failed attempts. For
| example if you only allow 5 failed attempts a 4 digit random
| PIN has a 0.05% chance of being guessed and a 6 digit PIN is
| 0.0005%.
|
| So the only real risk is key extraction, hardware key
| extraction is always possible but likely incredibly
| expensive, so for most threat models it is not an issue.
| (Software key extraction or side channels is a different
| problem which may be easier but in theory is not possible.)
| franga2000 wrote:
| PIN+limit is still a much worse user experience than a
| password:
|
| - a PIN is hard to memorize, so people are more likely to
| use personally-relevant or common numbers, whereas a
| password can be easily be both complex and memorable - it's
| easy to burn through even 10 login attempts through any
| combination of temporary/permanent disability, stress,
| being drunk, damaged device... - a wipe-after-failed-
| attempts system is trivial to abuse, be it by a prankster
| or a real adversary - it's much easier to see someone's PIN
| over their shoulder or film them entering it
| wayeq wrote:
| > But they don't have the right to extract something from your
| brain.
|
| sure they do if, unless you want to be held in contempt of
| court for not providing the information.
| echoangle wrote:
| Don't you have a right to not incriminate yourself? You only
| have to give them information as long as you're not
| incriminating yourself, right?
| saulrh wrote:
| Historically, US courts have declared that giving a
| password is proof that you control the given asset and that
| this can be incriminating.
|
| In practice, juries will take a refusal to divulge a
| password as evidence of guilt, the cops will use it as an
| excuse for even greater brutality, the FBI is perfectly
| willing to hold you without trial for years on end, and in
| most cases they don't need it anyway because everything
| lives on someone else's computer and they're perfectly
| willing to hand your data over if they haven't already.
| Furthermore, because the defense is founded on the
| principle that the password serves as evidence that you
| owned the encrypted data, if the prosecution is able to
| prove that you owned the encrypted data in any other way,
| that protection goes away. > In Boucher,
| production of the unencrypted > drive was deemed not
| to be a self-incriminating > act, as the government
| already had > sufficient evidence to tie the
| encrypted > data to the defendant
|
| I am, of course, not a lawyer. I'm just summarizing easily
| available information, i.e. wikipedia.
| orthecreedence wrote:
| You cannot be compelled (in US court, anyway) to give up
| encryption passwords/keys.
|
| You can certainly be compelled in a black site torture den,
| but _most_ people don 't have that as a looming threat yet.
| HeatrayEnjoyer wrote:
| > You cannot be compelled (in US court, anyway) to give up
| encryption passwords/keys.
|
| Multiple people have been held in contempt for refusing to
| provide an encryption password by US courts.
| echoangle wrote:
| [citation needed], can you give a link? In a court case
| about their own crimes?
| orthecreedence wrote:
| Maybe it's slightly more nuanced than I thought. This (ht
| tps://crsreports.congress.gov/product/pdf/LSB/LSB10416)
| seems to be an interesting report on the issue, although
| in most cases a defendant cannot be compelled to unlock
| their password-protected device. Biometrics might be
| different, but honestly, don't use a fucking fingerprint
| unlock if you've got "sensitive shit" on your device.
| Duh...
| dpifke wrote:
| In the U.S., this is a still-evolving area of law, which was
| argued before the Supreme Court last month: https://www.supre
| mecourt.gov/DocketPDF/23/23-1020/302999/202...
|
| The State of Utah allowed the jury in _State vs. Valdez_ to
| infer that a suspect was guilty because he refused to provide
| his password to the police. On appeal, the Utah Supreme Court
| ruled that he had the right to withhold his password
| according to the 5th Amendment, and he shouldn 't face
| negative consequences for doing so. The state appealed that
| ruling to the U.S. Supreme Court, citing various other state
| and Federal courts which have made conflicting rulings on
| this same issue. A decision is expected in June.
|
| More info/commentary here:
| https://reason.com/volokh/2023/12/14/is-compelled-
| decryption... (But I recommend going directly to the primary
| source material--legal documents in Supreme Court cases are
| very accessible, even to non-lawyers.)
| jgalt212 wrote:
| > when the room is in a country that has a list of travel
| advisories including "Violent crime is more common in the US than
| in Australia", "There is a persistent threat of mass casualty
| violence and terrorist attacks in the US" and "Medical costs in
| the US are extremely high. You may need to pay up-front for
| medical assistance".
|
| What's wrong with these Aussie technocrats?
| skybrian wrote:
| I don't trust passkeys, and yet so far, I'm not bothered by them.
| This is because I use them as an _additional_ way to log in.
|
| The other day I noticed that for some reason GitHub couldn't seem
| to find my Android passkey. Weird. So I logged in using my
| Yubikey and recreated it.
|
| But this would be a lot worse if it were your _only_ way of
| logging in. Always have multiple authentication methods for
| important accounts.
| qudat wrote:
| Likewise frustrated by the passkey implementation but like the
| idea. I've been experimenting with passkeys leveraging SSH
| tunnels. You can read more about it with a demo here:
| https://pico.sh/tunnels
| throw7 wrote:
| Just wanting to get rid of "passwords" means getting rid of
| "something i know" as an authentication factor. That should not
| be the goal. The issue is that the other authentication factors
| have real drawbacks. It's tradeoffs all around.
|
| 'something i have' means carrying something around and also the
| possibility of it being forgotten/stolen/broken/taken by
| authorities (legally even!) and the repercussions of that. i'm
| fine with this, only if i am allowed to access/export/copy/store
| the keys myself. I can do that with totp auth and i do. people
| say this "breaks" security. but the point is: i control what i
| own; i control me (not you).
|
| 'something i am' has the worst drawback. you can't change it! the
| other issue is you are not the unique snowflake you think you
| are. Also, side note of a personal experience: India has mass
| fingerprinted everyone, yet in trying to do some bank
| transactions in India the fingerprint read/auth kept failing for
| an acquaintance.
| 0xbadcafebee wrote:
| There is no auth panacea. There's too many different use cases,
| too many players involved. You cannot create one "thing" that
| solves all the problems for all the people. It was hubris.
|
| Instead, if "the industry" wants to solve "the problem", they
| need to write down all the use cases. Then we can argue about how
| to do that, and the result will probably be a couple different
| things that solve a couple different groups of use cases.
|
| But what will always suck is letting "the industry" dictate to us
| "tech peons" how that should happen. They always come up with
| bloated standards that are a pain in the balls. So rather than
| let "the industry" solve the problem, I think we need a loose
| confederation of open source contributors and corporate goons to
| meet on some forum somewhere and hash it out. Let the solutions (
| _plural_ ) come organically without a single player controlling
| the conversation.
| bloppe wrote:
| This feels overly cynical to me. The article is a bit rambly so
| let me try to distill the problems:
|
| 1. Most relying parties support resident keys only. This makes a
| bad user experience because users are surprised when they run out
| of space, and may have to wipe their device to get more.
|
| 2. Most authenticators do not allow you to export your keys. If a
| relying party only allows a single credential per account, this
| creates authenticator lock-in, which is a bad user experience.
|
| 3. Chrome is uncooperative about the Authenticator Selection
| Extension, and that can make a bad user experience if the relying
| party rejects the device attestation after enrollment.
|
| Yes, these are all bad user experiences, but they don't indict
| the technology. It sounds to me like the relying party can
| mitigate all of these issues:
|
| 1. Support non-resident keys. Seems like it really doesn't have
| to be a bad user experience. Usernames are easy to remember. Just
| use their email address.
|
| 2. Support multiple keys per account. Most users will have
| multiple authenticators. Let them enroll several and they're not
| locked into any one in particular. Most users won't care about
| this, but for important services it's an option.
|
| 3. As a relying party with strict authenticator requirements,
| just explain those requirements on the passkey registration page.
| People can read. They don't have to be _that_ confused when their
| unsupported key doesn 't work.
|
| I get that there's nothing users can do when the relying party
| creates a bad experience, but if a relying party has all the
| power to create a good experience, is it really worth being this
| gloomy about the technology?
| tonymet wrote:
| Tech articles have gone the way of online recipes. I had to read
| his grandfather's biography to understand he had a bad experience
| logging in with passkeys
| DavideNL wrote:
| > " _If you really want passkeys, put them in a password manager
| you control. But don 't use a platform controlled passkey store_"
|
| That is my main reason for avoiding Passkeys;
|
| I will only use Passkeys, when i can export/backup them easily
| and store an offline backup, without depending on some Big Tech
| company or whatever. (KeepassXC can export them, but not sure if
| it's released and fully functional in the stable build yet.)
|
| What also worries me however, is that apparently if i read
| correctly, each server/service/website can decide/restrict "
| _which_ password managers /apps" are allowed to be used for the
| Passkeys they offer...
| mantra2 wrote:
| "...if you do want to use a security key, just use it to unlock
| your password manager and your email."
|
| This feels like the best advice, imo.
| chrisjj wrote:
| > Just like ad-blockers, I predict that Passkeys will only be
| used by a small subset of the technical population
|
| Hmm...
|
| "As of Q3 2021, 37.0% of internet users worldwide use ad
| blockers, according to GWI data cited by Hootsuite."
| https://www.emarketer.com/insights/ad-blocking/ "
| jrm4 wrote:
| Yeah, good riddance.
|
| I get the capitalist inclination and desire to make things easier
| for people (and often infantilize them) but this just ain't it.
|
| There is no _easy_ solution here. Security is difficult and there
| are no shortcuts that involve "make things easier for the
| general public" that don't ALSO involve "make things MUCH HARDER
| (either in complexity or LIABILITY for getting it wrong) for the
| company providing the security."
| nivenhuh wrote:
| For folks who don't know how passkeys work at a technical level,
| take a look at this implementation guide: https://webauthn.guide/
|
| I don't get the passkey hate -- moving to public key challenge
| for authentication is a strong step forward for web security.
| Each browser / OS safeguards & backs up the private key (and even
| if that's lost, you can still reset your auth credentials using a
| normal "forgot password" flow).
| jjav wrote:
| > I don't get the passkey hate
|
| The linked article does a quite good job explaining why hating
| passkeys make sense.
|
| Here's a key quote, but I do recommend reading the whole
| article.
|
| > Since then Passkeys are now seen as a way to capture users
| and audiences into a platform. What better way to encourage
| long term entrapment of users then by locking all their
| credentials into your platform, and even better, credentials
| that can't be extracted or exported in any capacity.
| tadfisher wrote:
| I don't believe this is necessarily true, as far as intent
| goes. I think Apple and Google focused on a core use case,
| shipped it, and subsequently lost interest or fired everyone
| involved.
|
| Unfortunately, this scenario is indistinguishable from one in
| which they deliberately mishandled the specs in order to lock
| in users.
| skarra wrote:
| Thanks for your faith. I work on the team shipping passkeys
| at Google. We are very much hard at work to realize the
| full potential of passkeys. Platform lockin serves no one.
| That is no one's intent - independent password managers
| storing passkeys is already a thing today. More interop
| will come once relevant standards are blessed.
| kobieps wrote:
| When Apple announced passkeys it was obvious that this would be
| the end result. I remember quite clearly complaining to a friend
| of mine at the time.
| latchkey wrote:
| I just went through the dance of logging out of all my google
| accounts and then logging back into them. While I was doing that,
| I added passkeys as a security layer.
|
| Using bitwarden, it adds them in just fine. But, if you go and
| try to log into a Google account with Brave, it tries to use the
| Brave system builtin instead of the Bitwarden one. Presenting a
| dialog too.
|
| As an end user, I don't know if it is bitwarden, brave or google
| screwing this up and I can't be bothered to figure it out, so it
| is back to just using passwords and 2FA...
| cchance wrote:
| Just add a passkey for brave too
| latchkey wrote:
| No, I don't want to be tied to a single browser for my
| passkey, what happens if I want to log into a site on my
| phone using safari or chrome? I also don't want it tied to my
| apple keychain. What if I want to share my passkey with my
| partner?
| gclawes wrote:
| For what it's worth, 1Password Passkeys works fine in this use
| case. I suspect it may be a subtlety in how BitWarden works.
| latchkey wrote:
| Good to know, if it is bitwarden, then I guess I'll expect a
| fix in the future.
| Izkata wrote:
| > This library ended up with Kanidm being (to my knowledge) the
| very first OpenSource IDM to implement passwordless (now
| passkeys). The experience was wonderful. You went to Kanidm,
| typed in your username and then were prompted to type your PIN
| and touch your key. Simple, fast, easy.
|
| > For devices like your iPhone or Android, you would do similar -
| just use your Touch ID and you're in.
|
| The fingerprint scanner on my phone is so finicky this would've
| been a dealbreaker from the get-go. I regularly have to just
| enter my PIN because it refuses to recognize my fingerprint.
| jdthedisciple wrote:
| This was foreseeable.
|
| Sometimes you just know when a thing isn't practically feasible.
|
| https://news.ycombinator.com/item?id=36717356
___________________________________________________________________
(page generated 2024-04-26 23:00 UTC)