[HN Gopher] Passkeys will come at a cost
___________________________________________________________________
Passkeys will come at a cost
Author : xena
Score : 343 points
Date : 2023-07-13 17:06 UTC (5 hours ago)
(HTM) web link (fy.blackhats.net.au)
(TXT) w3m dump (fy.blackhats.net.au)
| Zamicol wrote:
| We're working on an open source alternative to Passkeys starting
| with Coze https://github.com/Cyphrme/Coze.
|
| We have not yet published our next steps, but we will soon.
| superkuh wrote:
| HTTPS only like this blackhats.net.au site comes at a cost too.
| If there's a browser/server SSL mismatch the text becomes
| completely unavailable. While if it was an HTTP+HTTPS site I
| could simply visit the HTTP endpoint. Instead to protect against
| hypothetical downgrade attacks they've made their content
| inaccessible and effectively DoS themselves for a small fraction
| of visitors.
| 8organicbits wrote:
| > small fraction of visitors
|
| This site won't work on Windows 7 / Chrome 69 as it only
| supports TLS 1.3 [1]. I believe 5% of the web can't connect
| [2].
|
| But the text on the site is for technically minded people and
| the content includes commands you should run and security
| configuration. Tampering of the content could be quite harmful.
|
| [1]
| https://www.ssllabs.com/ssltest/analyze.html?d=fy.blackhats....
|
| [2] https://caniuse.com/?search=tls1.3
| asdff wrote:
| Passkeys make no sense. Its selling you something you already
| own, since a fingerprint or a retina scan makes a fine good two
| factor as well.
| pndy wrote:
| > since a fingerprint or a retina scan makes a fine good two
| factor as well
|
| Last year I was making new IDs for myself and my mother which
| in the newest version require fingerprints being provided
| beside the biometric photo. The office clerk lady who served us
| had a real struggle with taking scans of our fingerprints. Our
| skin was damaged due to low temperature and extensive use of
| alcohol-based sanitizing gel because of _the current situation_
| back then. She gave us vaseline cream so this would go a little
| bit easier but no luck - each of us spent around 10 minutes
| scanning each finger till it got finally digitalized.
|
| The scanner used could a really cheap one and thus blamed for
| prolonging this whole scanning process or it was our skin
| condition or both these things. Whether it was, by this
| experience even if episodic one, I don't think that
| fingerprints are "a fine two factor".
|
| As for eyes: it's really unlikely it might happen to many
| people but eyes can be damaged and there are eye diseases that
| might affect verification. Not mention post-procedures
| treatment that excludes use of this scan technique for some
| time.
| danieldk wrote:
| Someone gains access to a Passkey. You generate a new Passkey
| and replace the registered Passkey for the server. Someone
| gains access to your fingerprints or retina scan... Game over?
| rcxdude wrote:
| biometrics aren't passwords. They are only somewhat useful as
| authentication if you can verify that they are attached to the
| person you are authenticating, which generally only works in
| person.
| Nadya wrote:
| What's your game plan for replacing your retina or fingerprints
| if compromised?
|
| Biodata is the least secure because it can't be easily changed
| and the technology already exists to compromise them.
| secabeen wrote:
| Compromise isn't even the most common issue, it's your
| incapacity or death. Your relatives need some way to get into
| your accounts when you can't.
| wongarsu wrote:
| In 2014 the fingerprints of Angela Merkel and the German
| Defense Minister were "cloned" by taking high resolution
| pictures at a press conference. Against targeted attacks, using
| something that's readily visible on your person isn't the best
| idea.
| wepple wrote:
| > Are non-resident keys less secure?
|
| The answer provided by the author (TLDR: you'd have to break AES)
| is far from satisfying to me.
|
| With a resident key, the only thing an attacker on an endpoint
| could ever get is a challenge & a response to that challenge.
| It's more than nothing, but limits a lot of attacks.
|
| With non-resident keys, an attacker can not only do all kinds of
| offline attacks* against the HMAC and crypto, but also has a far
| better position of attack against the the security key: you've
| got decryption, HMAC, key parsing code all happening on untrusted
| data (if done correct, HMAC will have to fall first).
|
| Further, you've got twice the encryption happening on the key,
| which could provide a larger attack surface for side channel
| attacks.
|
| I'm not saying any of these are trivial or even feasible, just
| that "citation needed" for resident key == non-resident key, in
| terms of security.
|
| *if your idea of an offline attack of this nature is "break AES
| with a brute force" and that's about it, there's a lot more
| options
| [deleted]
| TacticalCoder wrote:
| > Obsession with passkeys are about to turn your security keys
| (yubikeys, feitian, nitrokeys, ...) into obsolete and useless
| junk.
|
| I'm sad about that too but I'm finding some relief in the fact
| that non cloneable / non shareable physical security keys aren't
| going to be totally obsolete though: they're supported by OpenSSH
| and shall probably be so for a very long time. Even Google
| teaming up with Microsoft teaming up with Apple cannot fuck that
| one up in the near future.
|
| Not that it's much of a consolation.
|
| But yup, it's really sad how a conglomerate of the biggest actors
| managed to fuck up security keys while riding on the security
| benefits non-cloneable keys do bring:
|
| _" It's physical non cloneable non shareable security keys but
| better because... More convenient for they're actually not
| physical and actually cloneable and actually shareable"_.
|
| I saw it here on HN too on the various threads on passkeys: _"
| It's better because it's more convenient"_.
|
| I won't post more because it'd be swear words.
| Melown wrote:
| It's all about the FIDO2 hardware attestation. I'd rather use a
| FIDO2 authenticator with attestation. Call it a passkey or not, I
| don't want the to use the syncable passkeys without hardware
| attestation.
| stavros wrote:
| Am I the only person who finds it unreasonable that security keys
| only have enough storage for 5-10 resident keys? Why can't I
| store millions of keys? What's that, 50 MB? Why isn't that
| standard?
| dandanua wrote:
| Monopolies were shitting, are shitting and will be shitting on
| community standards. There will be no end to this until a radical
| change in the societal mindset.
| torstenvl wrote:
| I'm not a security or crypto guy at all. I found this very
| difficult to follow, and I suspect others might too.
|
| My questions probably seem weird to someone with enough
| background context to understand the post, but I am getting
| wrapped around the axle every sentence or two.
|
| > _It all comes down to one thing - resident keys._
|
| How/why? What's the connection to passkeys or HSMs?
|
| > _we need to understand what a discoverable /resident key is_
|
| Yeah okay... does this imply that all resident keys are
| discoverable keys? Or that all discoverable keys are resident
| keys? Or both?
|
| > _You have probably seen that most keys support an 'unlimited'
| number of accounts._
|
| No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or
| both? Or something else entirely?
|
| > _This is achieved by sending a "key wrapped key" to the
| security key._
|
| Okay so an HSM can apply to an unlimited number of accounts
| because it can store... some kind of key wrapped in another key
| (of the same type? different type?)
| dcow wrote:
| It's a poorly argued point, agree. Essentially the author is
| arguing that the ability in the WebAuthN protocol for Relying
| Parties to be able to specify `rk=required` is considered
| harmful because it excludes tons of TPM hardware from being
| able to work as a _Passkey_ wallet /db. I think most people in
| the comments probably agree. That doesn't excuse all the
| confusion the author creates by essentially bike-shedding the
| definition of passkey for half the essay.
| torstenvl wrote:
| I _think_ the upshot is this:
|
| The hype around passkeys is high enough that basically all
| authentication layers are requiring passkeys when they're
| available. This is a problem because passkeys must be stored
| in the client-side authenticator (password manager, hardware
| token, whatever), some of which have very limited capacity
| for storing them.
|
| This is compounded by two problems: (1) Extant standards for
| storing these keys on hardware tokens don't allow deleting
| them individually, though this is changing in the newest
| standard; (2) Many current hardware tokens claim to have huge
| capacities, but this is based on a different challenge-
| response mechanism than passkeys. As a result, users will be
| pressured into using passkeys often, run out of precious
| passkey space despite thinking they have plenty, and then be
| forced to forego the benefits moving forward or reset and
| lose their keys.
|
| Is that more or less accurate?
| gtvwill wrote:
| Gonna only say this once. Stop building your forts with only one
| wall and one gate. Build many walls to cross, many gates to open,
| observe the user through each of these.
|
| lol op assumes passkeys or pw's are the only lock being used to
| protect things. Well from a security implementation
| standpoint...I assume someone either you on the rust end or
| someone on the yubikey end is already a weak link and your
| password is probably already compromised. But thats ok.
|
| TBH from a security standpoint, yeah I expect your PW to be
| correct, but I also do assume that its not secret. Its only part
| of the parcel. I expect about a dozen other metrics to be correct
| too pending on how secure you need your stuff or how important
| the security is. If you don't tick most of these if not all of
| these boxes. I don't care if your password or passkey is right.
| Your not getting in.
|
| The pincode>push button on yubikeys is part of this. Your IP,
| your device ID, your TPM trusted data paths, the time of day your
| trying to make access, the frequency of it, the country of
| origin, the target your trying to get into, the wifi you are
| accessing this via....are all part of this. Stop being so old
| school about security and propping it up off one point of
| failure.
|
| Now this bit is going to be the real hard biscuit to bite for
| alot of folks, but Yes I get that its harder in web because you
| probably don't have the physical end of things under enough
| control that you can use those for your security checks/metrics
| as they are under user control, but maybe don't store super piss
| off secret data that needs to stay secret in systems like that.
| If your web app gets to X level of personal data/could be
| involved in X level of harm to society or its users if breached.
| Don't let people sign up without mfa, hardware keys and so on.
| Force users to detail more info about their fixed locations and
| regular usage areas and judge their access security on that.
|
| tldr I dont care if your PW is compromised its 1/X keys needed. I
| assume its compromised. I dont assume all other X keys are tho.
| zaroth wrote:
| They really just can't get out of their own way in screwing this
| stuff up...
|
| Resident keys allow the browser to query the secure element for a
| list of usernames for a domain. It's a nice feature, but you have
| to setup the protocol to reliably fallback to non-resident keys
| on secure elements that are space constrained.
|
| But then they came up with these resident key "preferred" and
| "discouraged" keywords which are sent by the _site_?! And then
| the various clients all interpret them differently so there's no
| obvious way for a site to let clients with secure elements with
| practically unlimited storage to opt-in to resident keys while
| limited storage secure elements stick with the wrapped /derived
| key.
|
| The current situation is if you send "preferred" you'll fill up
| limited space YubiKeys, and if you send "discouraged" then
| Androids with practically unlimited storage won't use resident
| keys.
|
| Clients should decide based on their capabilities and should
| always opt for residency if they have unlimited storage. The
| protocol should have been defined with just a boolean 'required'
| field for residency, which would only be used in highly unusual
| circumstances (which I'm not sure what those are -- what's the
| justification for a site _requiring_ residency?)
|
| One day we'll get it right...
| cameldrv wrote:
| What I don't get is why can't the browser just maintain a list
| of accounts that it knows work with the non-resident key? The
| username is not secret information, so why does it need to be
| held in the key?
| drdaeman wrote:
| Because a key could be used with a brand new browser on an OS
| or machine that you've never used before.
|
| And the problem is that it's not usernames, they're IDs, not
| intended for humans, so manually typing those is not exactly
| a good idea.
| a-dub wrote:
| this is probably a dumb question, but why not just store a secret
| seed that is used with an on device prng to generate as many
| secrets as you need where a sequence id gets shared with the
| counterparty?
| kj4ips wrote:
| I'm pretty sure that is how non-resident keys work on some
| platforms (like the first gen yubico U2F tokens).
|
| The main feature of resident (aka discoverable) keys is that
| the RP doesn't need to know anything about which key is about
| to be used, so it can just say "send me an auth for
| example.com", and the browser and key handle the rest.
|
| However, with non-discoverable keys, the RP has to provide a
| reference to the key, which could actually have encrypted
| private key matter in it.
| wepple wrote:
| how does authn happen here?
|
| RP sends ID and I respond with the secret code? that's subject
| to replay attacks.
| kj4ips wrote:
| It's a challenge-response with nonces. There is also the
| browser's role to ensure that a given RP's requests are
| marked with the origin (domain) they came from, so
| auth.example.com and auth.example.evil don't overlap. (U2F is
| mostly concerned about malicious sites, and less about
| malicious browsers and other nastyware)
| matthewaveryusa wrote:
| Is this really how resident keys work? I thought the common use
| of all secure enclaves is to save keys outside the enclave, but
| symmetrically encrypted with a master key in the enclave,
| bypassing the memory limits. I can see the downside for
| yubikeys/usb enclaves being the keys are then no longer
| accessible, but for embedded enclaves this should never be a
| problem.
| nathants wrote:
| passkeys seem meh, but if they help fido2/webauthn spread then
| they are for great good.
|
| not your keys not your coins, except for passwords. the general
| public has been learning this for some time now due to endless
| crypto scams.
|
| plot twist, satoshi founded yubico!
| NotYourLawyer wrote:
| > The problem is that security keys with their finite storage and
| lack of credential management will fill up rapidly. In my
| password manager I have more than 150 stored passwords. If all of
| these were to become resident keys I would need to buy at least 5
| yubikeys to store all the accounts
|
| How it is possible that THIS is the problem in 2023? Storage is
| cheap, tiny, and capacious. I feel like I'm reading an article
| from 1992.
| goalieca wrote:
| A private key for curve p256 is 32-bytes. Let's say we have
| associated metadata (hostname, whatever) and round that up to
| 1KiB per key.
|
| A typical user has around 200 accounts but let's give room for
| 1000 since powerusers love hardware keys.
|
| That's 1000 x 1KiB = 1MiB. This is totally within our technical
| capabilities. It's not uncommon for small radio coprocessors to
| have more storage on die. Even old school SIM cards have 256KiB
| worth.
| kccqzy wrote:
| You aren't buying a USB mass storage device when buying a
| security key. Completely different product, different
| requirements.
| gtvwill wrote:
| No I'm buying a USB minimum storage device with a micro
| controller embedded and potted under some very hard plastics.
| Very much the same thing. Function different yes,
| manufacturing when it comes down to it. Exactly the same. I
| could print wafer for your security key, I could print wafer
| for your flash memory. IC's arent manufactured differently in
| security keys to normal IC's. The product is the same silicon
| just doped differently to make a different ic/circuit. its a
| small computer in a USB. it does a limited function. Stop
| making them out like they are some wizard stick fancy stuff.
| You can setup a ESP32 as a security key if you want.
| drdaeman wrote:
| > Stop making them out like they are some wizard stick
| fancy stuff
|
| But they are. Tamper resistance is a thing, and it's
| different from the engineering perspective. That's why
| Yubikey and FST-01 are entirely different beasts.
|
| Most folks probably don't need tamper resistant hardware,
| though. I mean, they've been doing fine with sticky notes
| on a monitor...
| gtvwill wrote:
| Most folks are better off with notebook in the table next
| to their bed/desk for passwords than anything else. Whens
| the last time you got broken into at home and someone
| stole your diary? Whens the last time you read about
| someone getting breached because they had their passwords
| written down in a book next to their desk? Pretty much
| never.
|
| Whens the last time someone got breached storing their PW
| somewhere digital? well shit probably a dozen happening
| every second and a few dozen breaches somewhere in the
| world before your done reading this.
| simultsop wrote:
| Everything comes at a cost. If a company has breaching issues to
| leak passkeys they will have bigger troubles. As many suggest the
| main problem this attempt of FIDO alliance tries to solve is
| "Passwordless accounts". Trusting passwords to password managers
| is a problem at raise. I guess this solution would mitigate
| password mess for next 10 years. Then by moving forward I believe
| tech sector would also be able to satisfy security guru's too,
| hopefully.
| elzbardico wrote:
| I think that 99% will use something they already have like an
| iphone, an Android phone, touch id on their mac books, or windows
| hello. Storage should not be a problem.
| dontupvoteme wrote:
| Why are organizations that aren't NIST trying to do anything
| fundamentally in cryptography?
| kj4ips wrote:
| This is more of a use of cryptography for authn, not designing
| the cryptosystem itself.
| Ajedi32 wrote:
| Is it even a good idea to use physical security keys as passkeys
| in the first place? Passkeys are meant to be a password
| _replacement_, and for that you probably want the 2-factor
| properties afforded by phones or desktops which usually require
| "something you know" or "something you are" to unlock in addition
| to the "something you have" afforded by physically possessing
| them.
|
| IMO physical security keys are better left as second-factor
| authentication, to be used _in addition_ to passkeys in certain
| high-security contexts; particularly where resistance to cloning
| is a critical feature. Resident keys aren't necessary for that
| use case since by the time you get to the second factor step you
| already know the account you're trying to log into.
|
| Further, the autocomplete functionality afforded by resident keys
| is important for the UX of passkeys in my opinion. I don't think
| it makes sense to sacrifice that in order to to retain backwards
| compatibility with a small number of keys that only security
| nerds use. (Though if there were a way to maintain that UX
| without using resident keys I'd be cool with that.)
| politelemon wrote:
| I don't see phones as being very different in terms of also
| being a physical security key.
| prophesi wrote:
| I think the key (pun not intended) differences are that
| phones are something you'll always have on your person,
| Apple/Google will allow it to sync across devices, and phones
| require a pin/biometrics to authenticate with them.
| caminante wrote:
| Have you not heard of "SIM swapping?" [0]
|
| The FBI (US) receives thousands of complaints, which I'm
| guessing means it's orders of magnitude more common.
|
| [0]https://blog.mozilla.org/en/privacy-security/mozilla-
| explain...
| giobox wrote:
| Using phones as physical security keys != using SMS for
| 2FA.
| jrk wrote:
| SIM swapping lets you take over a _phone number_. It does
| not let you clone the keys stored in your physical
| phone's secure storage / enclave / key storage.
|
| So SIM swapping makes SMS verification vulnerable (that
| just depends on controlling the phone number), but
| doesn't fundamentally affect iPhone/Android passkeys.
| naikrovek wrote:
| sim swapping doesn't move the authenticator app to the
| attackers phone, only your phone number.
|
| this is why SMS-based 2nd factor has been considered
| insecure for years.
| zb3 wrote:
| There are two separate problems - the first one is to
| make sure others don't have the access you don't want
| them to, while the other is to make sure that you/others
| have the authorized access.
|
| SIM swapping means someone else might be able to have my
| phone number, but I'll eventually get this number back
| via legal means. So the number itself is something I own
| (at least in my country). Now if a site assumed this and
| phone numbers were meant to be constant, it'd mean I
| could always get my account back.
|
| But of course this depends on which problem I consider
| more important. It's better to lose access to my FB
| account forever than to allow someone to gain access to
| it for a moment, because that might cause harm.
| Similarily, it's better to lose access to my bank account
| until I have to visit them in person than to lose all the
| money, but in this case the weakest link is probably not
| the key itself.
| fatfingerd wrote:
| I'm quite concerned that phone numbers I don't own or
| addresses I no longer live at have legal "owners" and
| their friends/sublets who could decide to impersonate me
| with accounts that still have these old details, and its
| kind of hard to separate that from my new details having
| been the illegitimate hack.
|
| I think most people wouldn't risk that unless they are
| pretty messed up and an average legal system to deal with
| that unless it is pretty messed up. A past residence in a
| mediocre city in the US provides all the crack heads
| needed for such a torturous comedy.
| gleenn wrote:
| FWIW, some Yubikeys require a pin as mentioned elsewhere
| and some more expensive ones even have biometric
| fingerprint readers on the key.
| jrozner wrote:
| When using a resident/discoverable credential the authenticator
| is supposed to authenticate the user (using a pin, biometrics,
| etc.) This fulfills the multi-factor requirement. All
| passkeys/webauthn credentials are something you have and you
| can use a something to know/something to are to unlock the
| credential stored on the authenticator.
| drdaeman wrote:
| Until there is something like pre-registration ("here are all
| my keys from all my devices, trust them all" - not possible
| with current standards) mechanism - I suppose, yes?
|
| I don't really understand if there's any other way to make all
| this work if not for portable authenticators. How one is
| supposed to log in from a different machine if it's from a
| different ecosystem that doesn't have the original passkey
| (e.g. log in on an iPhone if I've signed up from a non-Apple
| desktop computer)?
| newhouseb wrote:
| I've been trying to wrap my head around this and my layman
| understanding is that there's an assumption (but maybe not
| baked into any requirements/standard) that use of the hardware
| key is locked behind either a biometric check
| (FaceID/TouchID/etc) or password. In other words, there might
| be an implicit second factor baked in to the passkey itself.
| mrtksn wrote:
| If you think about it, the core problem can be described as
| "authentication of the biological being with an electronic
| system".
|
| When passwords are used, the authentication interface is a
| keyboard and you don't have any actual guarantees that the
| person typing the password is the person who claims to be. The
| passwords could have been extracted in so many ways because it
| depends on easily transferable knowledge.
|
| Moving the authentication interface to device2device is
| actually much better, you no longer assume that the easily
| transferable knowledge was not transferred. Instead, you assume
| that the biological being is capable of keeping track of the
| authentication device and people are naturally good at it.
|
| You can increase the number of authentication channels to
| tighten it up a bit, you can restrict the authentication of the
| biological being with the device(FaceID) which will be used for
| authentication with remote systems but at the core I think it
| feels right to assume device(phone, key etc.) means the person.
|
| It's also quite a human thing to do. At home, we share not only
| the Netflix password but one of the credit cards. For practical
| reason, one credit card stays with the spare keys and when
| there's something to buy for the house anyone can grab that
| card and use it. We trust each other that the card would be
| used properly, everyone knows the pin code but that's rarely
| needed since contactless payment is the norm anyway. It's much
| more natural than keeping track of the expenses and then pay
| each other the outstanding amounts. However, It's probably
| illegal and if the bank finds out about it, they will cancel
| the card.
|
| IMHO, the IT systems desperately need to approach human
| behaviour by working in analogous ways with the real world.
| Since I'm involved with IT systems I don't struggle most of the
| time but people who are not that tech savvy are having hard
| time figuring out daily stuff like What is the iPhone's
| password for, What is the iCloud password for, what is the
| Gmail password for, why I need to enter a code in WhatsApp etc.
|
| Actually, I think I struggle too - I never came along to
| understand Mastadon. I'm prbably defenceless against phishing
| attacks on Mastadon, I will type whatever the screen tells me
| to type.
| JohnFen wrote:
| > it's probably illegal and if the bank finds out about it,
| they will cancel the card.
|
| In the US, anyway, this isn't illegal unless you have to sign
| something and sign someone else's name. So just sign your own
| (nobody actually checks signatures).
|
| It might be against the CC issuer's terms of service, of
| course, but that's a whole lot different from being illegal.
| paulddraper wrote:
| > Instead, you assume that the biological being is capable of
| keeping track of the authentication device and people are
| naturally good at it
|
| That seems a dubious assumption.
|
| It's far more often that debit/credit cards are physically
| lost/stolen than digitally lost/stolen.
|
| (The only thing preventing cards from being a massive day-to-
| day issue are very aggressive fraud-detection systems and
| financial controls.)
| mrtksn wrote:
| Is that true though? AFAIK they sell CC info for pennies.
|
| The good thing about the physical device is that you can
| easily tell if it's stolen.
|
| For passwords, there are numerous services that keep track
| of the leaks and even Apple has incorporated that into
| their password manager but it all depends on mass leaks to
| work.
| ryandrake wrote:
| > IMHO, the IT systems desperately need to approach human
| behaviour by working in analogous ways with the real world.
| Since I'm involved with IT systems I don't struggle most of
| the time but people who are not that tech savvy are having
| hard time figuring out daily stuff
|
| I'm pretty much the website key master for everyone in my
| family. Since nobody else is "in computers" they really don't
| have a clue about what things need passwords and why. They
| would NEVER voluntarily complicate their lives with 2FA or
| even with a password manager. If it wasn't for me, they'd
| just use "hunter2" and share it across every single device
| and service they use. If I told them they couldn't just type
| in their Netflix password when Gmail was asking for a
| password, they would just look at me exasperated, like I was
| making their lives difficult.
|
| The security community really needs to get a grip and start
| designing systems that are compatible with the extremely low-
| tech-interest population if we even have a hope of securing
| systems. If I knew what the solution was I'd be rich.
| cbsmith wrote:
| > The security community really needs to get a grip and
| start designing systems that are compatible with the
| extremely low-tech-interest population if we even have a
| hope of securing systems. If I knew what the solution was
| I'd be rich.
|
| Most of that population seems to do fine managing house
| keys, car keys, locker keys, etc.
| bmurphy1976 wrote:
| You sure about that? I inherited what feels like 1,000
| keys when my in-laws passed away. Who the hell knows what
| any of them are for, and they sure as hell didn't.
| ekianjo wrote:
| True but online accounts are usually in the dozens for
| most people so thats definitely more of a burden. Also,
| its a mental load while physical keys carry the
| "password" physically.
| bombolo wrote:
| Maybe the netflix password isn't so vital?
| thaumasiotes wrote:
| > Instead, you assume that the biological being is capable of
| keeping track of the authentication device and people are
| naturally good at it.
|
| This is not something that people are good at.
| mrtksn wrote:
| Why do you think that?
| thaumasiotes wrote:
| I have some experience with people trying to keep track
| of objects.
| mrtksn wrote:
| Can you describe your experience? I know what you mean
| but if you describe it, I think we will be able to
| examine the implications.
| thaumasiotes wrote:
| All of the following are routine. We will name our
| example person "Bob".
|
| 1. Bob owns an important item. He believes that he knows
| where it is. He is wrong.
|
| 2. Bob owns an important item. He is well aware that he
| has no idea where it is.
|
| 3. Bob owns an important item. He knows where it is. He
| is right about where it is. Unbeknownst to Bob, other
| people frequently borrow or otherwise meddle with his
| item.
|
| 4. Bob has taken his important item with him, for
| security. Unbeknownst to Bob, it fell out of his pocket
| an hour ago.
|
| 5. Bob used to own an important item. When he cleaned his
| house, he confused it with a different, unimportant item,
| and he threw it away.
| aseipp wrote:
| Yeah, this is basically my take. At this point, the idea
| everyone is converged on is that you have a locally encrypted
| secure "vault" of some kind, that you can trust, and you need
| to verify identity with _that_ system, perhaps with a password
| and perhaps with a key. It is easier to have some trust that
| your password manager of choice is more secure, rather than
| having to assume that every service in existence you create an
| account for is secure (or unphishable.) So, by the time you use
| a passkey, you 're quite often in a more secure context where
| you've already established that identity: to your operating
| system, to your password manager that owns your passkeys, etc.
|
| It also seems likely that places that didn't support hardware
| keys now or recently probably wouldn't have supported them in
| the near future. But the ROI for a Passkey solution is likely
| much higher since the buy in (just some software support) is
| much easier for people to achieve. Of course, this is only true
| for websites mainly; a Passkey is basically the equivalent of
| "Standardized SSH keys" for a website.
|
| I see hardware keys as more useful for second factors like
| actually _unlocking_ your vault with your passkeys inside of
| it, which might also want a password. I suspect hardware keys
| still have a bit of life left in them.
|
| The Passkey login flow is actually super, super nice now that I
| can use it on GitHub, Gmail, etc as a primary method.
| katbyte wrote:
| i think they could be great for websites i don't really care
| about and already use weaker passwords. but for important sites
| where security matters? nope
| aseipp wrote:
| Passkeys are unphishable and can't meaningfully leak
| credentials in the case of a hack, nor can they be reused by
| design. For "important sites where security matters" they are
| literally better in _every_ way than a password, it doesn 't
| matter how weak or strong. You can use a pure software
| solution, and soon probably even your existing password
| manager, to handle them. Again, you should think of them as
| replacing passwords. You can still enforce post-
| authentication requirements like SMS or calls to known
| numbers, bank account deposits, magic follow-up links in a
| confirmed email, push notifications, etc.
|
| SSH keys are the best analogy. "SSH keys are great for
| useless servers, but for important servers? no way!" No!
| That's exactly where SSH keys are most useful. And you also
| happen to encrypt your SSH keys _locally with a password_ ,
| don't you? This is the exact same principle, but applied to
| arbitrary websites. Nobody goes around randomly generating
| login passwords for SSH'ing into each and every server they
| use, and then pats themselves on the back.
| Eduard wrote:
| > Passkeys are unphishable and can't meaningfully leak
| credentials in the case of a hack, nor can they be reused
| by design.
|
| Let's assume a "passkey device emulator" written in
| software; quite realistic IMHO for someone to use,
| considering the cost of hardware authentication devices
| (phones, YubiKey etc.)
|
| If someone using such emulator gets hacked and has their
| passkey emulator data stolen, is there anything preventing
| a credential leak?
| aseipp wrote:
| The software you're describing is called a "Password
| Manager", and several do support passkeys already in
| newer versions. There's no real "emulation." 1Password 8
| supports them just fine, your browser has APIs so third-
| party software can integrate exactly for that. So, the
| answer to your question is pretty much "exactly the same
| scenario as your password manager getting leaked", which
| is basically unsurprising and already well understood
| when you frame it this way, I think.
|
| The particular case I was referring to (and probably
| should have been clearer about) was when a _website
| operator_ gets hacked; in that case the only information
| an attacker gains from your user account is a public key,
| which isn 't of much use. But like, that's actually a
| major issue in practice, because the value of hacking a
| service operator is often far greater than just one user.
| That exact scenario was one of the motivations for using
| password managers in the first place, too, to mitigate
| operators getting hacked and common passwords getting
| reused between users, thus turning a single compromise
| for many users into _multiple_ compromises for many
| users. So, it all has come full circle in a sense; now we
| 've finally recognized that instead than shoehorning
| passwords into becoming psuedo-random strings that might
| as well be base64 encoded bytes from /dev/urandom, you
| might as well go "all the way" and just get those raw
| bytes from /dev/urandom directly and then use them as key
| material for a public key exchange.
|
| Again, the best analogy is to just imagine that you used
| SSH keys to log into a website. That's all this is. It's
| software. Then you remember: oh yeah, SSH key
| synchronization and enrollment across machines sucks ass,
| and normal people would hate doing it. Hey, you know
| what, we already use passwords to encrypt SSH keys -- so
| what if we added a storage synchronization layer between
| your machines to keep those SSH private keys
| synchronized, encrypted with that password, and stored
| using $FAVORITE_SERVICE_PROVIDER? That's pretty much it,
| in a nutshell. You just reinvented modern Passkeys. Most
| of the threat models at that point are well understood:
| what service provider or software to choose, how secure
| is the local encryption, should you use two-factor
| authentication to further improve unlock safety, etc.
| autoexec wrote:
| > when a website operator gets hacked; in that case the
| only information an attacker gains from your user account
| is a public key, which isn't of much use.
|
| How is that different from situations where a website
| gets hacked and all the attacker gets is a well-hashed
| version of a unique password? In either case it isn't
| doing the attacker any good.
| katbyte wrote:
| for my important accounts the password is long, unique, and
| not recorded anywhere, that is one way that passkeys are
| not better. there is literally no credentials to leak until
| i go login and type it where passkeys are recorded
| somewhere? otherwise how would they work. someone gets my
| private SSH key that is a bad time (which is why we
| password protect them, or at least you really should be)
|
| to follow the ssh analogy, you (should) only use SSH keys
| to gain access to a unprivileged user account at which
| point you elevate permissions via sudo and another factor
| (password/MFA) and really theres an argument to be made the
| unprivileged account should have MFA for login as well.
|
| nobody puts their ssh public key in the root account of a
| server and pats them selves on the back that its secure so
| why would passkeys be any different for accounts you truly
| need to be secure?
| aseipp wrote:
| You seem to be making up a bunch of scenarios that aren't
| really relevant (what if someone did this and that with
| sudo, what if the bytes were stored here). You don't want
| to understand the actual security model, which is fine,
| but only on Hacker News can someone say with confidence
| "actually unphishable public keys that can't be leaked,
| are not good for security." Again, you might as well be
| arguing against SSH keys. That won't get topped for a
| while.
| someplaceguy wrote:
| I understood the parent poster to be saying that since
| his passwords are unique and are not stored anywhere,
| then if his device were to be compromised, the attacker
| could only steal a password once it is manually entered,
| in which case it wouldn't automatically compromise his
| other passwords.
|
| Conversely, if he were to use a password manager on his
| device to store passkeys, the attacker could compromise
| all his passkeys once one of them is used.
|
| Admittedly, it is an unusual use case (I mean, how do you
| generate and remember unique, sufficiently long and
| random passwords without storing them anywhere?) but I
| can see how passkeys could be worse for him if this is
| really what he does.
| jrockway wrote:
| I'm not sure that a second factor was ever the goal of 2FA, but
| rather the desire was a key that users couldn't pick themselves
| (because they use their birthday, they tell example.com their
| Google password every time they log in, etc.)
|
| That said, I don't feel great about letting security keys be
| the only factor. They can be stolen. So can phones, but phones
| make you unlock them before they'll be your password. (Windows
| Hello is the same thing.) That seems like the right balance to
| me. Your phone can authenticate that you are you; a USB dongle
| can't.
| the_snooze wrote:
| When I use a Yubikey for passwordless authentication (FIDO2),
| it challenges me for a PIN before asking me to touch the
| device. If I give it too many incorrect PINs, the Yubikey locks
| up and requires a device reset, which invalidates all previous
| registrations to use that key for authentication. It doesn't
| seem like a big deal if someone steals my hardware token.
|
| https://support.yubico.com/hc/en-us/articles/4402836718866-U...
| e40 wrote:
| That's not how my YK works. When I go to a new computer and
| login to my Google account, it asks me to insert it and press
| the button. Did I configure it wrong?
| jsmith99 wrote:
| It's optional and can be required by the service. Services
| like Microsoft that use security keys as a single factor
| rather than as a MFA are more likely to require it.
| ilikepi wrote:
| Are you sure you have a YubiKey (e.g. a "5 Series"[1]) and
| not a YubiCo "Security Key"[2]? The latter is a less
| expensive device with less functionality[3], though still
| good for arguably the most common 2FA situations.
|
| [1]: https://www.yubico.com/products/yubikey-5-overview/
|
| [2]: https://www.yubico.com/products/security-key/
|
| [3]: https://www.yubico.com/store/compare/
| NoZebra120vClip wrote:
| The Security Key models have an access PIN just the same.
| yata69420 wrote:
| Yes, you need to use `ykman` to set a PIN. This also allows
| some services (really only Microsoft Accounts right now) to
| use "passwordless".
|
| The idea is you register 2 or 3 passwordless keys on
| important accounts. Keep one in the machine, one on your
| physical keychain, and one in a remote location.
| hntway123 wrote:
| Something I noticed after reading this thread is that
| Google basically converted my YK from a 2FA security key to
| a Passkey. I'm so confused.
| the_snooze wrote:
| If you're only using it for two-factor authentication, you
| don't need a PIN. But when I tried to registered mine as a
| passkey (passwordless authentication), my browser prompted
| me for a PIN. I didn't have one set at the time, so it kept
| rejecting whatever PIN I gave it. I had to use the YubiKey
| Manager to set a PIN before I could register it as a a
| passkey.
|
| https://www.yubico.com/support/download/yubikey-manager/
| warp wrote:
| You can also manage this from within Chrome (Privacy and
| security -> Security -> Manage security keys).
| jauntywundrkind wrote:
| It means though that your secure hardware token has a
| reliable way where the secrets all self-destruct. That
| someone can easily do if they get even brief hardware access.
| For people who have a problem keeping sufficient backups
| (almost everyone on earth) this seems like a horrific
| blocker, a show stopper for this entire intiative.
|
| I personally think these things absolutely should be able to
| be exported & backed up separately. Many people guffaw that
| now the device isn't secure. But I just don't think I could
| realistically adopt nor do I expect others will unless users
| get some better affordances, unless we get some capability to
| manage trust as we see fit, not just be pushed top down into
| someone else's desired much narrower security behavior.
|
| (Thankfully it seems like there is building interest in
| exports & portability, particularly as the OS/browser powered
| PassKeys arrives.)
| Arch-TK wrote:
| You can import onto a yubikey. At least the GPG keys which
| is basicly all I use it for.
| wkat4242 wrote:
| GPG yes. Fido no.
| etothepii wrote:
| I struggle with this on a lot of 2FA. I change my phone
| every 1 or 2 years when I get an upgrade and the 6 months
| after I end up having to keep my old phone around to handle
| the 2FA apps that can't be ported over, it is incredibly
| annoying.
|
| For me allowing a weak 2FA that moves you from the pool of
| people that can be trawled to the people that need to be
| specifically targeted is a huge improvement, but my fear of
| losing access to critical systems because I lose my phone
| fills me with dread.
| stephenr wrote:
| Your 2FA app of choice doesn't support export/import?
| saint_yossarian wrote:
| I use Aegis Authenticator on Android which does encrypted
| cloud backups, so changing phones isn't much of a
| problem.
|
| I also only keep critical accounts there, the rest goes
| into Bitwarden. I realize this isn't as secure, but with
| those accounts I wouldn't even bother with 2FA otherwise.
| JohnFen wrote:
| > I personally think these things absolutely should be able
| to be exported & backed up separately.
|
| I agree. The usual response is that you don't need to do
| this because you can have multiple hardware keys that
| authenticate to the same services, so you can store one as
| a backup.
|
| But managing that sounds like a real pain in the butt to me
| (honestly, the entire passkey system sounds like a real
| pain in the butt to me -- but that bit particularly so).
|
| But it looks like the major companies recognize that this
| is an issue and won't be requiring that part.
| jauntywundrkind wrote:
| It'd be awesome if you could ask to enroll a variety of
| other devices all at once, without having them on hand.
|
| Requiring ongoing physical access to your crucial backups
| to do any account enrollment or changes seems like a way
| to make sure you have your crucial backup way too close
| to potential disasters. Ideally I wanty backup keys many
| states away from me. But then I can enroll them!
|
| But it feels like there could be some kind of pubkey for
| those keys that I could also enroll at the same time as
| I'm getting my first device.
|
| Except these devices don't have just one pubkey cause
| that wouldn't be secure. Maybe they pre-make & share 20
| keys with a peer device or something. Somehow though data
| needs to at the end be able to get into the backup/other
| device too though. Ugh it's wild.
| JohnFen wrote:
| That would certainly be very convenient, but it would
| also retain/reintroduce several of the security
| weaknesses that passkeys are intended to mitigate.
|
| The reality is that security is really, really hard. And
| it remains as true as ever that increased security comes
| at the cost of decreased convenience.
|
| My personal attitude is that I make different
| security/convenience tradeoffs for different things. I do
| have and use hardware keys for very sensitive things. But
| they're rather inconvenient, so I don't use them for most
| authentication purposes. Does my account here on HN
| really need to have the best possible security? No, it
| doesn't.
|
| So, in my opinion, both passkeys and the traditional
| username/password mechanism should be supported for most
| of the web. Which is likely how it's going to be for a
| long time.
| aidenn0 wrote:
| If someone hits my cell-phone with a hammer a few times, it
| will probably self-destruct all the secrets.
| bombolo wrote:
| Quite unlikely.
| wkat4242 wrote:
| > Passkeys are meant to be a password _replacement_, and for
| that you probably want the 2-factor properties afforded by
| phones or desktops which usually require "something you know"
| or "something you are" to unlock in addition to the "something
| you have" afforded by physically possessing them
|
| Yes because the keys have a PIN just for this usecase. Similar
| to the ATM card or SIM card you already know
| bandrami wrote:
| The difference between zero and one factor is infinite. The
| difference between one and two factors is huge. The difference
| between two and three is almost negligible. Except in Citrix-like
| situations where you're sharing the actual reader hardware,
| passkeys are only useful for a device you have physical access
| to, and that's already one factor. So in that sense they can
| replace passwords, I guess, but they seem like a strictly worse
| solution.
| zb3 wrote:
| Any form of authentication based on "something you have, but can
| also lose" is fundamentally broken. Either I'll lose access if I
| lose the device, or their superior security doesn't matter
| because the weakest link has to be somewhere else.
| upofadown wrote:
| This raises a question for me. Why are hardware keys so limited
| in storage? How much extra would it cost to have a secure
| processor that could access a mass storage device also built in
| to the key. This mass storage device would of course be strongly
| encrypted by the secure processor with a key that would be erased
| at the same time everything else is erased.
| dathinab wrote:
| Because secure tamper resistend storage is expensive.
|
| I would even go as far and say from a security POV the best
| security key is the key which has 0 storage. Because in my
| experience any protocol which injects and stores a secure token
| into a security key/enclave/whatever instead of deriving it
| from shared secrets etc. has serious flaws. Sometimes it's
| fundamentally security flaws (like TOTP). Sometimes it's
| complexity flaws. Similar you don't really EVER want to share a
| secure key for HSK/2FA across multiple devices. It means if one
| device leaks it it's corrupted for all of them. Instead you
| want a separate key (oversimplified) on _each_ device. Login
| provider/server side wise the overhead for this is negligible
| in the bigger picture.
| qzio wrote:
| I believe tillitis tkey lack storage, might be of interest?
| https://tillitis.se/
| shawnz wrote:
| Why not just store the master key in the tamper resistant
| storage and then have some regular old consumer grade storage
| to store all the derived keys?
| dandanua wrote:
| This allows to copy derived keys easily, which ruins the
| purpose of the whole security key idea.
| rcxdude wrote:
| only if the master key can be extracted (assuming the
| keys are encrypted by such)
| westmeal wrote:
| What do you mean by fundamental security flaws with totp?
| radicaldreamer wrote:
| I think this is a conscious design choice made to keep these
| devices as "dumb" as possible. As soon as you add storage, you
| start opening up the same surface for vulnerabilities as any
| other storage device, next comes compute and eventually you
| have a full fledged computer instead of a dumb yubikey.
| morelisp wrote:
| I don't know if this is the only reason, but mass storage
| devices seem to have a ludicrously unacceptably high failure
| rate and short lifetime to be something I key large potions of
| my life to.
| gruez wrote:
| Usb drives have ludicrously high failure rates because
| they're optimized for cost rather than reliability. Other
| forms of flash memory (eg SSDs) are quite reliable, despite
| having much more flash chips (and thus points of failure).
| taeric wrote:
| I'm sure they can go up in storage, but the more you add to
| them the more you increase the chances of fault. And these
| things currently take a hell of a beating before they don't
| work anymore.
|
| There is also something a bit more auditable about a smaller
| storage. Though, even the small sizes are probably pushing the
| bounds of what can realistically be audited nowadays.
| matthewaveryusa wrote:
| It's less that they are limited in memory, and more so that
| they are designed to not have memory limits.
|
| If you look at TPMs, basically each time you want to sign
| something, your input is the data you want to sign and a sealed
| private key. The sealed key is the private key that was
| generated by the TPM and then symmetrically encrypted with the
| key embedded in the TPM. You store the sealed key in your mass
| storage, and provide it to the TPM for each signing operation.
| This design allows you to have as many keys as your mass
| storage will allow you to save.
| deathanatos wrote:
| What you're talking about seems to be what the article would
| call a "non-resident" key, whereas this commenter is
| specifically asking about "resident" keys.
|
| Or, if you think you are describing resident keys, then you
| need to reconcile,
|
| > _This design allows you to have as many keys as your mass
| storage will allow you to save._
|
| with the OP: the article states that to be roughly "20", and
| people tend to have more than 20 logins, and that is the
| reason the person you're responding to is asking the question
| they're asking.
| matthewaveryusa wrote:
| What I'm saying is if you look at the sequence diagram for
| the resident key, at step 3 there's no requirement to have
| the keys stored in the security key: you can save an Rp to
| token mapping in the client outside and it's still
| considered a resident key.
|
| I think what I'm saying here is that resident means
| resident to the client, not necessarily resident to the
| enclave. I took a peek at the spec and they define resident
| keys as being part of the "client platform" which they take
| care to clarify as "A single hardware device MAY be part of
| multiple distinct client platforms"
| https://www.w3.org/TR/webauthn-2/#client-platform
| [deleted]
| dcow wrote:
| I think the author is taking the argument too far and also not
| being precise in their language which is the exactly the "passkey
| hype" they fault Apple and "Fido" for doing. Maybe just cut the
| exposition out of the article I don't think it helps the argument
| and makes the author sound angsty rather than contribute to the
| well thought out considerations towards the end. Point being, I
| think there's a point but it was hard to get there.
|
| Anyway:
|
| 1. _Passkeys_ , to me, are the private key. It doesn't matter
| whether it's resident or not, or whether it's device bound (non-
| extractable) or not, whether a "genuine" authenticator made the
| signature or not, or whether user presence was verified or not. A
| Passkey is _not_ the authenticator /library as the author claims,
| and it's not the protocol or some set of protocol features.
|
| 2. The world is better off if everyone uses WebAuthN instead of
| passwords irrespective of how the passkey is stored. Full stop.
| So let's start there. Additionally, where I diverge from the
| author, I don't think preserving the sanctity of decade old
| hardware keys which only conform to older versions of a TPM spec
| is of paramount concern, either. The author's fixation on that is
| a little strong, but it's understandable.
|
| 3. I don't think you need to discourage resident keys. But I also
| don't think RPs need to care about whether the key is resident or
| not. Let the library on the user's browser/device decide how to
| find the key. An RP wanting to verify user presence is one thing,
| but saying this key must be stored with the user IMO _is_ a step
| too far. It 's likely that RPs don't even care and are just
| avoiding wanting to store some extra bytes in their DB. Or their
| security team overly cares and is making up reasons why the RP
| needs to require resident keys (IMO bad security take all things
| considered) but I can see the tin-foil angle).
|
| So I think the simple solution is probably to, for WebAuthN
| specifically, deprecate the ability for the RP to specify that it
| needs a resident key. Problem solved.
|
| Oh and while we're at it, forbid hardware attestation. The _web_
| doesn 't need that. If rk=required and hardware attestation need
| to exist for tightly controlled enterprise use cases then
| whatever, but relegate them there preferably in some non-required
| protocol extension.
| dathinab wrote:
| no not far enough
|
| residual keys are IMHO a security misdesign and shouldn't exist
|
| but now the industry hype is pushing to make the the de-facto
| mandatory way
| dcow wrote:
| I'm not clear on what you mean by this. Do you mean hardware-
| backed non-extractable resident keys? Or the more simple idea
| that your WebAuthN agent can store a key?
|
| I don't see a problem with a WebAuthN agent storing a key
| (ideally locally encrypted at rest with a hardware resident
| key from a user or device TPM). Having users have a passkey
| database that they sync across devices is not really a
| problem as far as I can tell. Do you feel like that's a
| problem?
| rcxdude wrote:
| It's suboptimal: it basically creates the same situation as
| password managers where compromising that database is game
| over. It's a much better situation if instead you enroll
| multiple different keys. The main issue is if you want to
| automate this you need a standard way to enroll one device
| on all sites another device is enrolled in, which AFAIK
| doesn't exist. (you'd also want to have an automated way to
| revoke another device in the case that it is compromised).
|
| Having multiple keys enrolled would also allow for better
| recovery from websites in the case of a suspected
| compromised device: they can simply disable one key,
| allowing another key to still log in (and either vouch for
| or disable the other). You could also have flows where
| certain actions require multiple keys for authentication.
| dcow wrote:
| > it basically creates the same situation as password
| managers where compromising that database is game over.
|
| So your solution is to split the DB up and store it
| encrypted, using the same key, on each services servers?
| I'm dubious that does anything for your case (not to be
| confused with me agreeing that it's totally okay to have
| non-resident keys).
|
| You can only compromise the encrypted passkey DB if you
| compromise the hardware key, or by brute force. If the DB
| is encrypted at rest using a hardware key, the security
| model is essentially isomorphic to that of storing
| encrypted keys on a server. You're just playing with
| where the key sits at rest. It's still ultimately
| encrypted by a device's hardware resident key (assuming a
| sane "soft" WebAuthN implementation by the PW manager).
|
| Unless I misunderstand you, I think you're letting the
| perfect be the enemy of the good.
|
| EDIT: I think I misunderstood you. It appears you're
| arguing _for_ resident keys. The person I 'm responding
| to is arguing _against_ resident keys (and I 'm asking
| why they think it's a security mistake) so your response
| doesn't really make sense.
|
| I understand that technically in a raw security sense
| it's better for a user to enroll multiple devices with HW
| resident keys that never leave the authenticator/TPM
| hardware.
|
| The argument these days is more about what's an
| acceptable compromise that will get people to actually
| use Passkeys, because users carrying HW keys around is
| obviously a failed solution.
|
| Encrypting a soft DB of Passkeys at rest with a user-
| bound key, and encrypting that user-bound key at rest
| with a device-bound resident key, and syncing that DB and
| user-bound key between devices seems like an acceptable
| compromise that's effectively isomorphic to resident keys
| everywhere.
| spiznnx wrote:
| I see a lot of comments mentioning "residual keys". Is that the
| same as the "resident keys" the article talks about?
| danieldk wrote:
| _Since Apple didn 't actually define it, this left a void for our
| thought leaders to answer that question for users hungry to know
| "what indeed is a passkey?"._
|
| I have always understood that Apple defined a Passkey to be a key
| pair that is synced through iCloud Keychain. Even their WWDC 2021
| presentation distinguishes passkeys to be different than security
| keys because they are "always with you" (the device sync aspect)
| and "recoverable". I think the definition was later extended to
| other cloud sync methods.
|
| I also think the article makes the wrong trade-offs. Security
| keys are not important [1]. They are only used by a negligible
| number of technical users and a small number of companies that
| really care about security. Getting people off passwords is
| necessary for improving web safety and 99% of the population is
| never going to use security keys unless they are forced to.
| Passkeys do have a good chance of getting people off passwords,
| especially with deep OS integration. We shouldn't optimize
| authentication for that 1% or less because they'd be running out
| of resident key slots.
|
| [1] I am the owner of 3 Yubikeys, 3 Yubico security keys and a
| SoloKey.
| dathinab wrote:
| > rk=required
|
| why does that even exist, that shouldn't be an option
|
| this stuff is why I have been so worried/skeptical about Passkeys
| and the people related to it.
|
| They have the responsibility to design their protocols to not be
| a tool well suited for big coperations like Microsoft to
| seriously mess up security, compatibility and enact all kinds of
| "bad faith" market practices to kill competition.
|
| But instead again and again in their posts what they write,
| publish and explicitly how they do it is more like "fuck you, we
| make abuse extra easy".
|
| It's not just this nonsense about residual keys, but also e.g.
| how attestation is handled (and can be trivially abused to kill
| companies).
| ballenf wrote:
| > how attestation is handled (and can be trivially abused to
| kill companies)
|
| What's this issue?
| marwatk wrote:
| Hardware tokens (Yubikeys, etc) are signed by their vendor.
| They support attestation which allows q site to disallow
| vendors not in a white list. Some banks (Vanguard was/is one)
| actually enforce this preventing all but a handful of
| hardware keys from working with their 2FA.
| Vecr wrote:
| In the limited set of attestors anyone would use/accept, no
| one would attest for you. It could target clients, services,
| or both.
| jabbany wrote:
| I think this is not as bad as attestation abuses.
|
| My guess of what will happen is if a service sets `rk=required`
| and you are on a platform that doesn't want to (or can't)
| enable/support it, the process would always fail and you
| wouldn't even be able to register. Which seems like a shoot-
| yourself-in-the-foot kind of move if the goal is to onboard
| users and get more business...
| runiq wrote:
| I'm pretty sure the goal here is to turn your phone into your
| passkey, _and nothing else_. Everything written in that article
| makes sense if you keep that in mind.
| danieldk wrote:
| Apple opened up OS integration for other applications.
| 1Password is currently doing beta testing of their Passkey
| implementation.
|
| Besides that, the whole idea of Passkey (in contrast to what
| this blog claims) was that the key material can be synced
| between devices, so I am not sure how only the phone would be
| 'a passkey'. iCloud Keychain syncs my Passkeys between all my
| devices, including to my MacBooks.
| jabbany wrote:
| The problem with cloud-sync-based managers like the iCloud
| Keychain is bootstrapping. Since you need to be able to log
| in to the services themselves to provision access to the
| passwords.
|
| This makes travelling a bit risky, since it's not that hard
| to lose/break/have your devices stolen during a random
| trip. This makes it immensely hard to recover, since you
| cannot just hop onto a public terminal and authenticate
| (which might involve entering 2FA codes etc that you cannot
| get anymore).
|
| This is why physical tokens are still quite useful. They're
| rather unattractive to thieves, don't require its own
| Internet connection to work, and they're relatively small
| and cheap so you can get a bunch them to stuff in various
| places increasing your chances of having one still
| available to you.
| thrashh wrote:
| Knowing ahead of that problem, you can plan a solution
| though? Everything I have is cloud-synced and even if I
| lose my phone right now in a random country, I definitely
| know how I can recover all my 2FA tokens and logins from
| a random terminal (or preferably a new boxed phone) -- I
| DO have to remember some passcodes which I otherwise
| never use but that's not too hard.
|
| If Google or Apple implements this, they can design a
| solution too.
| jabbany wrote:
| > I DO have to remember some passcodes which I otherwise
| never use but that's not too hard.
|
| Right, but you're giving up a lot of security to do this,
| since it implies with these rare passcodes someone else
| could also bootstrap your logins.
|
| With HW tokens, you don't have to worry about recovery
| passcodes being leaked/hacked (the recommended procedure
| today is to print out the recovery codes and destroy
| digital copies).
| katbyte wrote:
| are there many places that use passkey yet? i've not
| encountered one, or rather not seen a place to make use of
| it
| tiltowait wrote:
| This website has a list of sites allegedly supporting
| passkeys: https://passkeys.directory
|
| I say "allegedly", because a few of them (Paypal, eBay, a
| couple others) have never once offered to let me use a
| passkey.
|
| Sites I know, off the top of my head (because I used them
| in the past 24 hours):
|
| * Porkbun
|
| * Google
|
| * GitHub (if you enable the preview feature)
|
| I know I've used more, but I don't have an easy way of
| searching for them.
| dcow wrote:
| eBay and Paypal do, though I don't know how to get it to
| prompt you to configure a passkey...
| donmcronald wrote:
| That's exactly what's happening. Is it really shocking that a
| collaborative standard is designed to benefit the entrenched
| big tech companies at the expense of users and would be
| competitors? Funny how the standards never "accidentally"
| favor the user.
|
| > This leaves few authenticator types which will work
| properly in this passkey world. Apples own passkeys, Android
| passkeys, password managers that support webauthn, Windows
| with TPM 2.0, and Chromium based browsers on MacOS (because
| of how they use the touchid as a TPM).
|
| All of those platforms, with the exception of password
| managers (which will be forbidden by the vendor lists), also
| have the compute needed to evolve the system into authorized
| actions that, IMHO, will eventually lead to devices where
| specific actions within apps are allowed / disallowed and
| enforced by the systems that are being sold as authentication
| (for now).
|
| As soon as those tech companies get an encryption / signing
| key they effectively control (via requests as the relying
| party), there's going to be a lot of incentive, and ability,
| for them to seize even more control over our devices.
| jabbany wrote:
| This is a terrible idea though.
|
| I had the misfortune of getting into a cycling accident which
| broke my phone display (completely lost display output and
| touch input), and it meant I lost access to all my OTP 2FAs
| for a couple of days (which is actually kind of scary).
|
| I was able to fix it myself by getting parts and going
| through an ifixit guide (right to repair anyone? ;-), after
| which I promptly exported my 2FA seeds to (1) a backup phone
| (2) KeePass, which apparently supports them, who knew... and
| (3) a QR code on a printed piece of paper.
| livueta wrote:
| Maybe I'm getting tinfoil-y here, but I think the
| horribleness is the point: consider how eager Apple in
| particular is to get people fully enmeshed in their
| services ecosystem. You're a lot less likely to try to roll
| your own backup, or otherwise exit the walled garden, if
| doing so means your entire auth story is irredeemably
| fucked.
|
| The thing that strikes me about this whole story is that
| during a lot of the initial discussions of passkeys, a
| common point brought up on the anti-lockin side was the
| ability to use non-phone providers like yubikeys. If the
| actual implementations make this less viable, as discussed
| in the article, then that shifts power towards lock-in.
| yellow_postit wrote:
| Not tin foil -- Apples privacy pushes (in some markets)
| are based on driving up lock in and benefiting their ads
| and apps. Any consumer benefit is a second order impact.
| jeroenhd wrote:
| Using "something you have" as an extension to "something
| you know" is essentially the point of all of 2FA. That's
| why backup 2FA methods are essential; if it's not extremely
| hard to get access to your account(s) after you lose all of
| your second factors, 2FA is pointless and you could've just
| sticked to just using passwords.
|
| That said, passkeys aren't necessarily second factors; they
| can be a relatively secure first factor as well, basically
| acting like long, randomly generated passwords that are
| impossible to be reversed or to be used in credential
| stuffing attacks.
| jabbany wrote:
| See, this where the metaphor breaks down. At no point was
| the phone "lost". The 2fa tokens are perfectly safe yet
| there's no way to get to them... even though you still
| "have" the things, you can't prove you have it.
|
| Which is why having 2FA _solely_ on a phone (like OP
| implies) is a bad idea. It's a fragile device that can
| easily render you unable to prove yoh still have it.
| sedatk wrote:
| That's indeed scary. Losing your 2nd factor shouldn't block
| you from accessing your accounts _indefinitely_. There
| should at least be one recovery path outside 2FA be it
| "printed recovery keys", "email recovery", "support
| channels", or even (despite being fully insecure) SMS maybe
| with a grace period (like 48 hours). Backing up your 2FA
| secrets isn't user-friendly at all, and it's even harder
| after you've started using it.
|
| Yes, those recovery paths are also susceptible to phishing,
| scam attacks, and they should be designed with that in mind
| like, for instance, with ID verification, notifications
| from multiple channels, process delays.
|
| Everyone should go over their Authenticator app and check
| their recovery options with every account they have there
| to make sure they don't fall into this trap.
| jabbany wrote:
| This is definitely good advice.
|
| My point here is to note that "phones" are not a good 2nd
| factor, unfortunately, because they're not that durable
| and are kind of targets of theft. So moving to solely
| rely on phone sounds like a bad idea.
|
| In my case, this was not the end of the world since I use
| a Yubikey for Google rather than TOTP, so at least my
| core email services (which represent a huge identity
| provider) were fine.
|
| (This is also the reason why I could afford to wait to
| get parts and fix the phone rather than get into some
| panic mode of having all my digital accounts in a state
| where I might get locked out at any point.)
| SebastianKra wrote:
| No, the idea is to turn _every_ device into your passkey, and
| also at least one cloud provider of your choice.
| saulrh wrote:
| That's a rather uncharitable take on the situation. I'll propose
| an alternative: If you want to take advantage of the new auth
| standard that will eliminate weak passwords and password reuse
| (thereby preventing 99% of casual account break-ins), you'll have
| to spend $30 to upgrade off the legacy yubikey you've been
| coasting on since 2013.
| DangitBobby wrote:
| Can you give me a high level description of why passkeys won't
| work with my current hardware key, and then explain why they
| went with that implementation instead of one that works with my
| current hardware key?
| runiq wrote:
| `rk=required` means your hardware is required to store each
| and every derived key, not just the master key, all in the
| service of you not needing to remember your username anymore.
| Current security keys can handle a couple dozen derived keys
| at most, _if_ they can handle any at all.
|
| This flies in the face of previous promises where 'every key
| can handle an unlimited amount of accounts'. In my eyes, this
| looks like a big push towards phones as passkeys, and nothing
| else. Would fit with the Bluetooth sync strategy as well.
| MountainMan1312 wrote:
| As someone who doesn't and won't ever have a mobile phone,
| I can't comprehend why things are going in this direction.
| pulpfictional wrote:
| Because almost every human who has digital accounts does.
| taeric wrote:
| This doesn't really change much, though? My keys can only have
| 25 resident keys on them, and I also have more than 25
| passwords stored in my password manager.
| conradev wrote:
| Password managers can store passkeys. I plan on storing
| passkeys in a password manager for most accounts, and then
| moving the few that matter to be resident keys. The
| theoretical advantage here is twofold:
|
| - Passwords are not guessable any longer
|
| - Password managers don't expose secret material in normal
| operation, because they sign requests with keys stored in
| TEEs (i.e. most modern devices have an embedded security key)
| [deleted]
| dathinab wrote:
| and this is already messed up
|
| password managers are a security liability which only
| exists because of how flawed password are
|
| the original design of WebAuthn was all about taking both
| password and password manager out of the equation
| noticeable reducing the attack surface
|
| instead how it now looks they will make password managers
| mandatory
|
| until they make "blessed" storage mandatory basically now
| controlling the password manager and HSK industry (by
| deciding which ones work with their products) and then
| maybe kill the whole industry by only allowing the storage
| build into Android,iOs,Windows, etc.
|
| And while stuff like this sound like a crazy conspiracy
| theory in the past the more I look into how passkeys
| developed in recent years (especially how they where
| represented) the more stuff like this sound quite viable. I
| mean big coperations which frequently have been found to
| abuse their power and try to get vendor locking wherever
| they can afford to, pushing a technology which looks like
| an improvement but can easily be abused to facilitate
| vendor lock-in and control over parts of an industry with
| the goal to abuse that... that isn't anymore conspiracy
| territory, that is what Microsoft has been doing in the
| past non stop and only stopped doing because it was no
| longer monetary beneficial for them. But in this case it
| would be. For them and Apple and Google and a few other
| huge companies.
| taeric wrote:
| If passkeys become defined as resident keys, is this still
| true?
|
| And if this is acceptable, honestly, do we need a new
| standard? Password managers exist today. Such that I
| already do what you are suggesting here with passwords.
| Does it really become much more secure by the move to
| passkeys?
| ericjmorey wrote:
| Passkeys are for the people that don't even use password
| managers outside of what Apple or chrome provides by
| default if at all. Passkeys are trying to eliminate those
| ad hoc solutions by providing a different system. The
| transition will be slow and messy requiring most people
| to use passkeys and passwords (and maybe password
| managers) for a while.
| taeric wrote:
| But if the passkeys are copyable off of where you are
| storing them, then I'm not entirely clear on how they
| truly up the security?
|
| I mean, I get the obvious ways that a challenge system is
| better than a bearer token. But I feel a ton is lost as
| soon as you move to the exportable keys.
|
| Love to see an exploration on these topics. I confess I
| have not been following them much, lately.
| ericjmorey wrote:
| I think the general idea is that the vast majority of
| people have a smart phone, so the security model is to
| let people use the phone as the "key" to access services
| and take advantage of the biometrics/pin security as the
| main component of security access. This means that there
| are a lot of security compromises that make sense in the
| name of ease of use.
|
| This model has been tested to some extent with Apple pay
| and Google wallet which people take relatively seriously
| since there's money involved. I think the model makes
| sense to improve security for the masses, but it's not
| good for people that want and demand more (like people
| that already bought YubiKey products).
| taeric wrote:
| Oddly, pay/wallet work for completely other reasons.
| Largely in the absurd amount of monitoring that the
| credit companies do to watch your transactions. That and
| the general legal framework around charges.
|
| Consider, that is largely replacing 20ish numbers with
| something else. Is slightly more convenient for folks, as
| you have your phone with you a lot.
|
| So, for the passkeys, I know that there is a secure
| enclave in phones. I was not aware that they could store
| resident keys. Know what the limits are, there?
| [deleted]
| recursive wrote:
| If you use good passwords, I don't think they're any more
| guessable than passkeys.
| cuu508 wrote:
| My worry is in the future there may sometimes be no other
| option than to take this "advantage". If a site implements the
| new auth standard, will it also keep the current
| username/password/2fa as an alternative option?
| JohnFen wrote:
| I think that probably depends on popular adoption. If going
| passkey-only causes a significant reduction in users being
| able to access the service, then there will always be a non-
| passkey option.
|
| Personally, I think there is significant friction to adopting
| passkeys, so there is little risk of being forced into using
| them in the near future. Longer term, though, I have no idea.
| vorpalhex wrote:
| Is there a clear path to a yubikey device supporting 1000+
| resident keys and doing so well in the near future?
|
| What does the cost look like? Are we talking $50 or $500?
| radicaldreamer wrote:
| I'm not sure why current keys cost so much...
| RandomBK wrote:
| My hunch is low volume and an enterprise-leaning customer
| base. Engineers aren't cheap, and those who can build
| security-sensitive products even less so.
|
| When I bought a (single) Yubikey from their website late
| last year, it was Fedexed to me directly from their Palo
| Alto downtown office, not some distribution center in the
| middle of nowhere. That can't be cheap.
| darthwalsh wrote:
| If you order a key and it comes from an Amazon warehouse,
| are you going to be worried about a supply chain attack?
| Maybe that's a benefit of sending by direct FedEx?
| fatfingerd wrote:
| $25. The solokey 2 already used a STM chip that could support
| at least 20X the storage (in USB mode), but didn't activate
| it in their initial firmware..
|
| Additional flash that is just as secure would be expensive
| mostly because other Smart Card uses don't need it, but it
| doesn't really have to be secure because storing resident
| keys could be done in a similar opaque style as a server and
| only really brought in to the secure context when needed.
|
| Edit- misremembered NXP->STM and added USB as difficulty
| getting significant flash within the NFC powered chip is an
| important consideration.
| saulrh wrote:
| Presumably Yubico's upgrade path is to tweak the form factor
| slightly so they can fit more than a few kb of memory into
| the thing. I know that it's possible, I can buy 50GB flash
| drives in the micro yubikey form factor, the ones that are
| just a rectangle of plastic that fits in under a USB-A port's
| tongue, and they only cost like $10. So it's probably just
| something that Yubikey needs to design into the next gen of
| keys, and I suspect it won't make them cost much more than $5
| more than the last gen.
| dathinab wrote:
| I would go as far and say it's a too charitable take.
|
| Shared residual keys _should not exist_ (outside of short term
| temporary usage, e.g. not 2FA/FIDO).
|
| They are a liability, they are a security risk, they promote
| bad security practices.
|
| Best example TOTP (which from a security POV is quite flawed).
| You don't want to ever share the shared secret across devices
| (or back it up) but due to it being possible and flawed 2FA
| implementation being the norm not the expectation you are kinda
| forced into it. And as thinks look now passkeys will go into
| the same highly flawed user hostile direction.
| 0cf8612b2e1e wrote:
| > You don't want to ever share the shared secret across
| devices (or back it up)
|
| Hard disagree there. I do not feel comfortable unless I can
| backup a key. Phones get lost/broken/stolen all the time. Is
| it less theoretically secure? Sure, whatever, but I am not
| James Bond.
| dathinab wrote:
| you don't need to backup a shared secret to gain exactly
| what you get from backing up a shared secret, except more
| secure
|
| you have a backup of a _different_ secret with a similar
| degree of "authority" (or if it's "copyable" with the only
| authority to be used for restoring 2FA once or similar)
|
| then if you backup gets stolen you can just go into you
| account management API and disable/delete/flag it, in that
| case even if encryption is broken as long as you act fast
| enough the damage is trivially and conveniently contained
| (e.g. some password managers had insecure backup/storage in
| the past)
|
| with the same key not only do you have to disable it, you
| first have to create a new key and then sync it to all your
| new devices and backups and then disable the old key, which
| isn't grate if you have more then one device or some of you
| devices are temporary out of reach (e.g. you one a business
| trip)
|
| it's like reintroducing the "physical" problem of having to
| replace all locks when you loose your house key in a
| situation where you could have all the benefits one key per
| lock and a different door for each person (i.e. device)
| without any of the overhead/drawbacks this would normally
| introduce
| rcxdude wrote:
| The main issue I see happening here with a large list of
| keys is the lack of an automated way of making these
| backups: this would require a standard way for a backup
| system to use one set of secrets to authenticate another
| set of secrets, which AFAIK doesn't exist for webauthn
| (it must be initiated by the site, all of which will have
| different methods of doing so). Otherwise you would have
| to manually enroll multiple devices for each account,
| which is both painful and error-prone.
| pohuing wrote:
| That's what the one time use backup keys are for
| cbsmith wrote:
| The usual solution for this is to have multiple keys. It's
| logically equivalent to having a backup key, but it's more
| secure because if you lose a key, you can use another key
| to disable the lost key.
| rcxdude wrote:
| The point is you would have a different key on different
| devices, each of which can access your account. This gives
| you a backup, in fact a better one, because if one is
| comprimised and locked out you can still use the others.
| The main challenge is automating this process so you can
| properly mirror your keyring across multiple devices, which
| I don't think there's a standard solution to. So it would
| be a manual process for each account, which kinda sucks.
| kj4ips wrote:
| I just looked a the technical manual for the 5 series, and it
| only supports 25. I only have two right now, but I have way
| more than 25 TOTPs.
|
| I don't know what the Bio FIDO ones have, but if it is similar,
| YubiCo may not have a product well placed for a large number of
| RKs.
|
| ~Edit: The Bio's have the same limit of 25
| mixmastamyk wrote:
| I think the FLOSS keys can handle more than that. But, I'd
| probably separate work and personal accounts to different
| pairs of keys anyway.
| radicalbyte wrote:
| As matthewaveryusa says above, you can have the key on the
| Yubi generate then encrypt the private key; that encrypted
| private key is then stored on mass storage (synced to iCloud
| etc). Then to use it you supply the key + data to sign the
| auth challenge.
|
| My issue then is that these keys allow total tracking. We
| need hardware implementing more complex and privacy
| protecting schemes (BBS+ etc).
| gruez wrote:
| Why should I be forced to upgrade? Non-resident keys also
| eliminate weak passwords and password reuse. Using resident
| keys only add marginal improvement (ie. you can plug in a key
| and the service knows which account it belongs to), and that
| doesn't seem like a good justification to deprecate all the
| existing authenticators in use today.
| servercobra wrote:
| Maybe not for us, but for the vast majority of users, they'd
| pick not having to remember a username OR password for sure.
| somehnguy wrote:
| Someone using easy to guess simple passwords probably isn't
| using a Yubikey and also likely has no interest in getting one
| at all. Those 2 categories are very different people.
| jabbany wrote:
| I wonder if there could be a middle-ground software solution
| here?
|
| E.g. A piece of software (like a passkey manager or keychain
| service) that transparently simulates a resident key store by
| using an encrypted database that resolves services to credential
| IDs which are then forwarded and unlocked by a non-resident
| hardware key. One could then conceivably still sync the database
| around (using whatever services or method you want), and even if
| the encryption of the database were somehow broken, it wouldn't
| be the end of the world, as the actual signing is still done by
| the hardware key.
|
| (Disclaimer: I don't know enough about the actual protocols to
| judge if the above is actually technically feasible, but would be
| curious if it is)
| dcow wrote:
| We absolutely need to allow soft implementations to exist. The
| platform providers are already doing this. You should be able
| to use your password manager as a passkey manager. The RP
| shouldn't dictate any of this and the protocol should actively
| resist platforms locking people in to (their) blessed
| implementations.
| jefftk wrote:
| For figuring out whether I should be worried about this, how can
| I check how many resident keys my security key can handle?
___________________________________________________________________
(page generated 2023-07-13 23:00 UTC)