[HN Gopher] KeePassXC pull request to add basic support for WebA...
___________________________________________________________________
KeePassXC pull request to add basic support for WebAuthn
Author : pabs3
Score : 307 points
Date : 2023-05-08 10:00 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| uglytruth2 wrote:
| We all know this is mostly meaningless.
|
| The real 'feature' of webAuth is 3rd party attestation.
|
| Your bank and soon every other service will see how 'cheap' it is
| to fight spam and abuse simply by restricting accounts attested
| by [apple,google,microsoft] and nobody else, specially 'None'
| like this one.
|
| When you talk about webAuthn that is what you are talking about
| in the end. 3rd party attestation. Which in the end will be the
| end all "privacy respecting" (/s) advertisement profiling tech in
| the years to come.
| prhrb wrote:
| Can someone explain more?
| Scion9066 wrote:
| Basically, for hardware backed devices like phones and
| physical security keys, there's an attestation certificate
| that is shared by all devices of that model. This can allow a
| site that wants higher security for some reason to require
| this kind of proof that the key is protected from copying in
| hardware (eg bound to a specific device and can't be stolen
| via malware, theoretically) due to it being a model known to
| be secure. I'm not aware of specific sites requiring this
| though.
|
| It is recommended that sites don't require it: "It is
| important to be aware that requiring attestation is an
| invasive policy, especially when used to restrict users'
| choice of authenticator. For some applications this is
| necessary; for most it is not. [...] When in doubt, err
| towards being more permissive, because using a passkey is
| more secure than not using a passkey. [...] we recommend that
| you do not require a trusted attestation unless you have
| specific reason to do so." https://developers.yubico.com/Pass
| keys/Passkey_relying_party...
|
| More info: https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Authent...
| vlovich123 wrote:
| That seems like truly terrible advice. The only example
| given:
|
| > It may still be useful to request and store attestation
| information for future reference - for example, to warn
| users if security issues are discovered in their
| authenticators - but we recommend that you do not require a
| trusted attestation unless you have specific reason to do
| so.
|
| If that's the only application, that communication should
| happen through alternate channels like your browser/OS
| vendor itself. Having random websites be responsible for
| communicating whether a given attestation may indicate
| compromise is less than helpful and the probability of that
| actually happening correctly is about 0. Oh and given all
| the breaches, if there is a compromise, the attacker now
| has a helpful list of customers using compromised
| authenticators.
|
| One application seems to be to use this to try to replace
| captcha but I wonder what kind of impact that will have on
| 3p authenticators. Without extra details, it may be right
| to be concerned this is a massive landgrab as to how people
| access online services.
| thealchemistdev wrote:
| [flagged]
| antiloper wrote:
| What value does this comment add?
| lima wrote:
| Beautiful example of the limits of AI - it simply
| reiterates the comment in a seemingly informative way, but
| it doesn't actually _understand_ it, so it really just
| states the same thing but more verbosely. Knowing nothing
| about Passkeys, it 's also subtly wrong.
|
| What exactly is your point?
| [deleted]
| misnome wrote:
| Not just verbosely, but with the implied contempt!
| namaria wrote:
| It's a bit anticlimactic how the hype is just dying down
| and everyone involved is just pretending they weren't
| just weeks ago crying wolf about the whole thing. Still I
| feel vindicated in my early assessment that it was mostly
| just empty hype about some chatbot.
| endgame wrote:
| After the success of EME, why would anyone expect any
| different?
| ale42 wrote:
| This doesn't _need_ to happen. Having such a function in
| KeePassXC is important so that there 's a sufficient user base
| not attested by big groups.
| alex7734 wrote:
| KeePass's userbase is negligible, banking apps didn't care
| about those that use rooted phones and won't care about
| KeePass users.
|
| My guess is that the big groups will lobby for this to be
| turned into a checkbox in some "best practices" list that
| auditors will enforce into the usual suspects in the name of
| "safety and security": banks, shopping sites, government
| sites, etc.
| flangola7 wrote:
| What do rooted phones have to do with anything? I use my
| credit union's app on my rooted, no google play services
| phone frequently.
| unaindz wrote:
| A lot of bank apps refuse to work if they detect your
| device as rooted/failing safetynet. My bank used to do it
| but they either stopped caring or more probably magisk
| now handles it so the apps can't tell.
| pabs3 wrote:
| I hear that the big tech vendors (Apple at least) aren't going
| to do attestable keys.
| ksjadfhiskwfh wrote:
| What do you mean? Apple already offer it.
|
| They are still to officially publish a spec, but already
| published rate limits for 3rd party apps attested requests on
| the official docs and since 2021 people are documenting how
| they are updating their IDs on AAGUID fields on already
| available attested requests.
| gdubchcb wrote:
| this is wrong. you're confusing with app attestation. the
| other reply to this comment is also wrong.
|
| passkey lack the attestation content because the spec
| doesn't provide for the case being discussed on another
| thread... cloud backed up keys.
|
| attestation field, per current spec, must attest the 3rd
| party own the key and it only lives in a single placed
| (original intent was harware on client validated by vendor
| keys there)... now obviously we know apple google backup
| your keys on their cloud, so they cannot attest anything
| per current spec.
|
| don't takes that as a instance on privacy. they are rushing
| changes to the spec.
|
| as soon as they can attest keys that are shared with their
| clouds they will do.
| ivlad wrote:
| It's about attested keys, not attested apps. Apple does not
| attest their software-backed FIDO keys (they call them
| passkeys).
| lima wrote:
| > _Your bank and soon every other service will see how 'cheap'
| it is to fight spam and abuse simply by restricting accounts
| attested by [apple,google,microsoft] and nobody else, specially
| 'None' like this one._
|
| If that's what they want, they can have it today via OAuth/OIDC
| (and many sites do just that). It's not a panacea - Google & Co
| catch some spam accounts but not all of them and not always
| before the damage is already done.
|
| Passkeys/WebAuthn improve the situation by giving site
| operators more choices.
| gdubchcb wrote:
| not even close the same thing.
|
| oauth/oidc gives too much signal to the identity providers.
| it's a 1990s solution at the time advertisers were writing
| the specs alone. and the implementation required oath-nascar-
| sponsorship pattern to have dozen of providers. no bank would
| accept that.
|
| webauth is a spec of this time, were it's still owned by
| advendors, but with a couple device vendors now for a
| semblance of balance. and it also solve the implementation
| issue of having to show too many logos on the login page.
|
| so, no, it wasn't possible before webauth. webauth solves the
| oauth issues for 3rd party attestation with a semblance of
| anonymity (which is meaningless if both party exchange data
| on back channels)
| znpy wrote:
| Isn't this similar to the trust issues for the x509 CA model?
|
| Basically you're implicitly trusting that no other CA among
| those trusted by common browsers will emit a certificate for
| your domain.
|
| While this isn't really nice for website certificates, and
| while there are some safeguards (although the strong ones got
| deprecated, like http key pinning) ... once you go down to the
| granularity of a single user... not sure how that pans out.
| Scion9066 wrote:
| Attestation is more like: The passkey is from this model of
| security key/phone.
|
| That can then be used to have a list of allowed devices if
| you really need hardware backed security for example (eg you
| provide all your users in your org with specific security
| keys and don't want them registering anything else). It's not
| recommended to use the attestation part unless you really
| need it though as it restricts user choice.
| pmoriarty wrote:
| Can anyone explain in a simple, practical way how you would
| actually use this?
| notum wrote:
| KeePass becomes your YubiKey/Authenticator.
| mikece wrote:
| KeePassXC _is not_ KeePass.
| piokoch wrote:
| KeePassXC is one of those old style applications that are fast,
| small, does not change UI every quarter and does well what it was
| built for. It does not offer "cloud integration", does not send
| email asking you if you are happy with it and if you want to
| upgrade to Pro Plan that let you share your passwords with your
| grandma. Or mine cryptocurrency, ok, this crypto is passe now,
| nowadays, it would be integration with ChatGPT that would invent
| better passwords for you...
|
| You put the file on Google Drive, Drop Box, etc. and now you have
| simple, "distributed" password manager that works on every
| reasonable platform.
| admax88qqq wrote:
| Google drive file conflicts fail silently. Putting your key
| pass file in drive is setting yourself up to lose credentials
| if you devices sync up at a bad time.
|
| A cloud solution that syncs on a per password basis with end to
| end encryption offers a more reliable experience.
| liminal wrote:
| I just switched to KeepassXC because KeeWeb is now unmaintained.
| I really miss the UI simplicity of KeeWeb. Posting this here in
| case there are any folks reading who are motivated to maintain a
| Keepass implementation with a far better UX.
|
| https://keeweb.info/
| remram wrote:
| This requires a browser with a passkey-providing plugin right?
| There is no way to use a passkey without browser support, like
| there is for password managers (copy/paste, or copy it from your
| phone screen)?
| vrglvrglvrgl wrote:
| [dead]
| flangola7 wrote:
| I thought passkeys are always stored in secure enclaves and can't
| be exported?
| ezfe wrote:
| No, Passkeys are just some random data and cryptography.
|
| However, the most popular implementations (like in iOS/macOS)
| use TouchID/FaceID/Passcode to protect access to the passkey.
|
| That doesn't preclude other implementations from doing it other
| ways.
| AviationAtom wrote:
| Am I mistaken, or has the open source community beaten the
| commercial password managers to implementing WebAuthn?
| 8organicbits wrote:
| I'm not sure about other password managers, but this pull
| request is still open so it's not ready yet.
| samcat116 wrote:
| 1Password already has a beta/demo of this I believe.
| fullstop wrote:
| Bitwarden supports it (for paid accounts)
|
| https://bitwarden.com/help/setup-two-step-login-fido/
| sodality2 wrote:
| That's not the same thing. Here, KeePassXC supports being a
| WebAuthn _device_ for logins, whereas linked is how you can
| use WebAuthn to log _into_ bitwarden. The former is basically
| (?) emulating the device, whereas the latter is just
| supporting it for vault logins
| fullstop wrote:
| I understand the difference now. Thanks!
| SkyMarshal wrote:
| I use KeePassXC on my linux desktops and macbook, but are there
| any good mobile apps that support it, that I can import my
| database into?
| jamietanna wrote:
| KeePass2Android is great (for Android) - been using for 5+
| years
| shhsshs wrote:
| I have been enjoying Strongbox for passwords plus Mobius Sync
| (a Syncthing implementation) to keep the password file synced.
| I am on iOS.
|
| Mobius Sync can sync a file to iOS' built in file store, and
| Strongbox can read that. So they work pretty well as a pair.
| kps wrote:
| Is there now a straightforward way (on both platforms) to use
| KeePassXC in the role of login keyring/keychain? Last time I
| looked, admittedly not recently, the answer was "we think you
| shouldn't want this".
| SkyMarshal wrote:
| I don't know, I do everything manually. I remember most of my
| passwords, but when I forget one I open KeePassXC and copy-
| paste the pwd into the login. And once every month or so,
| I'll manually ssh the databases around in a round-robin
| manner and merge them on every machine. Mainly b/c my pwd
| database is one thing I don't really want to trust to the
| cloud, and the manual effort of not doing that isn't too
| onerous.
| kioshix wrote:
| I use KeePassium on iOS, synced with Dropbox. Works perfectly.
| Other sync methods are available too.
| flal_ wrote:
| KeePassDX on Android
| makepanic wrote:
| (last commit from Dec 11, 2022)
| Ajedi32 wrote:
| Yeah, this isn't new. I've been advocating for this since
| 2018[1], and the PR in question was submitted in November 2022.
|
| The PR isn't dead though. There's some additional discussion[2]
| on its current state in the issue I linked above. Basically, it
| needs more people to test the implementation against different
| sites in the wild.
|
| Hopefully the increasing popularity of passkeys will provide
| the necessary level of motivation and support to get this over
| the finish line.
|
| [1]: https://github.com/keepassxreboot/keepassxc/issues/1870
|
| [2]:
| https://github.com/keepassxreboot/keepassxc/issues/1870#issu...
| wkat4242 wrote:
| Eh no? The repo has been committed to 7 hours ago.
|
| Of course the pull request is pending review but that's not too
| exceptional.
| makepanic wrote:
| Yes I'm talking about the PR which sadly didn't really
| receive any recent review activity
| biscuitech wrote:
| The repo was committed to, yes, but not the linked PR. The
| linked PR hasn't been updated since December of last year.
| account-5 wrote:
| If this gets implemented it will be the first step in showing
| that passkeys are a viable alternative to passwords in a
| meaningful way.
|
| That is, there is no vendor lock in to multinational corps only
| interested in their bottom line and selling your data. They
| aren't tied to a device that can be lost, stolen or broken, or
| requiring you to have multiple devices just in case; and not tied
| to biometrics.
|
| Lastly this means there is a proper open source, offline version
| that is portable across devices, browsers, and ecosystems.
| Putting the user back in control.
| JeremyNT wrote:
| This doesn't solve anything, sadly.
|
| You are entirely at the behest of Bigco as to whether they will
| require keys signed by any particular device's certificates,
| and they have no incentive to allow interoperability here.
| krono wrote:
| Attestation certificates include detailed information about the
| device that signed them. Nothing is stopping services from
| limiting accepted devices to only those approved by the passkey
| gang (MSFT,AAPL,GOOGL).
|
| Suddenly things that many so readily dismiss as being FUD such
| as retail Pixel devices' bootloader requiring an internet
| connection to unlock[1] become much more more relevant.
|
| [1]: https://news.ycombinator.com/item?id=35852192
| throwaway2056 wrote:
| > FUD such as retail Pixel devices'
|
| At the end of the day pragmatism will survive. Sure, if the
| OP cant put a simple SIM card to get it resolved then he/she
| can buy from nitrokey/other installed GrapheneOS.
|
| The basic premise of all these
| authentication/fingerprint/passkeys/whatever is to benefit
| the COMMON public. Telling a mother of 3 to keep keypassxc
| backup elsewhere (in a RAID with 3-2-1 offsite is
| impractical).
|
| Also all these experts that write in HN often join some
| company and implement closed-source. Yes, life sucks if one
| uses 'linux' phone
|
| - Banks don't care - If one is so against passkey gang then
| they should do something to make sure an average mum can use
| tech safely - see the state of PGP (very complex) - but
| signal/whatsapp is awesome. - Whether or not you like Cisco
| DUO becomes more of less default - Github/gitlab is
| developers world. Sure codeberg exists: I opened an issue
| asking them if they can help me configure runners - no help
| at all. - Also many of the devs say all open/free/etc but
| finally they do consume NetFlix, Prime etc (Yes, they have
| Apple TV or chromecast in addition to FrameWork (and RAID +
| 3-2-1). - Average Joe can't afford Framework. Get an ad-
| infested smartTV. Live with Google or Apple.
| krono wrote:
| To clarify I'm not against passkeys and WebAuthn, only
| leery of the gang and their games.
|
| With that out of the way: I'm alright with you, that
| hypothetical mother of 3, Average Joe, and anyone else
| accepting the situation as is no matter the reason. Myself,
| though, however pointless it may be, I haven't given up the
| fight and I'm likely worse off for it. I suppose that makes
| me a masochist.
|
| Everything you say is true, and yet none of it relevant for
| the sceptical and cynical thoughts that I sometimes share
| here. I don't post those for people who don't care, I post
| them for my fellow masochists so they don't miss out on
| whatever new thing I found that we can all get more angry
| about :)
| throwaway2056 wrote:
| To be honest, I was once like you but eventually it is
| painful to have tons of harddisks and maintain things.
| Also when I once visited a FSF event and saw many of
| those so called advocates (telling amazing things in
| blogs about Libre) were personally using iPhone and
| NetFlix or every other proprietary service or M1 Apple.
| Sure, everyone's choice. Then I learned that we all have
| cognitive dissonance.
|
| > fellow masochists so they don't miss out on whatever
| new thing I found that we can all get more angry about :)
|
| Ha ha ha!
| pabs3 wrote:
| I hear that the big tech vendors (Apple at least) aren't
| going to do attestable keys.
| krono wrote:
| Must have missed that, thanks. I'm not entirely up to date
| on this initiative.
|
| Just to be clear I'm not opposed to WebAuthn, I've just
| gotten very weary of these big corporations - especially
| when they are banding together and are all super excited
| about the same thing as we're seeing here :)
| arianvanp wrote:
| Luckily apple is of the opinion that attestation is a bad
| idea for adoption and they canned it
| asmor wrote:
| > They aren't tied to a device that can be lost, stolen or
| broken, or requiring you to have multiple devices just in case;
| and not tied to biometrics.
|
| They optionally can be all of the above, using AAGUIDs and
| direct attestation.
| rootusrootus wrote:
| If even one of the big three refuse to support attestation,
| then it's dead. And trying to retroactively force attestation
| at a later date will an even bigger headache than it would be
| right now.
| cyphar wrote:
| I don't understand your point about vendor lock-in, on the
| devices side YubiCo, Feitian and NitroKey exist (as well as
| many others probably) and are none are "multinational corps" in
| the derogative sense (the replies make reference to Google,
| Microsoft, Apple -- do those companies even produce U2F
| tokens?). On the authentication side, WebAuthn isn't tied to
| SSO and most websites that have their own login system will
| probably just add WebAuthn rather than switching to SSO (the
| WebAuthn and FIDO sites both have PoCs you can test and there
| are plenty of open source libraries and frameworks to use).
|
| I also don't get your point about how tokens could be used to
| sell your data -- it's my understanding that it'd be very
| difficult to track someone using their U2F key (there are
| attestation keys but they're done in batches so you cannot
| track an individual token, and the registration handshake
| doesn't use a unique ID you can use for tracking). But even
| ignoring that, if it were possible to track people using their
| token, then a digital token in KeePassXC would also be just as
| trackable.
|
| Personally I don't see a huge difference between this KeePassXC
| feature and just having your password (and maybe OTP) stored in
| KeePassXC and auto-filling everything. I think that's also
| secure enough for the vast majority of people (it's also what I
| use for websites that don't support WebAuthn as a second factor
| or when I don't want to have to have a physical token to do
| actions) but it's clearly not a _second_ factor of
| authentication. Requiring a physical token is sometimes a good
| thing. Yes, if it breaks it 's annoying, but requiring a token
| is what makes it _multi_ factor authentication.
| dathinab wrote:
| The vendor locking argument is less about "classical"
| WebAuthn and more about passkeys.
|
| But even for "classical" WebAuthn it's still a valid issue.
|
| The problem lies in:
|
| 1. attestation
|
| 2. browsers like chrome possible gate-keeping what can work
| as an authentication device (independent of attestation)
|
| Attestation is a feature where each "batch" of authentication
| devices get a unique certificate burned in and report that
| back when registering a key through webauthn. There will be
| roughly at most 10_000 other people with the same cert. In
| many cases likely less.
|
| And that is _highly_ problematic for many reasons. First
| while 10_000 sounds big, with just a bit additional
| fingerprinting information it allows a very unique
| fingerprinting of people across services (and devices you use
| to access the services). The combination of cert id + e.g.
| email + service + optional statistics about usability is
| _very_ saleable information, I mean a private health care
| provider would love to know that someone who might be one of
| their customers has signed up for a online anonymous
| alcoholic group or similar. They don't even need to know it's
| them for sure, just knowing it could be them with a 10%
| chance is enough to make sure to bump what their client has
| to pay "just to be save" the next chance the provider gets to
| do so.
|
| Furthermore this are "burned in" certs so you can't have a
| different attestation certificate per service or anything
| like this without also having different physical devices,
| which in case of e.g. using your phone might be hard.
|
| This "burned in" nature also means that some things can't
| have attestation, e.g. KeyPassXC or the TKey by nature can't
| (nor do want to) have this form of attestation. In turn if
| attestation is required this vendors are basically out of
| business.
|
| But this isn't where the problems stop, attestation can also
| be used to find out what kind of device you have in general
| including an approximate date of production. So now the page
| you auth against knows you use a specific kind of YubiKey or
| e.g. that you use a specific phone produced in some specific
| time frame for authentication. This is very useful
| information for marketing as e.g. lifestyle and believes
| often influence buying decisions, not necessary in the
| current HSK market, but on the phone market which with
| passkey will likely become the most common HSK.
|
| Furthermore this information can be used to remove agency
| from the user, e.g. through attestation a app can know that
| your HSK does support bio-metric authentication and in turn
| might force you to use it, even through you might not be able
| to do so because e.g. the fingerprint reader is broken or you
| had an op which makes face recognition impossible.
|
| Lastly attestation allows applications to not work with HSK
| vendors they don't like even if they are standard conform.
| E.g. if Microsoft has beef with YubiKey they could reject
| them and make it look like a bug. Or a app you have for work
| could decide that using any HSK which isn't their partner (or
| from themself) is only usable if you pay a premium or
| similar.
|
| Now the good part is WebAuthn doesn't require attestation.
| You can set attestation to none, and this can be done for
| devices which support attestation, too. E.g. Firefox does so
| by default.
|
| The problem is if even just a small number of the big players
| (e.g. Google + Microsoft) decide they do require attestation
| on all logins it could be game over for _any form of privacy
| preserving 2FA for good for ever_ (except if regulators step
| in). Worse through chrome and edge they can enforce requiring
| attestation for sides which do not want to enforce it and
| collect additional private information by sending the
| attestation information data to their ad-services. Don't
| forget that not to long ago edge had a bug which wasn't fixed
| for a long time which lead to it basically sending all links
| their user followed to bing, including magic sharing links
| like you e.g. know from google drive. So don't expect vendors
| to not a
|
| And for the big players enforcing attestation through the
| ecosystem is as easy as flipping a switch. As most HSKs
| support attestation. Furthermore they could add additional
| requirements, like only accepting attestation from vendors
| which have gone through some very expensive security review
| done by companies of their choice (Google already does so for
| access to (large pars of) their oauth2 authenticated APIs).
| This could mean good-by to any smaller or new HSK vendors,
| and might majorly hurt phone vendors they don't like.
|
| Now you might wonder why attestation exist if it's that bad.
| The reason is requirements for some enterprises like e.g.
| military contractors requiring FIPS certified devices.
| Attestation can be used to enforce this. It also can be used
| to e.g make sure your employees only use HSKs you gave to
| them.
|
| IMHO the main problem I see is not that attestation does
| exist, but that it's often phrased as a good or desirable
| thing (instead of a necessary evil) by the groups pushing for
| WebAuthn/passkey making me believe that there is a extremely
| high risk of abuse of this feature by Google, Microsoft or
| similar in the not so distant future. Especially given that
| it can be monetary wise quite beneficial and could be forced
| down the throat of users without most realizing it.
|
| I would prefer if attestation would by default always be off
| and the spec requiring vendors to support non-attested
| devices as long as the user (or company the user belongs to)
| doesn't require it. Require that attestation information must
| be enabled on the key instead of being enabled by default,
| etc. I.e. make it cumbersome enough so that it can't easily
| be abused but still usable for the rare military contractor
| like use case. Oh and also there should be ways to have more
| privacy preserving attestation, too.
|
| EDIT: To be clear you don't have the whole cert with all
| device information burned in, but a private key + some
| metadata and you can look up all this information based on
| the metadata depending on the kind of attestation. I.e. it
| works similar to TPM attestation, but not necessary exactly
| the same (expect if you used a TPM as HSK then it's exactly
| the same).
|
| EDIT2: Just to be clear WebAuthn is in general a grate idea
| and could even lead to more privacy if used nicely. But it
| sadly has also potential for abuse and the parts which allow
| abuse can't be stripped out for practical reasons. So I'm
| worried.
|
| EDIT3: WebAuthn today is mostly used for second factor in 2FA
| but it has the potential to become the first factor or fully
| take over both factors. Providing a more secure and
| convenient experience. But if abused also enforce more
| control of big cooperation, leak ton of private information
| (especially to the big cooperation's) and remove agency from
| the user in a not really acceptable way.
|
| EDIT4: China could use attestation internally to even more
| control their citizens if they want to (might not be worth
| the effort), e.g. requiring vendors to be whitelisted (hint:
| vendor leaks private keys to government) or coupling the
| citizen score to it in some way.
| account-5 wrote:
| I don't have an issue with simple hardware devices being used
| but for me that's overkill. And means I always need that
| device with me, and hope it doesn't break, or get lost or
| stolen. The only way to avoid these issues is to have
| multiple devices.
|
| Im pretty confident MS, Apple, Google will be pushing for
| their implementations to be the only accepted form of this
| authentication. It's not like their isn't precedent for this
| suspicion. And while it's not immediately obvious how these
| companies can use this technology to track you doesn't mean
| it can't be done or that they aren't working on it.
| brookst wrote:
| That's a lot of speculation to be using as the basis for
| opinion.
| account-5 wrote:
| Extrapolation from known facts of past conduct more than
| speculation. Either one is a good basis for opinion,
| since opinion is entirely subjective.
| cyphar wrote:
| Why would they bother trying to track you through a
| specification which is specifically designed to make it
| hard to track users? If you're using one of these software-
| based SSO lock-in "tokens" then they can get all the
| information they want from telemetry (nee spyware) on the
| device.
| account-5 wrote:
| A device you must use to authenticate.
| michaelt wrote:
| _> I don 't understand your point about vendor lock-in, on
| the devices side YubiCo, Feitian and NitroKey exist (as well
| as many others probably) and are none are "multinational
| corps" in the derogative sense (the replies make reference to
| Google, Microsoft, Apple -- do those companies even produce
| U2F tokens?)._
|
| The U2F keys made by Yubikey are indeed OK from a privacy and
| lock-in perspective.
|
| But the new latest thing from Google+Microsoft+Apple is
| 'passkeys' or 'passwordless' authentication, where you won't
| have a password. Two-factor authentication will be
| device+biometric, with the biometrics performed on the
| device. 'The device' in this case will be your smartphone, or
| windows PC with TPM. Or maybe a biometric yubikey for 0.01%
| of users.
|
| They've also fixed one of the big usability stumbling blocks
| of U2F, by allowing your credentials to be synchronized to
| your cloud account - so even if you lose your iphone you
| won't be locked out of your account, you can just buy a new
| iphone and restore the backup. And of course, you can't
| expect to restore the backups to incompatible devices - that
| might let attackers bypass the biometrics.
|
| It's fairly obvious why Microsoft would like people to not
| have passwords, and to log into websites using something
| locked to Windows and their Microsoft account.
| lumb63 wrote:
| Hearing "device+biometric" described as 2FA makes me
| chuckle. Really, that translates down to "biometrics reader
| storing the passkey+ biometric" being "2FA". By that
| standard, "a device storing a way to verify the password +
| a keyboard to input the password" should be 2FA. In which
| case, passwords were always 2FA to begin with, since the
| server/OS acts as that device.
| cyphar wrote:
| It seems to me that is the same problem as Single Sign On,
| and I think there simply needs to be legislation to make it
| not possible to monopolise markets this way (or just
| enforce the existing legislation on the topic).
|
| WebAuthn/FIDO are not the issue here.
| rgoulter wrote:
| > But the new latest thing from Google+Microsoft+Apple is
| 'passkeys' or 'passwordless' authentication, where you
| won't have a password. Two-factor authentication will be
| device+biometric, with the biometrics performed on the
| device. 'The device' in this case will be your smartphone,
| or windows PC with TPM. Or maybe a biometric yubikey for
| 0.01% of users.
|
| I don't believe it's restricted to Yubikeys with
| biometrics:
|
| https://support.google.com/accounts/answer/13548313
|
| "You can create passkeys on these devices:
|
| - A laptop or desktop that runs at least Windows 10 or
| macOS Ventura
|
| - A mobile device that runs at least iOS 16 or Android 9
|
| - A hardware security key that supports the FIDO2 protocol"
| 0xCMP wrote:
| A passkey is just a "software yubikey". I highly recommend
| trying to implement a demo of this and you'll see how
| little difference there is between them unless you
| specifically go out of your way.
| kps wrote:
| FIDO security keys don't store login-specific
| information. Passkeys do, which raises the lock-in
| problem.
|
| To be clear, I _want_ to be able to use passkeys, or
| something close, but I won 't if I can't control my keys,
| and I can't if I can't use them cross-platform.
| warp wrote:
| Current Yubikeys do allow you to store login information
| (Resident Keys in webauthn), and because Apple refuses to
| provide attestation for Passkeys, it's going to be very
| difficult for a website to force you to use a security
| key from any particular vendor.
|
| Obviously Yubikeys (and most/all other hardware keys) do
| provide attestation, so in theory a website could refuse
| to let you register those -- but if that becomes common
| it would be easy for any company to create hardware keys
| which refuse attestation.
| kps wrote:
| Higher Yubikeys do, but other FIDO2 keys, including
| Yubico's 'Security Key' series, don't.
|
| Apple's current policy on attestation is good (for
| consumers; I don't deny there are closed conditions where
| you'd legitimately use it), but their refusal to allow 3P
| integration is not.
| lxgr wrote:
| Effectively, they really do (yes, the Relying Party
| technically stored the encrypted credential, but to the
| user, their keys really "are in the Yubikey" in any
| meaningful way).
|
| But more importantly, they (to my knowledge) don't offer
| any in-ecosystem-only backup/sync functionality, which
| would make switching vendors that much harder and thereby
| create platform/vendor lock-in.
| kps wrote:
| Security key backup was always the biggest obstacle. In
| principle you could create fungible keys flashed with the
| same private key, but in practice that isn't possible
| (outside of some obscure open-source implementations).
|
| The second obstacle, of course, is the question: why do I
| need a separate microcontroller taking up a USB slot,
| when the host device is capable of running the same
| software? Passkeys do solve that (though so would soft-
| FIDO without resident keys), but the bait comes with the
| hook of vendor lock-in.
| lxgr wrote:
| > In principle you could create fungible keys flashed
| with the same private key, but in practice that isn't
| possible (outside of some obscure open-source
| implementations).
|
| Not necessarily - Yubico has a proposal (that requires
| some changes to all RPs, though):
| https://www.yubico.com/blog/yubico-proposes-webauthn-
| protoco...
|
| > why do I need a separate microcontroller taking up a
| USB slot, when the host device is capable of running the
| same software? Passkeys do solve that (though so would
| soft-FIDO without resident keys), but the bait comes with
| the hook of vendor lock-in.
|
| Trusted computing and vendor neutrality are unfortunately
| somewhat at odds with each other. Google has learned that
| the hard way with Google Pay - only when they finally
| gave up on Secure Elements (in favor of HEE and software-
| based OS attestation) did it become available on non-
| Google devices. The device vendors and mobile carriers
| (which control the SIM, the only other pragmatic trusted
| hardware).
|
| It would be amazing if there was a sort of "embeddable
| Yubikey" specification that would allow you to, logically
| or physically, install your own Secure Element/TPM and
| have that be decoupled from both OS and OEM, but it would
| be a major upstream effort.
| prophesi wrote:
| That's the point, if I'm reading this thread correctly.
| Google/Apple/Microsoft's implementation will be going out
| of their way to tie it specifically to a device and
| biometrics.
| lxgr wrote:
| In fact, Google and Apple have recently started
| synchronizing Passkeys to the user's cloud account, which
| effectively undoes any specific device binding.
|
| As a Relying Party, you can't know what authentication
| method will be used for either enrolling a new device, or
| on the new device itself.
| afavour wrote:
| Isn't tying specifically to a device and biometrics the
| point?
| josteink wrote:
| No. The point is replacing passwords with something which
| is equally user-friendly, but which cannot be phished.
|
| Ie replacing passwords with cryptographic keys tied to a
| specific website.
|
| That is, your passkey for amazon.com won't work on a
| phishers site amozon.com or lookalike.somehost.org.
|
| And in the hypothetical case of your passkey for site X
| being leaked it will never be the same as for site Y, so
| it's not reusable.
|
| No part of the specification requires Google, cloud or
| third party trust. Those are just "user-friendly" client-
| side implementations.
| 0xCMP wrote:
| > No part of the specification requires Google, cloud or
| third party trust.
|
| AFAIK the only reason you need Google, Apple, or etc. is
| because the mobile OS needs to make the process of doing
| the bluetooth pairing between a random device and the
| phone seamless. Given the crap networking we have in the
| world you need a 3rd party everyone can reach to exchange
| the most basic information. Then everything is local via
| Bluetooth.
|
| > The point is replacing passwords with something which
| is equally user-friendly, but which cannot be phished.
|
| Yes, and biometrics (which pretty much everyone uses) are
| great! They're device ONLY. It's entirely a convenience
| feature that avoids needing to enter the Required To
| Setup PIN/Passphrase every time.
| danShumway wrote:
| > which is equally user-friendly, but which cannot be
| phished.
|
| This is good to bring up. Without vendor lock-in and
| attestation, passkeys have huge benefits for blocking
| phishing attacks. It's not "stick with passwords" or
| "deal with lock-in", it's possible to get rid of the
| current problems and still end up with a system that's
| way more secure than traditional passwords.
| ezfe wrote:
| Yes, Google/Apple/Microsoft are likely to tie it to
| device biometrics, but:
|
| - 1Password is rolling out Passkey support next month
|
| - Apple is on the record stating that passkey
| import/export is on the roadmap
|
| You can already use the 1Password demo and export the
| passkey it generates and see the raw data.
| prophesi wrote:
| Glad to hear Apple's allowing import/export. The issue I
| was thinking of is setting up passkeys for your phone and
| now you can't use it on desktop, or switching to
| Android/iOS and it can't carry over.
| wepple wrote:
| I don't necessarily think OP believes this point of view, but
| even HN folks seem to think passkey is some wild biometric
| stealing mega Corp conspiracy.
|
| See a lot of the comments in this thread as an example:
| https://news.ycombinator.com/item?id=35801392
| signal11 wrote:
| > HN folks seem to think passkey is some wild biometric
| stealing mega Corp conspiracy.
|
| What it does is promotes further centralisation, because
| most users will use one of the big providers.
|
| This wouldn't be a problem either, except that the big
| providers are not _accountable_. Google, Meta, etc lock
| users' accounts all the time. Users often have no recourse.
|
| Passkeys will mean a locked Google account now impacts your
| ability to sign into all the sites where you used that
| passkey.
|
| Think it can't happen to you? "Oh Google won't lock my
| account out!" That's exactly what those locked out thought
| too.
|
| The fundamental problem with Passkeys isn't technical. Even
| ignoring the centralisation issue, the problem is a lack of
| organisational accountability on the part of Google, Meta
| etc.
|
| And yeah, the tech industry, including the tech press,
| needs to own the fact that they've given these companies a
| free pass over this.
| cyphar wrote:
| But I don't see how passkeys factor into this discussion
| at all. Yes, large companies are unaccountable and they
| do harmful things to their users without recourse. This
| is unrelated to the method you use to log into
| microsoft.com.
|
| _WebAuthn is not Single Sign On_ (where you are
| centralising logins) -- it seems a lot of people on HN
| think that it is. I don 't like SSO as the only option
| for a site (precisely for the centralisation reasons),
| but that's very explicitly not what WebAuthn is. The test
| page for WebAuthn (on their site) is completely self-
| hosted and every site I've seen that supports WebAuthn
| self-hosts it.
| jtbayly wrote:
| Just to be clear, because I do t know the answer to
| this... if Google locks your account, can you still use
| your Android device to login with a passkey to that other
| site?
| growse wrote:
| I guess that'll depend on whether you phone still
| functions if Google dlocks your account.
|
| But worst case, yes, but only in the same way that if you
| put all your photos on Google photos and then they block
| your account, you won't have access to your photos any
| more.
|
| If that's a concern, then _don 't do that_.
|
| I think the passkey design actively encourages sites to
| support multiple authenticators, so you just enrol your
| yubikey as well as your phone and you're good.
| jtbayly wrote:
| So what I hear you saying is that if a _normal_ person
| gets locked out of their Google account, they will also
| be locked out of every other website they have accounts
| with.
|
| Yikes. I guess I'll be telling everybody to stay far away
| from passkeys.
|
| *By "normal," I mean the people who don't have yubikeys,
| like myself. Lol.
|
| Edit: wait, what do you mean if your phone still works?
| Also, does this mean if you lose your phone you can't log
| into anything? How do you recover from that?
| growse wrote:
| > So what I hear you saying is that if a normal person
| gets locked out of their Google account, they will also
| be locked out of every other website they have accounts
| with.
|
| > Yikes. I guess I'll be telling everybody to stay far
| away from passkeys.
|
| This is a bit like telling everyone to stay away from
| password managers, just because Google offers one with
| Chrome that potentially disappears (taking all your
| passwords with it) when they nuke your account.
|
| No, passkeys are fine. Just don't rely on a single,
| central provider who you consider an adversary.
|
| > Edit: wait, what do you mean if your phone still works?
| Also, does this mean if you lose your phone you can't log
| into anything? How do you recover from that?
|
| If you lose your yubikey/Google authenticator/whatever
| TOTP, you're in a similar pickle. So then you do account
| recovery (recovery codes etc.)
| signal11 wrote:
| > Also, does this mean if you lose your phone you can't
| log into anything? How do you recover from that?
|
| If your passkey is tied to the phone (which will be true
| for most people), losing your phone will be an
| interesting experience.
|
| Assuming you remember your Google account password, you
| will have to buy a new phone.
|
| In many cases you'll need a new SIM or eSIM as well, eg
| if you have SMS based 2FA enabled. If you use Google
| Authenticator, your phone's gone, so you better have a
| fallback -- either SMS or fallback 2FA codes.
|
| If you need a SIM, and used Passkeys to login to your
| telco's online account ... um, tough. You'd better call
| customer support.
|
| Essentially, passkeys tied to one device is a house of
| cards. When things go wrong (eg you lose your phone or
| your dog chews your Yubikey) it's not pretty. But of
| course security pros know this, they have backups and
| spend time securing and testing the backups.
|
| Most ordinary users won't, of course.
|
| More interesting is the underlying assumption that your
| Google account works. If your stolen phone was used to do
| something shady or simply something Google's account
| protection systems don't like, your account may be locked
| out. At which point things get even more interesting.
|
| That said -- cross platform Passkeys should exist soon.
|
| 1Password is implementing Passkey support[1], hopefully
| KeePassXC will do it too, then users of those apps will
| be okay. But I've no idea how easy it'll be to move keys
| around.
|
| The spec really needs to support interop better, with
| formal import/export support. You shouldn't be able to
| say you support PassKeys if you don't support
| import/export.
|
| But of course even then, most users won't export or back
| up their keys -\\_(tsu)_/-
|
| [1] https://www.future.1password.com/passkeys/
| signal11 wrote:
| The parent comment I replied to brought up passkeys,
| trying to paint criticism of it as "conspiracy".
| cyphar wrote:
| Is "passkey" not another word for a WebAuthn/FIDO token?
| [deleted]
| signal11 wrote:
| They're similar but differ in some important ways[1].
|
| Passkeys were built on top of work done by FIDO though.
|
| [1] https://css-tricks.com/passkeys-what-the-heck-and-
| why/#the-d...
| throwaway2056 wrote:
| > What it does is promotes further centralisation,
| because most users will use one of the big providers.
|
| Because there are no easy non-centralised solutions (that
| works for Average Joe)?
|
| Remember
|
| Average Joe cannot
|
| - backup keepass
|
| - 3-2-1 backups using ZFS
|
| BTW, if so many average Joe's lost google accounts then
| there would be outrage and great chaos (like ticketmaster
| etc). So some people lost Google accounts - true. Same
| some people list U2F key.
|
| > the tech industry, including the tech press, n
|
| Pragmatism will win.
|
| This reminds me of IRC vs WhatsApp (or Signal). People
| want things to be simple.
| signal11 wrote:
| > BTW, if so many average Joe's lost google accounts then
| there would be outrage and great chaos (like ticketmaster
| etc). So some people lost Google accounts - true. Same
| some people list U2F key.
|
| They don't "lose" Google accounts or Meta accounts or
| whatever. They're locked out. In many cases, it appears
| lockouts can be triggered even by external events,
| including bad actors. Most companies are famously opaque
| on how lockouts happen, but there's enough affected users
| out there to start forming some hypotheses.
|
| Your argument is that the failure rate is so small, it
| doesn't matter. "We'll worry about it when the failure
| rate increases."
|
| This is what _lack of accountability_ looks like, because
| you're completely oblivious to the human consequences of
| even one failure.
|
| Organisationally, companies like Google or Meta want
| billions of users, and want to manage the keys to their
| users' digital universe, but don't want to put in decent
| redressal processes for when things go wrong.
|
| It's not a tenable situation. Either the public will need
| to reevaluate how much they can trust big providers, or
| big providers might find legislation or legal action
| directing them to do better.
| danShumway wrote:
| > People want things to be simple.
|
| As a reminder, if you ask what the best way is to back up
| a Yubikey, the advice is:
|
| - Buy a second Yubikey
|
| - Store it in a separate physical location, preferably
| within a fireproof safe
|
| - Whenever you make a new account, set yourself a
| reminder to go get your second Yubikey, log in with the
| first Yubikey and then go through whatever process the
| site has (on a site-by-site basis without a consistent
| UI) and add the second Yubikey as another credential.
|
| - Then go back to whatever secondary location you've
| chosen and put the second Yubikey back.
|
| - And then repeat that process every single time you make
| a new account.
|
| In contrast, dragging a KeePassXC vault into a Dropbox
| folder one time and just _leaving it there_ and using it
| from Dropbox is incredibly simple and I feel like pretty
| much anyone is capable of doing that.
| cyphar wrote:
| If you don't need a proper second factor, just set up
| TOTP and store it in KeePassXC. There is little benefit
| to a WebAuthn/FIFO "key" stored in your password manager
| over a password manager with your TOTP stored in it --
| almost all of the benefits of WebAuthn (making phishing
| much harder) already exist with password managers that
| auto-fill.
|
| There are usecases where you need proper multi-factor
| authentication, and in those cases you are either a
| professional (meaning you can handle backups yourself) or
| you're working for a large company where the management
| of the keys is done by IT and normal workers don't have
| to care about it.
| danShumway wrote:
| I disagree that a proper key-based solution wouldn't have
| security benefits (auto-fill doesn't always work and is
| more vulnerable to phishing).
|
| But I also really want to be clear here that we are not
| talking about multi-factor authentication in the long
| run. The explicit goal of Google/Microsoft/Apple is to
| _get rid_ of passwords. Passkey is designed as a
| replacement for passwords. It 's not a replacement right
| now, but that is the intention, they are not thinking
| about having a Yubikey as a second-factor for login.
| throwaway2056 wrote:
| You are lucky if you find a mum with 3 kids or cafe owner
| or a fruit seller using TOTP in keepassXC. Do you know
| they would prefer a phone (not laptop/desktop)? They dont
| have laptop.
| throwaway2056 wrote:
| > Buy a second Yubikey
|
| I can (as a geek) but this is a problem for average Joe
| or a single mum with 2 kids.
|
| This is the reason even banks or <your employer> incl.
| Federal places uses Cisco DUO not an opensource solution.
|
| Most things are for average customer. passkeys are great
|
| - Assuming a person keeps one password (either Apple or
| Google OK)
|
| - Phishing for them is reduced
|
| - No need to squeeze brain for was it username or email
| address (for login field)
|
| - Most phones have fingerprint (even < $60 in developing
| world too with Android)
|
| - Passkeys work from Android 9 onwards
|
| - At the end some one needs to compromise.
| danShumway wrote:
| - And they can't move ecosystems.
|
| - And logging into your bank requires a proprietary
| device.
|
| Let's be clear about what we're "compromising" about. If
| passkeys are going to be a replacement for passwords (and
| Google/Microsoft/Apple are very up-front about the fact
| that they want passkeys to be a replacement for
| passwords) they have to handle all of the use cases. But
| even if that wasn't the case and they could just target
| the general consumer, the downsides here are not just for
| techy people. The platform lock-in will absolutely affect
| ordinary people as well.
|
| It'll mean that when your family member that doesn't know
| to make backups loses their iPhone, the _only_ way to get
| those keys back will be to buy another iPhone.
| dv_dt wrote:
| If they buy another iPhone, how do they authenticate to
| the cloud account? A password that hasn't been used in
| months or years? Standard credit collection agency data
| (which is stealable and has been stolen for many people
| already?)
| danShumway wrote:
| Yes, correct. Apple documents its restore process here:
|
| - https://support.apple.com/en-us/HT210217
|
| - https://support.apple.com/en-us/HT204974
|
| They also have account recovery processes which use
| metadata about you to try and verify your identity.
|
| Note, this is the system they are using _today_ for
| passkeys. So this is not some kind of compromise or
| complexity with password vaults that passkeys eliminate,
| it 's just the universal process of account recovery that
| we have today with all of its flaws, and passkeys don't
| add any additional protections or simplicity on top of
| this system.
| throwaway2056 wrote:
| > ecosystems
|
| A majority don't. A majority use their phones/banks
| rather than analysing ecosystems.
|
| > It'll mean that when your family member that doesn't
| know to make backups loses their iPhone, the only way to
| get those keys back will be to buy another iPhone.
|
| That is acceptable solution. Buy and then move on with
| life. Everything will be back after your shell out $$
| (android).
|
| But with local will the family member send the hard disk
| or USB disk containing keys to recovery? Which recovery
| company? Will they be honest?
|
| Whereas if you want to new phone - all works then easy.
|
| People want simplicity. Really thats it.
|
| (Again it may be sad for those that don't want to carry
| phone but the world is designed for average user).
|
| BTW, why do you thing banks are using proprietary device.
|
| Ask the HN -er to
|
| - make it possible using U2F or TOTP keys (QR code)
|
| - the same HN-user likes to implement flashy APP - so
| that they
|
| - track, help whatever
| danShumway wrote:
| > A majority don't. A majority use their phones/banks
| rather than analysing ecosystems.
|
| Is this intended to be an argument for my point or
| against it?
|
| The majority of people don't think about platform lock-in
| until it bites them, and money is tight and they can't
| afford to get an iPhone and then they sigh and buy one
| anyway because it's too annoying to switch.
|
| > That is acceptable solution. Buy and then move on with
| life.
|
| Like, you are laying out exactly how vendor lock-in
| happens, but your point seems to be that vendor lock-in
| is fine and we should just stop talking about it. "Yes,
| passkeys are vendor lock-in and I don't care" is maybe
| not as strong of an argument as you think it is? People
| like to be able to choose which phone they're going to
| buy.
|
| ----
|
| > But with local will the family member send the hard
| disk or USB disk containing keys to recovery
|
| No. They'll use Bitwarden or Dropbox and it'll be fine --
| easier than setting up a new phone. They won't need to
| wonder if their new phone is compatible with anything,
| they won't need to wonder about whether their computer
| will work or not. It'll just work, immediately, as soon
| as their password app is installed.
|
| Literally every single restoration/syncing option that's
| available for passkeys is also available for password
| databases, just as simple if not simpler. But you get an
| addition of a number of other simple solutions like:
|
| - if you lose your phone and show up to a friend's house,
| you can type a password into a web browser and get all of
| your passwords back instantly.
|
| - if you buy a windows computer and you have all of your
| passwords on an iPhone, you type a password into a web
| browser or an app and get all of your passwords back
| instantly.
|
| None of that is supported with passkey.
|
| Vendor lock-in does not make people's lives easier, it
| makes things more complicated. Do people really think
| that passkey is _easier_ to back up than Bitwarden is?
| throwaway2056 wrote:
| I understand your argument from a philosphical or
| idealistic view. You are correct
|
| People know Google/FAANG rather than bitwarden.
|
| If your family knows bitwarden then kudos. I am living in
| a different world.
|
| > Like, you are laying out exactly how vendor lock-in
| happens, but your point seems to be that vendor lock-in
| is fine and we should just stop talking about it. "
|
| - We can talk about it
|
| - And we are now.
|
| - But people in power don't understand (or care).
|
| There are no equivalent, easy option. I wish some company
| like proton mail or some one else would run a phone with
| all equivalent google services. But they don't.
|
| > They'll use Bitwarden or Dropbox and it'll be fine --
| easier than setting up a new phone.
|
| Are you sure? People would ideally like
|
| - Buy phone
|
| - sign in google/apple account
|
| - All apps installed and ready to consume/produce MEDIA
|
| > Do people really think that passkey is easier to back
| up than Bitwarden is?
|
| People think in different way. They know 2 things
|
| - Google/Apple username + password
|
| - get SMS recovery info (again I am not recommending -
| people are simplistic). May be you can replace this with
| some other option
|
| - For example, facebook allows for nominating a friend or
| a facebook for recovery
|
| - Enter the code
|
| - ready to consume/produce MEDIA
|
| > They won't need to wonder if their new phone is
| compatible with anything,
|
| Average Joe has brand loyalty so that they will stay in
| whatever. Usually. If one goes to Samsung, they usually
| stay there - even if Pixel is better.
|
| > They'll use Bitwarden or Dropbox and it'll be fine --
| easier than setting up a new phone.
|
| Where is the 2FA for dropbox or bitwarden? is that file
| supposed to be accessible without 2FA?
|
| I agree to your no-vendor lockin sentiment but this means
| some one should invest and build a platform neutral +
| verifiable thing.
|
| And even if some decent govt steps in people will claim
| it is all to track you. So EOF.
| danShumway wrote:
| > There are no equivalent, easy option
|
| Of course there is, the equivalent easy option is
| passkeys _without vendor lock-in_. Vendor lock-in does
| not make any of this easier or simpler.
|
| Also note that current platform-offered password managers
| already allow syncing to new devices, so even for the
| people who are saying "I only want to use my Google
| account", syncing passwords through their Google account
| to Android is just as easy as using passkeys would be.
|
| > Average Joe has brand loyalty so that they will stay in
| whatever. Usually. If one goes to Samsung, they usually
| stay there - even if Pixel is better.
|
| This is just not true. I see people switch ecosystems all
| the time, and when they refuse to switch ecosystems, the
| reason they usually give is "it would be too annoying to
| port everything." Lock-in is something that affects
| ordinary people, I see this all the time.
|
| > Where is the 2FA for dropbox or bitwarden? is that file
| supposed to be accessible without 2FA?
|
| Weren't you just arguing for simplicity? The average user
| doesn't use 2FA. They should, but they don't because it's
| too complicated for them.
|
| ----
|
| But this is silly, we've graduated from "people need a
| simple solution" to "any solution that involves anything
| other than a Google or iCloud account doesn't count as
| simple."
|
| Which, sure, if your definition of simple is _literally_
| "the passwords stay in your Google account" then only
| putting keys in a Google account will do. But it's a
| pretty tautological definition.
|
| And also a definition that doesn't hold up for ordinary
| users in my experience. People do actually understand
| that there are passwords for services other than Google
| and Microsoft because they interact with those systems
| today just fine. Pretty provably they can handle that
| level of complexity because that level of complexity is
| embedded in every single service that we use today.
|
| But let's assume you're right. Even under that criteria,
| even if your definition of simplicity is "I sign in with
| an Apple/Google password and that's _it_ , and it has to
| be specifically an Apple/Google password -- I want to re-
| emphasize that current password vaults with Google/Apple
| already handle this use case fine today just as simply as
| passkeys do, so there's still no extra simplicity or
| ease-of-use with passkey synchronization. At best, for
| those users it's _as_ easy to sync a passkey as it would
| be to use a password manager. But password sync to new
| phones on log-in is already supported natively if you use
| the native built-in password managers (ie, the same
| password managers you 'd be using for passkey).
|
| Even under the most restrictive criteria with the least
| possible number of steps for syncing -- password vaults
| can be synced just as easily if not easier than passkeys
| can be.
| rkeene2 wrote:
| The US Federal Government got rid of passwords in 2004.
| They use smart cards issued by approved issuers. They are
| certificate-based, so if you lose your card another one
| can be issued to you with the same properties on the
| certificate. Additionally, they usually escrow the Email
| Certificate private key.
|
| I maintain some open source middleware for these cards
| [0].
|
| [0] https://cackey.rkeene.org/
| sidewndr46 wrote:
| Having worked with the Federal government you are
| woefully misinformed. There likely is a policy statement
| announcing that passwords are being phased out, but I can
| assure they were alive and well past 2004.
| signal11 wrote:
| > At the end some one needs to compromise
|
| Sure. Google and Meta and similar companies can
| compromise by having proper redressal processes which
| will hold up in court, should they lock your account.
|
| Being an identity provider who can take away your
| identity _with no legal recourse_ is not legally tenable
| and _will_ be challenged legally.
|
| If you're an engineer working on this, expect to get beat
| up by the EU on this, to start with. There is a solution
| though -- build import & export into the spec and
| actually implement it well.
|
| Google actually has done a decent job with Google
| Takeout. It's worth learning from.
| fn-mote wrote:
| Ticketmaster outrage has exactly the same effect as
| complaints against Google.
|
| Average Joe has no idea whatsoever how to complain and
| get noticed. That's like saying "If shoplifting were so
| common there would be police in every store." Nope, it's
| just the cost of doing business.
|
| Cloud backup works for average users. That includes
| keypass. Heck, even HN users do it that way. The only
| difference is that we have 16 word DiceWare passwords and
| key files on YubiKey devices.
|
| The scariest problem to me isn't centralization, it's a
| lack of recourse when things go wrong.
| throwaway2056 wrote:
| > tcketmaster
|
| IIRC, nothing changed.
|
| Take for example practices of PayPal or VISA etc. Nothing
| changed.
|
| > Cloud backup works for average users. That includes
| keypass. Heck, even HN users do it that way. The only
| difference is that we have 16 word DiceWare passwords and
| key files on YubiKey devices.
|
| Sorry most HN users are the ones building closed systems.
|
| Sure, they work in FAANG for 10 years - get enough $$$M
| then sure complain things are NOT open.
|
| > it's a lack of recourse when things go wrong.
|
| but does it happen outside of banking etc. Most average
| Joe does not keep 10 year old email like a geek. They
| keep moving on.
|
| I am a 20 year veteran of linux user. Sadly and
| frustratingly
|
| - There is no easy open solution for google drive or docs
|
| - Dont ask average Joe to do hosting/nextcloud etc
|
| - I wish some one like FSF, Linux foundatation built some
| products that are usable (like firefox phone). Even
| during firefox phone sales, I found most of the EU devs
| were using for their daily use iPhone or expensive
| Samsung Galaxy. It is ridiculous to tell others to use
| 512MB or 1GB firefox phone when they used state of art
|
| - Even recently I wanted to implement something like
| Codeberg at a large University. No help from their side.
| hackernewds wrote:
| > are none are "multinational corps" in the derogative sense
|
| YET. Remember when LastPass was the second coming liberating
| us from the devils of Google passwords?
| danShumway wrote:
| It's a _huge_ first step, but only a first step.
|
| We still need:
|
| - Guaranteess that attestation won't be used to block KeePassXC
| from being used as an authenticator. ( _Edit: it 's been
| pointed out below that Apple is getting rid of attestation for
| its platform authenticators, and as far as I can tell that's
| true. Extremely big deal because nobody is going to want to cut
| off Apple keys, which effectively means those services can't
| require attestation. So assuming it is true (which it looks to
| be) this shouldn't be an issue._)
|
| - Support for platform authenticators on Linux for Firefox and
| Chrome (Chrome currently has "no plans" to support this).
|
| - Compatibility with other platform authenticators.
|
| That last point is possibly the biggest problem, and it's part
| of why I've been pushing that this needs to be part of the
| spec. Okay, let's say you can export and import from KeePassXC.
| To where? This is still going to be a situation where a family
| member tells me they're interested in switching to Android and
| I have to tell them that they'll have to one-by-one transfer
| their login information. This is still going to be a situation
| where if you export your keys from KeePassXC, you won't be able
| to _import_ them into anywhere. It 'll still be a situation
| where if a family member loses their iPhone and they haven't
| synced keys to other devices already, their only solution is to
| buy another iPhone like a good little consumer.
|
| That's not to say that an Open implementation of a platform
| authenticator doesn't matter. It absolutely does, it's just
| only a first step. We still need buy-in from the FIDO alliance
| itself that importing/exporting keys is an important part _in
| general_ of being a passkey provider.
|
| And we still need to see how the attestation situation is going
| to play out ( _see note above_ ) and whether there are going to
| be any consequences at all for sites that just try to block
| anything except mainstream devices ( _see note above, the
| consequence would be losing iPhone users_ ).
| lxgr wrote:
| Do Passkeys even support attestation? What would they even
| attest to, given that the credential is effectively not bound
| to any secure hardware?
|
| To my knowledge, Apple has ripped out their "anonymous
| attestation" service together with introducing Passkeys in
| iOS 16; before that, requesting attestation was an option to
| opt out of Passkey syncing (and create a device-bound
| credential).
| danShumway wrote:
| I'd love some kind of reference for this. I'm hoping you're
| right.
|
| My understanding is that iOS does still very much support
| attestation
| (https://support.apple.com/guide/deployment/managed-device-
| at...) but I would be very happy to be proven wrong about
| that. I think attestation is harmful and should never have
| been part of the spec.
|
| > What would they even attest to, given that the credential
| is effectively not bound to any secure hardware?
|
| Originally at least, passkeys did support attestation in
| the form of reporting which authenticator had issued the
| passkey. Again, I would love for that to change. If Apple
| went full-anonymous with its passkeys and did not even sign
| the request to verify it was coming from an Apple device,
| that would be a really big deal for me. It would
| effectively make it impossible for any serious service to
| block anonymous attestation.
|
| But my _guess_ is that they probably just eased up on the
| hardware part of it and that they 're still allowing
| requests to ask if the key is coming from an Apple device.
| Again, if anyone has documentation proving me wrong, please
| share it. I would love to check off the attestation problem
| from my list.
| morpheuskafka wrote:
| I think the use case for attestation is for devices that
| were designed to prevent key export, like YubiKey, that
| are selected by a corporation for internal use where they
| want to ensure that employees self-enroll only the
| approved authenticators.
|
| I don't see much reason for syncing platform
| authenticators to attest because the keys will ultimately
| wind up elsewhere beyond the attested device.
| danShumway wrote:
| I think that's something that I'd be fine with -- you can
| require a YubiKey (or similar) within an org if you need
| on-device credentials, but general platform
| authenticators and syncing authenticators don't provide
| attestation. So in practice your choice is to either:
|
| - require a roaming authenticator (ie, a hardware token)
| which can be enforced with attestation, or
|
| - don't use attestation
|
| I'd still like it to be reflected in the spec that
| platform authenticators should not support attestation,
| but it seems like a reasonable compromise to me.
| Enterprises still can do what they want and have strong
| security internally, but Netflix can't use attestation
| unless they're willing to force every one of their
| customers to buy a hardware token and to block web sign-
| in on Mac. Honestly, kind of a win-win for everyone
| (except for companies that wanted to abuse the spec).
|
| I'm not _against_ enterprise customers and orgs being
| able to control their own devices, I just want guarantees
| that the practice will stay within those companies /orgs.
| And restricting the capability to basically just roaming
| authenticators/hardware tokens seems like it would
| provide some guarantee.
| lxgr wrote:
| https://www.slashid.dev/blog/passkeys-deepdive/ talks
| about this, among others.
|
| I think Apple mentions it in a WWDC presentation as well,
| but I find it quite ridiculous to bury such a significant
| change in a video + transcript announcement.
| danShumway wrote:
| Well heck, I'm very happy you chimed in on this, thanks.
| Very happy surprise.
| lxgr wrote:
| To be honest, I think as it is, not providing attestation
| was the only way to not outright be in violation of the
| FIDO/WebAuthN specifications (which at the moment
| requires specifying whether a key is "stored inside
| secure hardware", for which there is no good answer for
| synchronized credentials), but I don't think we're in the
| clear yet:
|
| Nothing prevents the big platform players (who are major
| contributors to the WebAuthN specification) from
| introducing a new form of attestation that specifically
| allows expressing that a credential is synced. I could
| absolutely imagine this happening in WebAuthn Level 3,
| FIDO CTAP 2.2 etc.
| warp wrote:
| In my tests Apple refuses to provide attestation. I'm
| using Resident Key: required, User Verification: required
| and Authenticator Attachment left empty. With those
| settings registering a credential fails if I ask for
| attestation: "indirect" or "direct". Only "none" works.
|
| My theory is that setting Authenticator Attachment to
| "cross-platform" (yubikeys and such) or "platform"
| (touch/face ID) might block cloud-synced credentials, in
| which case perhaps attestation: "indirect" still works.
| But I'm just guessing, I haven't tried it.
|
| Or perhaps Apple anonymous attestation only works when
| using webauthn as a second factor (i.e. without Resident
| Key and/or without User Verification).
| lxgr wrote:
| I think Apple just scrapped it entirely with iOS 16 for a
| more consistent user experience.
|
| Unfortunately, this also makes it a dealbreaker for me -
| I _want_ some credentials to be device-bound and non-
| extractable.
| JohnFen wrote:
| > Unfortunately, this also makes it a dealbreaker for me
| - I want some credentials to be device-bound and non-
| extractable.
|
| Why do you need attestation to have that? You can still
| use a Yubikey and the like, if nothing else.
|
| Or do you mean that you want to force the users of your
| service to only use credentials that are device-bound and
| non-extractable, I suppose. But then I would ask... why?
| lxgr wrote:
| Both, actually.
|
| As an RP, due to regulatory or security requirements, for
| example:
|
| Knowing whether I need to worry about my users' iCloud
| and Google accounts having been taken over or not is
| important for accurately evaluating the security posture
| of any service built on Passkeys as an authentication
| factor.
|
| And as a user, I don't trust Apple's or Google's sync
| backends enough to store my most important credentials
| there. Especially iCloud is frighteningly easy to hijack,
| even with a recovery code in place (which ironically at
| the same time increases the chance I'll lock myself out
| as the legitimate user).
| danShumway wrote:
| > And as a user, I don't trust Apple's or Google's sync
| backends enough to store my most important credentials
| there
|
| I'm not sure everyone realizes that you don't get a
| choice whether or not Apple passkeys are synced to
| iCloud, you can't create a passkey from Safari unless
| iCloud syncing is turned on.
|
| Regardless of whether or not there's support for
| exporting/importing, you should as a user have the option
| to not send your passkeys to iCloud. That is a completely
| reasonable ask. There's really no system where
| synchronizing to the cloud and syncing between
| devices/ecosystems ought to be _required_ for the user. I
| want users to have that option and I have some
| disagreements about whether services should be able to
| block it, but I do want it to be an option rather than a
| requirement.
|
| My guess is that Apple is worried people will turn off
| syncing without knowing the implications, but... it
| should still be the user's choice. It's completely
| legitimate for someone to be annoyed about forced sync.
| salawat wrote:
| That vombined with the key-escrow for iCloud would be a
| deal breaker for me if I'm understanding you right.
| danShumway wrote:
| My main issue with attestation is that it's platform
| controlled instead of user-controlled and that it doesn't
| just bind a credential to a device, it binds an
| authentication mechanism to a category/subset of devices.
|
| If the attestation part was separated from the
| manufacturer and it couldn't be used to identify who made
| the device or what brand the device was or what OS it was
| running, and instead was just a completely randomized
| device key with no other information with only the
| restriction that it was hardware-bound, would that be
| enough to meet your use case or would the user being able
| to update the OS/firmware still be a problem for you?
|
| My problems with attestation in order:
|
| 1. Locking down the ability of the user to change the
| software/firmware.
|
| 2. Allowing the website to identify the
| device/manufacturer (and allowing them to restrict
| accounts to a subset of devices).
|
| 3. Not allowing the user to replicate/change the
| device/move the key.
|
| But 1 and 2 are the biggest issues I have, if they went
| away then 3 wouldn't be _as_ big of a deal to me. Not
| that I would be super-happy about it, I still don 't
| think it would be a good idea, but... it's comparatively
| less of a problem.
|
| I could imagine a version of this where you get one
| private key set on firmware/OS load for your device but
| it's completely random, and if you update the firmware
| and the integrity check fails the only thing that happens
| is that key changes to a new one and the old key is
| erased. So updating the firmware would invalidate the old
| login keys that were relying on attestation, but it would
| not make it possible for a site to block an un-Googled
| Android from making an account or to even know that you
| were using an Android/iOS device in the first place.
|
| Again, I don't think that would be a good idea, I think
| it would be introducing a lot of foot-guns that shouldn't
| be exposed to ordinary users, but I don't think it would
| be nearly as much of a problem as saying "we guarantee
| this is one of X devices in this hardware batch, and that
| the OS hasn't been customized."
| lxgr wrote:
| This would be great, but as it is, platform
| authenticators are effectively always a combination of
| trusted and untrusted hardware/software, since the TEE or
| Secure Element usually does not have user input/output
| capabilities and is relying to the application processor
| OS's integrity to some extent.
|
| Notable exception: Google's Protected Confirmation [1] -
| the signature format of that is not natively
| WebAuthN/FIDO compatible, though.
|
| [1] https://android-
| developers.googleblog.com/2018/10/android-pr...
| JohnFen wrote:
| > I think attestation is harmful and should never have
| been part of the spec.
|
| I agree. That it's part of the spec makes me nervous
| about the spec.
| eptcyka wrote:
| MS/Google/Apple could use a TEE to attest that the passkey
| is in fact coming from a device that is linked to your
| identity.
| lxgr wrote:
| That's what Apple used to do for actual device-bound
| credentials. Passkeys aren't that anymore.
| sebk wrote:
| The entire sync fabric would become the authenticator.
| Apple and Google could (but don't currently) issue
| attestation that the passkey ecosystem you're using is
| theirs for multi-device passkeys, and continue to use
| attestation for the specific hardware for DPK and single-
| device passkeys.
| sebk wrote:
| I don't think FIDO saying importing/exporting keys is
| important and them having to standardize it is the same
| thing.
|
| The first and most straightforward reason is that we have no
| standard for importing/exporting passwords in or out of
| password managers, yet we manage to export them just fine.
| Each vault has its own proprietary format that's simple
| enough for others to implement as well.
|
| But more importantly, WebAuthn makes assumptions about the
| characteristics of an authenticator at registration time.
| (And establishes continuity of those signals with DPK).
| Exporting it would be contrary to that.
|
| Instead, with all these password manager vendors not wanting
| to be left out, and a good portion of the userbase either not
| being entirely in a single vendor's ecosystem, I can see
| cross-platform virtual authenticators like KeepassXC here
| becoming more common, and I don't think it's unlikely that
| the OSs will offer APIs to back these keys with TPMs/Secure
| Enclaves, and will allow you to replace the built-in passkey
| manager with a third-party, much like they do with password
| managers today.
|
| I see it more in the purview of OS APIs than FIDO itself. The
| big, nontrivial risk here is that it involves establishing
| trust between devices across ecosystems so that they can
| share wrapped key material, and this introduces a vector for
| attacks. A user could more easily be tricked into trusting a
| malicious TPM that exfiltrates they passkeys, whereas single
| vendors like Apple can implement mitigations as long as all
| the devices are in their own ecosystem and they can use their
| own services for sync.
| danShumway wrote:
| > The first and most straightforward reason is that we have
| no standard for importing/exporting passwords in or out of
| password managers, yet we manage to export them just fine.
|
| Sort of. Passwords themselves are just text, and they can
| always be copied and pasted no matter what. But you're
| right that the full vaults themselves aren't standardized,
| and a requirement in the spec that authenticators just
| generally support export would be enough for me I think,
| even if it didn't specify a specific format.
|
| I do think specifying a specific format might be better
| though -- if we had standardized password vaults more,
| maybe the LastPass breach wouldn't have happened, and they
| wouldn't have assumed that encrypting site metadata/urls
| was optional. But I generally agree, supporting multiple
| export formats is fine as long as those export formats
| exist in some form.
|
| > But more importantly, WebAuthn makes assumptions about
| the characteristics of an authenticator at registration
| time. (And establishes continuity of those signals with
| DPK). Exporting it would be contrary to that.
|
| Well, that's the question though: _should_ it make
| assumptions about the characteristics of an authenticator?
| Embedded in that statement is the idea that sites should
| have more insight into my device than they 've ever had in
| the past. It's a huge expansion of the amount of
| information that a site has about where a user is logging
| in from. I don't know that I agree with that, and I think
| there needs to be more justification that having that
| information leads to practical increases in security.
|
| There are a lot of advantages to WebAuthn that have nothing
| to do with verifying the device. The biggest security
| increase from WebAuthn is the site identifying itself to
| the authenticator. The site getting information about the
| hardware is kind of secondary, and I would argue of much
| more limited value for security (but of high value for
| DRM/platform restrictions).
|
| Users can already get device-bound credentials without
| attestation -- they can get a Yubikey. So for users that
| want that extra security, options exist. But does it add
| tangible security for the _site_ to be in charge of that?
| Enough security to justify enabling some really pervasive
| DRM methods and device lock-down?
|
| > A user could more easily be tricked into trusting a
| malicious TPM that exfiltrates they passkeys, whereas
| single vendors like Apple can implement mitigations as long
| as all the devices are in their own ecosystem and they can
| use their own services for sync.
|
| I don't think I agree with this either. Any restriction
| Apple puts in front of iCloud recovery can be put in front
| of an export button. Any information that Apple asks you
| before syncing to a new iPhone can be asked before
| providing you with a backup file. And from an attacker's
| point of view, if I can attack the iCloud export function,
| I can also buy an iPhone and attack its device recovery
| process. I'm not sure there is much of a security
| difference here.
|
| I think that ship has kind of sailed as soon as we start
| talking about syncing passkeys between devices. I think
| this argument only makes sense if we get of sync entirely
| and say, "no, they'll be completely device-bound like a
| Yubikey." But if Apple is syncing keys between iOS and Mac,
| if it allows going even further and sharing them using
| AirDrop, we're well past the point of worrying about
| whether someone can trick you into exporting your passkeys.
| sebk wrote:
| WebAuthn goes to great lengths to preserve user privacy,
| much more so than past alternatives, so I don't think
| there's a expansion of information, especially when the
| device is probed for capabilities which is extremely
| pervasive with browsers today. There is some new info
| with attestation, but other than it not being very
| widespread in practice, attestation keys are shared by a
| minimum of 100k devices.
|
| In general, the intent of attestation seems to be
| enterprise use cases where companies want to issue
| authenticators that meet certain capabilities, and only
| allow those capabilities as attested by a trusted party.
| For instance, a company might mandate Webauthn with user
| verification for their internal systems, and they don't
| want an employee using a software based virtual
| authenticator that fakes UV and keeps key material in
| plain text, so they issue Yubikeys to their staff and
| only allow Yubikeys to be used for logging in (issued or
| otherwise, as the RP can't differentiate them). I have
| not seen a single instance of attestation being used to
| gatekeep access to an otherwise public service, but I'd
| like to see some examples if there are any. Enterprise
| attestation is a different beast, however, and can
| uniquely identify an individual security key, but this
| has significant management overhead and will not be seen
| outside of enterprise use cases.
|
| Now I understand you personally don't value attestation
| as highly as some other features of WebAuthn and that's
| fine, I'm on the same boat. However that's the nature of
| standards and how they come about, there's multiple
| interests in the working groups. It's hard to say what's
| the "biggest" security increase because that's entirely
| relative to the individual or corporation implementing,
| consuming, or standarizing the functionality.
|
| As to whether there can be a phishing-resistant trust-
| establishment mechanism, I absolutely agree that there
| can be. All I'm saying is that there isn't an
| interoperable one currently, and that it's hard to
| establish interoperability across vendors and without an
| online sync fabric (I'd presume most users would want to
| export key material to a file or otherwise not rely
| necesarily on a third party phone-home service to export
| keys). I also think that it exceeds the scope of FIDO and
| will have to be primarily OS-vendor-driven. For me,
| personally, this along with something like the recovery
| extension that Yubico is promoting is one of the
| potential future features I'm most excited about.
|
| Related, and for the other reason why import/export is
| hard, which is the reasoning about the ecosystem, I don't
| think that even with such a mechanism we'll ever be able
| to export keys out if iCloud Keychain and into KeePassXC.
| What will most likely happen is that credentials
| generated by KeePaasXC and backed by hardware, will be
| able to be imported/exported in/out of devices in the
| same trust circle, using a KeePassXC sync fabric as the
| sync mechanism.
| danShumway wrote:
| > There is some new info with attestation, but other than
| it not being very widespread in practice, attestation
| keys are shared by a minimum of 100k devices.
|
| I would question whether 100k devices is actually a big
| enough pool to protect privacy. Regardless, that is "an
| expansion of information", right? It's a pretty decent
| fingerprinting vector to start with when combined with
| other device information.
|
| > For instance, a company might mandate Webauthn with
| user verification for their internal systems, and they
| don't want an employee using a software based virtual
| authenticator that fakes UV and keeps key material in
| plain text
|
| At the point where a company is in that position, they
| should be supplying their own locked down devices. This
| is an extremely narrow use case, much more narrow than
| "I'd like to be able to use this on a Linux machine." And
| the companies that are in that position have much greater
| resources to solve that problem by issuing dedicated
| hardware that's locked down in general. It doesn't need
| to be part of the spec.
|
| In practice, where this will be used most often is with
| banking apps, which I've argued elsewhere are not nearly
| responsible enough to be trusted with this extra
| information and are usually startlingly insecure. They
| can get on board with basic security techniques that the
| rest of the industry has already implemented before we
| discuss giving them more control over my hardware.
|
| People keep billing this as a compromise, but it's not
| really. The attestation proponents are asking for a
| capability that doesn't exist, they're asking for a level
| of insight into my hardware that login methods have never
| provided before. The status quo is "no, of course you
| don't get that." If they want to change the status quo,
| asking for "compromise" isn't the way to do it, providing
| real proof that it's not going to be abused (which, I'll
| mention in a second I don't think is safe to assume) and
| that it'll provide meaningful security increases is where
| they should start.
|
| > I have not seen a single instance of attestation being
| used to gatekeep access to an otherwise public service,
| but I'd like to see some examples if there are any.
|
| Continuing from the above, I've seen both intent
| (https://developer.apple.com/forums/thread/708982) and
| practice
| (https://arstechnica.com/civis/threads/passwordless-
| google-ac...).
|
| Also attestation in the form of SafetyNet (https://develo
| per.android.com/training/safetynet/attestation) and the
| more recent Play Integrity API has been used for DRM in
| plenty of instances, even for very trivial services like
| Netflix. So it seems pretty reasonable to extrapolate out
| that services that already use attestation for DRM today
| are going to use it when it's available for WebAuthn.
|
| The default assumption ought to be that this is going to
| be abused. Every instance of attestation in the past has
| been abused. Why would we just assume that suddenly
| companies are going to be nice about it?
|
| > However that's the nature of standards and how they
| come about, there's multiple interests in the working
| groups.
|
| Right, and the way you force that collaboration is by
| refusing to go along with standards that are harmful. I'm
| not part of this standards process, it's _their_ job to
| build a standard that appeals to me if they want me to
| use it. If they can 't do that, then I won't use it. And
| I'll advise other people not to use it and I'll tell
| people (truthfully) that I believe it's a harmful
| standard. As users/stakeholders, we force collaboration
| by laying out very clearly where our limits are so we can
| focus on finding solutions that solve multiple use-cases.
|
| I'm willing to compromise on a lot of stuff. Not this. If
| the big stakeholders also aren't willing to compromise on
| it, then we'll stick with passwords. That's fine with me.
| The FIDO group doesn't have an inherent right to have
| people pay attention to them. It's their job to come up
| with a standard that's good enough that people want to
| pay attention to it.
|
| > All I'm saying is that there isn't an interoperable one
| currently, and that it's hard to establish
| interoperability across vendors and without an online
| sync fabric
|
| Some of us would argue that is also entirely the FIDO
| Alliance's problem to solve given that they exist to
| build the FIDO standard and are the most invested party
| in getting the rest of us to adopt their solution.
|
| Normally when people get together to build Open
| standards, they _start_ with an Open implementation as a
| proof of concept. FIDO Alliance seems to be under the
| impression that it 's everyone else's problem that nobody
| has built an Open implementation of their "Open" spec
| _for them_. That 's just not how this should work.
|
| > and will have to be primarily OS-vendor-driven
|
| It's a good thing that all of those OS-vendors are part
| of the FIDO Alliance and are currently involved in a
| process that provides them with a great opportunity to
| sit down with each other and hash this out then.
|
| > What will most likely happen is that credentials
| generated by KeePaasXC and backed by hardware, will be
| able to be imported/exported in/out of devices in the
| same trust circle, using a KeePassXC sync fabric as the
| sync mechanism.
|
| That wouldn't solve any of my problems; the sync fabric
| isn't the important part -- I want to control my own
| keys. What does an "Open" sync fabric that restricts keys
| to specific devices even look like? That's certainly not
| Open in the sense that I control the sync fabric or can
| compile/change it myself.
| sebk wrote:
| 100k devices is the minimum. Also I already agreed that
| this is an expansion of information, were it to be
| requested in practice and the user chose to provide it.
| And I don't believe the use case for attestation in
| enterprise settings is narrow. For the "own locked down
| devices" is that Enterprise Attestation exists, which has
| management overhead in both its configurations, wheras
| normal attestation does not.
|
| I can't comment on the intent link, as there's no
| information. But the "practice" link is simply incorrect.
| Google does in fact allow a Yubikey to be used as a
| passkey, I have one configured myself. It shows up as
| "FIDO2 security key". What I assume is happening in that
| link you sent is that the user's yubikey does not have a
| PIN set for the FIDO2 interface, which means that it
| can't provide user verification and therefore is not a
| passkey as far as Google is concerned. This is the kind
| of reasoning about the capabilities of the authenticator
| that I was talking about, and it doesn't have to do with
| attestation.
|
| > it's their job to build a standard that appeals to me
| if they want me to use it
|
| They're appealing to OEMs, vendors and service providers
| as well. I also don't quite see how merely _having_
| attestation in the standard is harmful. RPs and users can
| chose not to require or provide it. If RPs decided they
| needed it for malicious purposes, would not having it in
| the standard suffice for them to be benign?
|
| > That wouldn't solve any of my problems; the sync fabric
| isn't the important part -- I want to control my own
| keys.
|
| It would, because then the sync fabric is free to provide
| you with an exported version that's wrapped in a key of
| your choosing. It's open in the sense that any one
| software can import/export keys out of hardware devices
| that are currently restricted to the hardware vendor.
| danShumway wrote:
| > This is the kind of reasoning about the capabilities of
| the authenticator that I was talking about, and it
| doesn't have to do with attestation.
|
| It seems like it does though... correct me if I'm wrong,
| but attestation is how Google knows that it's a Yubikey
| and that it doesn't have a PIN/biometrics set. And in
| practice, it's not allowed to be used to provide user
| verification; there's a restriction on functionality.
| Yes, you can use it as a Yubikey, but you can't use it
| for the new passkey system.
|
| > For the "own locked down devices" is that Enterprise
| Attestation exists, which has management overhead in both
| its configurations, wheras normal attestation does not.
|
| Good? Attestation should have an overhead. Getting rid of
| the overhead is exactly what I don't want. You can have
| attestation today through existing methods, and they're
| basically sufficient for enterprises that need them. It
| costs a bit of money, which is good because it'll force
| enterprises to think about it. And importantly, it
| doesn't really work for restricting _consumer_ accounts,
| it 's mostly useful for orgs where devices are
| controlled. Which is again, good, that's the best
| outcome. Enterprises can restrict their devices, but
| there are barriers to entry that prevent those
| restrictions from being applied to general consumers
| using their own devices.
|
| The other thing you can do if you don't want to go the
| hardware route is you can have a custom login app for
| your enterprise. You shouldn't, you should provide users
| with devices if you're going to restrict those devices --
| but there's nothing stopping an org from having a custom
| authenticator that works outside of the standard.
|
| The only problem they'll have is if they want general
| users _outside_ of the org to install that app just to
| log in. Which again, is very good. It 's good that you
| can build a custom solution for within an enterprise, but
| that there are significant challenges in front of trying
| to force that solution on regular users.
|
| Heck, you can even use the Play Integrity API to help.
| Should the Play Integrity API exist? No, probably not.
| But it does and it's usable for dedicated authenticators,
| so we certainly don't need _another_ solution on top of
| it.
|
| This is a rare use-case, and it's probably fine for the
| orgs that need it to use something other than passkeys.
| There's no real danger to them of lock-out, they're
| already doing this today so they can just keep doing what
| they're already doing.
|
| > I also don't quite see how merely having attestation in
| the standard is harmful.
|
| Because every single time that we've had attestation in
| the past -- literally every single time -- it's been used
| for DRM. Hopefully this conversation doesn't matter
| because Apple is just blocking attestation, but what do
| you see in the industry that makes you think this time
| would be different? Has something radically changed at
| Netflix over the past couple of years?
|
| When has attestation ever not been abused?
|
| Here's the Chromium team expressing similar fears:
| https://www.chromium.org/security-keys/ Are those fears
| unfounded? I don't generally assume that Google is going
| to be leading the charge on user freedom, and if even
| they are kind of creeped out about the potential here,
| then I trust that there's a real risk of abuse.
|
| > It's open in the sense that any one software can
| import/export keys out of hardware devices that are
| currently restricted to the hardware vendor.
|
| Right, but if you're talking about trusted devices,
| unless that's something the _user_ controls, exporting
| /importing doesn't matter. The point is that the user
| should be able to export their key and import it to any
| authenticator they choose without fear that their
| authenticator is going to be blocked from logging in to a
| service.
| sebk wrote:
| Attestation doesn't carry that information. Also consider
| that Apple zeroes out attestation for its devices and
| works just fine with Google as passkeys. What's happening
| here is that when an RP is registering an authenticator,
| it can include a property that's called userVerification
| which in a Yubikey is backed by a PIN, and Google sets it
| as required. The restriction in functionality that you
| mention is exactly what Google wants though, but not for
| malicious purposes. Google doesn't want someone stealing
| your yubikey and having that suffice to log in to your
| account. They want user verification so that if that
| Yubikey is stolen, an attacker also needs to know the
| PIN, thus providing two factors. Again, Google does not
| prevent you from using Yubikeys. It prevents you from
| using security keys that aren't configured for user
| verification, and they don't do that through attestation.
|
| > Right, but if you're talking about trusted devices,
| unless that's something the user controls,
| exporting/importing doesn't matter. The point is that the
| user should be able to export their key and import it to
| any authenticator they choose without fear that their
| authenticator is going to be blocked from logging in to a
| service.
|
| No, not just physical devices. Anything that represents a
| device with a wrapping key. That could be a software
| implementation that's just a file you control. What I'm
| saying though is that for the _general case_ which is
| what a standard is concerned with, we won 't see the
| standard-mandated ability to export passkeys across sync
| fabrics. I don't see a world where you can export
| passkeys from Apple iCloud Keychain and import them into
| Google Password Manager. But I do see a world where you
| create passkeys in your Mac with KeePassXC, and can use
| an open sync fabric from KeePassXC to sync them to your
| Android device, and a flat file as well, and I believe
| this will happen not under the purview of FIDO. Whether
| those flat files can then hop on to another sync fabric
| (say, 1Password) to later be imported into hardware
| devices will definitely not be a part of a standard, but
| given the analogy to password managers, it doesn't
| matter; those capabilities can still be built.
|
| As far as the Chromium post, I find that one slightly
| more dystopic than attestation as a feature. They say _If
| Chrome becomes aware that websites are not meeting these
| expectations, we may withdraw Security Key privileges
| from those sites_ , and similar other warnings. They
| don't say that they will warn users, they say that they
| will withdraw privileges. Do you want your browser
| deciding for you what websites you can log in to?
| JohnFen wrote:
| > Google doesn't want someone stealing your yubikey and
| having that suffice to log in to your account.
|
| But it's not Google's place to make that decision for me.
| danShumway wrote:
| > Also consider that Apple zeroes out attestation for its
| devices
|
| This may be the saving grace because it may end up being
| that whether or not attestation is part of the standard
| doesn't matter because companies won't be able to use it.
| But it doesn't mean that attestation is harmless, it
| means that we're very lucky that (for now) Apple is
| deciding to effectively make it impossible for a
| commercial service to actually use it reliably.
|
| > It prevents you from using security keys that aren't
| configured for user verification, and they don't do that
| through attestation.
|
| Fair point, I don't know that this is actually using
| attestation and that it's not just the Yubikey reporting
| back that it doesn't support that field. I do quibble
| somewhat with "they're not blocking Yubikeys, they're
| just blocking <description of a Yubikey>." But... yeah,
| I'll grant you're probably right that this is not using
| attestation.
|
| > I don't see a world where you can export passkeys from
| Apple iCloud Keychain and import them into Google
| Password Manager.
|
| That's exactly what I mean when I say it wouldn't be
| sufficient. When I talk about syncing, I'm talking about
| transferring into and out of ecosystems, not just
| specific devices. What you're describing is a system
| where I can use the KeePassXC ecosystem to use keys
| across multiple devices. But I can't transfer those keys
| out of the KeePassXC ecosystem (unless hopefully other
| vendors like 1Password add support), and if someone
| starts using iCloud, they're stuck with same vendor lock-
| in.
|
| This is effectively saying, "you'll have a closed
| ecosystem for most people, but people who know enough
| beforehand to avoid it can somewhat avoid it." We should
| expect better from a standards body that purports to be
| building an Open standard.
|
| I really don't see how this is an out-of-scope problem
| for the FIDO Alliance. They have input from every single
| major OS. All of the players are in the same space. And
| their entire job is to dictate how this is going to work.
| I'm just asking them to do that job. A spec for
| portability is not that big of an ask compared to
| everything else they're already working on as part of
| this.
|
| It's not really that different than a spec for logging in
| using a standardized QR code, or over Bluetooth -- all of
| which was considered in-scope for them to to work on.
| Portability is just part of the general interoperability
| work that we should be expecting them to do.
|
| > Do you want your browser deciding for you what websites
| you can log in to?
|
| Of course not; in very typical fashion Google's solution
| to the problem may be worse than the problem itself.
| Google is very fond of recognizing that a feature is
| abusable and saying, "well, how about we prevent that
| abuse by giving ourselves even more capricious power?"
|
| But I do think it shows I'm not being paranoid, that this
| is a legitimate worry that even Google recognizes is
| worth worrying about. Google is part of the FIDO Alliance
| and it's not looking at attestation as a theoretical
| risk; it's looking at it as a very plausible risk that it
| needs to have policies around.
|
| Which I think is pretty reasonable given that every
| single instance of attestation in the past has been used
| for DRM, and there's nothing special about attestation in
| this spec that would stop that from happening. I really
| do think the burden of proof here is on you to describe
| why you think Netflix/Banks/etc... are suddenly going to
| act differently now than they have with every other
| attestation method they've had access to leading up to
| now.
|
| The only answer I can think of is, "they'll act
| differently because Apple is effectively killing
| attestation for platform keys for everyone." But that's
| not really a defense of attestation, it's just something
| to thank Apple for.
| sebk wrote:
| let me restate, they're not "blocking the description of
| a Yubikey" either. You can register one, and in fact I
| just did to try it out. The Yubikey needs to be
| configured with a PIN which you do through Yubikey
| manager. They're blocking authenticators that don't have
| additional protection other than just presence.
|
| > That's exactly what I mean when I say it wouldn't be
| sufficient
|
| I think we're confusing what the role of a standard is,
| versus what other features can be built around a standard
| capability. With an open fabric, vendors like KeePassXC
| can allow exports in formats that can then be imported by
| other sync fabrics as I described previously. The
| standard mandating it would be a good reason for vendors
| not to adopt the standard, or adopt a crippled version.
| Given the fact that WebAuthn ties capabilites to the
| authenticator at registration time I think it's
| understandable that vendors like Apple want give RPs
| assurance that keys are entirely contained in an
| ecosystem that guarantees those assertions. You will have
| _options_ , including not using Apple/Microsoft/Google's
| sync fabrics, and to move off these sync fabrics if you
| consider them insufficient, but not by exporting keys
| directly.
|
| > I really don't see how this is an out-of-scope problem
| for the FIDO Alliance (...) It's not really that
| different than a spec for logging in using a standardized
| QR code
|
| Logging in using a QR code or BLE is part of the hybrid
| transport in CTAP, which deals with how authenticators
| communicate with clients. It's very much within FIDO.
| Establishing trust between devices in different
| ecosystems to form a circle of trust so that key material
| can be shared doesn't really have anything to do with
| logging in to services, so it's not WebAuthn. It also
| doesn't deal with client to authenticator communication
| as there's no client. If anything, a standard like TPM
| (ISO/IEC 11889) is a better fit, but probably too low
| level for that exact use case.
|
| > Which I think is pretty reasonable given that every
| single instance of attestation in the past has been used
| for DRM
|
| Going back to attestation, I don't think that in general
| it's in the best interest of services to not allow you to
| log in to them, but I can see a bank in their typical
| backwards-fashion issuing some branded keys and only
| letting you use those (Symantec, I'm looking at you). The
| reality is that standard or not, if RPs want this
| functionality, it'll be there. Standards simply attempt
| to provide the bare minimum for interoperability that
| every party can agree to. The alternative is not an
| attestation-free world. It's a bank asking you to log in
| with a flawed key they purchased from an ancient vendor
| because there's no standard offering that does what they
| want. I'd much rather have a Bank of America branded
| Yubikey with enterprise attestation using WebAuthn than
| some weak and poorly implemented proprietary token like
| the ones they issue today.
| danShumway wrote:
| > They're blocking authenticators that don't have
| additional protection other than just presence.
|
| I know this isn't strictly attestation, but this _is_
| blocking authentication based on attributes of the
| device, correct? I 'm sort of quibbling over details here
| I know, but this is basically saying "we are checking for
| a pin protection or biometric protection and limiting how
| an authenticator is used based on the presence of that
| feature."
|
| > You will have options, including not using
| Apple/Microsoft/Google's sync fabrics, and to move off
| these sync fabrics if you consider them insufficient, but
| not by exporting keys directly.
|
| And that is a good reason to reject the standard as
| harmful.
|
| I'd love to use keys for log-in, it would be a huge boost
| to security. But if portability between sync fabrics as
| you call them isn't supported, then we can stick with
| passwords. I'm fine with that, and I think other people
| are as well. Ultimately, passkeys have to be better than
| what we have, and out of luck or history or whatever
| reason password vaults are extremely portable between
| different ecosystems. Even ecosystems that try to lock
| down passwords struggle to do so, because ultimately
| passwords are text and in the worst case they can be
| copied and pasted between managers. So if passkeys aren't
| similarly portable and they become another tool for
| holding people down into a single OS ecosystem (even if
| there are options that allow avoiding that), then they're
| harmful -- the security gains are not worth the downside.
|
| It does not address my concerns to say that a user who
| knows about the dangers of vendor lock-in in advance can
| avoid it in some situations.
|
| > Establishing trust between devices in different
| ecosystems to form a circle of trust so that key material
| can be shared doesn't really have anything to do with
| logging in to services
|
| It absolutely does, it dictates how that login
| information gets shared between devices. As far as I'm
| concerned it's just another part of transport.
|
| It's also relevant to FIDO in the sense that it is a
| _major_ barrier of entry to getting passkeys to be
| accepted by the general public. At the end of the day,
| the highest-level responsibility for FIDO is to figure
| out a standard that 's usable. The lack of portability
| keeps the standard from being usable. It is the single
| biggest complaint that people have about passkeys.
|
| Yes, that is a problem they should solve, particularly
| because everyone who would be required to be in the same
| room to solve that problem is currently in the same room,
| and all of them have a vested interest in getting rid of
| barriers to passkey adoption.
|
| Ultimately, does FIDO want this to be adopted by normal
| people or not? If the answer is yes, then portability is
| a problem they need to tackle. Again, every single
| company required to tackle this problem is currently a
| member of that alliance.
|
| > Standards simply attempt to provide the bare minimum
| for interoperability that every party can agree to.
|
| That bare minimum of interoperability _should not exist_
| for abusive uses of the technology. Like you said, there
| are solutions for this today. Companies that are abusing
| their customers should not get extra support from OSes
| and standard bodies to help them do it.
|
| Bank of America can already use a Yubikey today. Or they
| can use a poorly implemented proprietary token. And maybe
| if that goes badly for them, they'll use an actually more
| secure option instead of LARPing security.
|
| But look, this is exactly what people said about web
| video DRM, it's exactly what people say every time these
| conversations around DRM and fingerprinting come up.
| Companies are going to fingerprint your device anyway, we
| might as well give them a device ID for advertising.
| Companies are going to build weird browser extensions, we
| might as well get rid of them and make DRM part of the
| spec. It's really just an excuse, the standards make it
| easier to do this stuff. They're pursued because they get
| rid of the inconvenient parts of abusing users. And in
| doing so, they remove a barrier of entry that should
| exist.
|
| And integrating this into web browsers on _desktop_
| platforms is a huge gift to companies that want to do
| this. I already can 't use my bank's app on a deGoogled
| phone but at least I can sign in on a web browser,
| because in the world that currently exists attestation
| through a general web browser is just difficult and just
| annoying enough that my bank isn't willing to do it.
| Please stop trying to change that.
|
| When a company is doing something awful, it should have
| to leave the beaten path and work outside of the standard
| to do it. Because that helps us call out that they are
| doing something awful, and it helps us point to their
| solution and say, "no, that's not intended."
| sebk wrote:
| > but this is blocking authentication based on attributes
| of the device, correct?
|
| Not precisely. It's requesting capabilities that the
| Yubikey is not configured to deliver so the browser
| doesn't show it as an option. There is no attestation or
| in fact no signed communication other than the RP
| requesting it in the registration. I don't understand
| what your desired behavior is here. Do you want to log in
| to Google with a bearer Yubikey (what do you do when it
| gets stolen?). Do you want all FIDO2 keys to require
| PINs, even if they're being used in a traditional
| "something you have" 2FA fashion?
|
| > It absolutely does, it dictates how that login
| information gets shared between devices. As far as I'm
| concerned it's just another part of transport. (...) The
| lack of portability keeps the standard from being usable
|
| In the same way that a keyboard dictates how a password
| is typed. Transport has a very well defined meaning in
| FIDO and it's not about transporting key material but
| rather signed challenges and responses.
|
| Remember I'm suggesting a mechanism for open sync fabrics
| to exist, not the opposite. I simply don't see either the
| value in _mandating_ interoperable sync fabrics, or for a
| particular vendor in control of the ecosystem like Apple
| or Google wanting to weaken the security posture of their
| keys given how the standard works if they allow them to
| be exported. Also remember that the standard doesn 't
| just cater to users, it caters to these vendors
| implementing it as well, and more so.
|
| > it's exactly what people say every time these
| conversations around DRM and fingerprinting come up
|
| Except Webauthn doesn't have any fingerprinting
| capabilities beyond those in enterprise attestation (not
| regular attestation). In fact, it's much more privacy
| preserving that past alternatives. And fully realized,
| you wouldn't even need a username as an identifier with
| an RP that can be used to correlate you across services.
| danShumway wrote:
| > Do you want to log in to Google with a bearer Yubikey
| (what do you do when it gets stolen?)
|
| I'd like to have that choice, yes. I don't think it would
| be good to act on that choice, but... Google should not
| be in charge of the device I use to submit a key. I mean,
| you talk about scope of the standard, a pin is a thing
| that exists locally on my device that I use to secure my
| keys. It's a local security measure, not something that's
| part of credentials for the service.
|
| It's out of scope for Google to know anything about that.
| The scope of Google's login is the credentials that get
| submitted to Google. It's not really their business to
| know how my phone is locked (or by extension, how my
| passkey vault is locked).
|
| > In the same way that a keyboard dictates how a password
| is typed
|
| Well, the difference is that keyboards aren't currently
| blocking adoption of passkeys. Lack of portability is
| blocking adoption of passkeys. It's the biggest complaint
| people have.
|
| If keyboards were a huge problem that made it harder to
| use passkeys, yes, it would be in scope to figure out
| some kind of solution to mitigate that problem.
|
| > I simply don't see either the value in mandating
| interoperable sync fabrics
|
| Because until users are confident that interoperability
| is going to to exist (and not just for one or two
| solutions, but also for the big environments like
| iOS/Android), this is going to continue to be a huge
| barrier to adoption and people are going to continue to
| warn against the spec.
|
| The value is to address the complaint or people will keep
| complaining.
|
| > Also remember that the standard doesn't just cater to
| users, it caters to these vendors implementing it as
| well, and more so.
|
| Okay, then the users will stick with passwords. This is
| honestly kind of wild. The point of passkeys ought to be
| to make a usable solution for users. My heart bleeds for
| some of the richest companies on the planet, but they
| joined the FIDO Alliance, they wanted to build a usable
| standard. They signed up for this.
|
| I have a solution that currently works (password vaults),
| and they want me to get rid of my solution and use
| theirs. So convince me. If they don't cater to users,
| users won't use passkeys, and it'll go the same way that
| every other key based authentication method for the web
| has gone. Remember, this is not the first time that
| companies have tried to get rid of passwords. Building a
| solution that doesn't have major caveats is really
| important if they want a different outcome from the
| previous efforts.
|
| > Except Webauthn doesn't have any fingerprinting
| capabilities beyond those in enterprise attestation (not
| regular attestation) [...] In fact, it's much more
| privacy preserving that past alternatives
|
| Only if it doesn't use attestation and doesn't get your
| device pinned down to X in 100,000. But that's not the
| important part, the important part is that attestation is
| literally DRM.
|
| It is DRM to say "you will not be able to log into this
| service unless you're using a proprietary
| Apple/Android/Windows OS."
|
| And will companies do that? Well, every single instance
| of attestation pre-WebAuthn -- literally every single
| instance -- is being used as DRM today. And you want that
| in the browser? If my bank is already using this to block
| me from logging into an app unless I'm on a proprietary
| OS, then of course they're going to do the same thing
| with web browsers as soon as they have access to tools to
| help them do so. You have to understand that, you have to
| understand that absent some kind of force blocking them
| from doing so (again, thanks Apple) attestation in the
| browser is most likely going to mean that I can't log
| into my bank from a web browser unless I have a
| proprietary OS to act as the authenticator. That's the
| world we're talking about.
|
| Why wouldn't they use attestation here the same way as
| they've used every other attestation mechanism they've
| ever been handed? What is making you think that won't
| happen?
| sebk wrote:
| I think we both have exhausted our arguments regarding
| attestation. I understand why you don't want attestation
| to exist, and I believe you understand why I think it
| needed to exist in order for WebAuthn itself to exist.
| Like you, I hope it doesn't turn into a dystopia of every
| service requesting their own particular devices. So far,
| it doesn't look like it's going in that direction.
|
| > I'd like to have that choice, yes. I don't think it
| would be good to act on that choice, but... Google should
| not be in charge of the device I use to submit a key
|
| It's in Google's best interest to not damage their
| reputation with repeated break-ins to customer accounts
| and to reduce the overhead of an account recovery
| mechanism after an attack. It's the same rationale they
| use to not allow you to use "password" as a password, or
| why other services mandate 2FA. And again, Google isn't
| in control either, the authenticator is. Google (the RP)
| asks the browser (the client) for a user verification
| attribute. The authenticator is the one in charge of
| providing a response that sets that attribute. Without
| attestation, Google can't know if the authenticator did
| what it asked it to do.
|
| > I have a solution that currently works (password
| vaults)
|
| We're already seeing third-party sync fabric that don't
| use hardware elements without needing standard support.
| Dashlane already has it, 1Password is releasing it next
| month, and we're on a thread about initial support for it
| in KeePassXC. I'm sure soon after we'll see import
| capabilities for other password managers. Isn't this
| equivalent to the password manager you want to stick
| with?
|
| All the extra discussion is around backing those sync
| fabrics with hardware (which is what I think will exist
| but outside of FIDO) and mandating implementors to allow
| exports (which I don't think will ever happen, nor do I
| personally want it or need it).
| JohnFen wrote:
| > I also don't quite see how merely having attestation in
| the standard is harmful.
|
| Because having it there makes it an option, and I think
| that history is pretty clear that if you give the tech
| industry a bat, they will beat their users with it sooner
| or later.
| brookst wrote:
| > Guaranteess that attestation won't be used to block
| KeePassXC from being used as an authenticator.
|
| What would such a guarantee look like? It's very hard to
| promise that something will never happen.
|
| I guess some kind of industry standard for criteria that a
| pass key manager must meet, and platforms accepting pass keys
| would promise to support any system meeting those criteria?
|
| Trying to predict every future gets hard. There are unlikely
| but possible scenarios where we would want something like
| KeePassXC to be cut off (e.g. they or a similar product
| steals credentials).
| danShumway wrote:
| > I guess some kind of industry standard for criteria that
| a pass key manager must meet, and platforms accepting pass
| keys would promise to support any system meeting those
| criteria?
|
| Basically what I would want. Or (better) for attestation to
| just not be a part of the spec in the first place. I don't
| think services should have the choice of cutting off
| authenticators.
|
| See sibling comments though, if Apple refuses to support
| attestation for platform keys, then requiring attestation
| effectively means cutting off the iPhone market, which is
| the next best thing to getting rid of attestation entirely.
| wkat4242 wrote:
| Absolutely, this is the one reason I'm not interested in
| passkeys yet. I want to fully own my authentication keys
| myself. Not trusting Google or Microsoft for that.
|
| I hope it comes to zx2c4 pass too <3
| eptcyka wrote:
| With the sad state of PGP on Android, I hope someone picks up
| development on a viable alternative or ressurrects
| OpenKeychain. Currently, I cannot use my PGP keys because
| they're _too new_ on Android.
| wkat4242 wrote:
| I think OpenKeyChain is pretty great, I still use it.
| Unfortunately the authors went commercial (heylogin) and
| this is why they abandoned it. Their new products are very
| corporate and not interesting to me as an end user. But OKC
| is really necessary for my entire flow. I use it with
| password store, with termux (through OKCAgent) and some
| other things.
|
| I hope someone else picks it up too, but as long as they
| incorporate security fixes it's fine. I use yubikeys for
| the actual encryption anyway so the only risk is in the
| symmetric part.
|
| But what's the problem with your keys being too new?
| eptcyka wrote:
| My ed25519 keys can't decrypt my secrets due to a parsing
| error _somewhere_. I can still use okc-ssh-agent to SSH
| into places, but I cannot decrypt my passwords, which is
| kind of a big deal. It 's because of this I'll probably
| migrate to a self-hosted bitwarden and use FIDO auth with
| my yubikey. I'll still use the GPG key for SSH
| authentication, but boy is this a mess I don't have any
| time for.
|
| And when I say I don't have the time for, I tried to get
| OpenKeychain to use a newer version of BouncyCastle,
| which should support my encrypted files just fine, but
| boy do I not have the knowledge to deal with changes in a
| project's gradle structure. I think the root of the issue
| is that newer versions of GPG have changed the format of
| the ciphertext in a way that the bouncy castle version
| OpenKeychain is using doesn't parse. Anyway, I do not
| feel confident in mucking about in crypto code. Maybe
| there's hope in just porting a front-end of pass that
| uses a plain ported GPG implementation instead.
| snapplebobapple wrote:
| check out psono too for self hosting (https://psono.com/)
| It's on my todo to do this myself but I haven't had time
| yet. It looks a lot more interesting to me than self
| hosted bitwarden/vaultwarden though, especially if you
| have needs to fill like encrypted file storage that are
| slightly above and beyond bitwarden's design.
| fn-mote wrote:
| > I think the root of the issue is that newer versions of
| GPG have changed the format of the ciphertext in a way
| that the bouncy castle version OpenKeychain is using
| doesn't parse.
|
| It might be worth your effort to test your hypothesis
| with an older version of GPG. The LTS version would be
| especially easy to investigate.
| cyphar wrote:
| I don't understand which part of FIDO/WebAuthn requires
| "trusting Google or Microsoft"?
| speed_spread wrote:
| The part where they are the sole implementors of the spec.
| vladvasiliu wrote:
| What do you mean? I run Keycloak for my home lab
| authentication needs and can use my YubiKey as a Webauthn
| factor from Firefox running on my Linux PC.
|
| The only part where MS comes into the picture is the
| "Microsoft Windows" sticker on the bottom of the laptop,
| since HP shipped windows pre-installed.
| eulers_secret wrote:
| Even forcing people to buy yubikeys is an antipattern.
|
| We shouldn't be forced to spend money at _any_ company.
| Where are the Free (beer and Libre) methods??
| vladvasiliu wrote:
| There was a kinda-free option (as in you had to have an
| iPhone, but the app itself was free). Krypt.co had this
| based on the iphone's secure enclave. It was bought by
| Akamai, and it's not clear what state it's in.
|
| https://krypt.co/
|
| I think there was also an implementation for mac os based
| on the t1/t2 chip, but since I've never had such a mac,
| I've never looked properly into that. But that probably
| means that you could roll your own.
|
| A quick google search yields this for Linux with a TPM:
| https://github.com/psanford/tpm-fido
| account-5 wrote:
| Nothing unless they're on only ones to provide it, or their
| implementations are the only "trusted" or accepted versions
| third parties allow you to use.
| jerjerjer wrote:
| It is a very large and complex standard that further
| centralizes authentication in the hands of several
| megacorps. The previous OpenID attempt was a resounding
| success, and this is a logical continuation. Google and co
| want to know where you log in to serve you "better" ads.
| The countermeasure remains the same - create an isolated
| account on each new website/service you use.
| vladvasiliu wrote:
| But you can use FIDO without ever touching MS/Google. For
| example, Codeberg (code hosting based on some soft-fork
| of Gitea) supports this with local-accounts.
| cyphar wrote:
| What you are describing is Single Sign On, not
| WebAuthn/FIDO. Every site that I've used that has
| WebAuthn self-hosts it (GitHub, Twitter, Google,
| Microsoft, etc).
| stavros wrote:
| None, it's just misinformation.
| TacticalCoder wrote:
| I don't think it's misinformation. You may decide, on
| your own website, for your own users, to accept passkeys
| from everybody but others won't.
|
| Sadly enough it's a near guarantee that the less secure
| implementations of passkeys (the software ones, allowing
| cloning and backups in the cloud) are likely to be the
| most accepted.
|
| While actually secure implementation with the secret
| hidden deep down behind an HSM and never leaving it, made
| by smaller companies who do care about security, are
| likely to be rejected on the ground that it's too much of
| an "obscure" vendor.
|
| I already posted about it today but if you think about it
| it's literally insane that cloning was meant to be
| detectable (and detection was enforced and upon detecting
| a cloned key, one of the two keys would stop working) and
| that this feature has now been removed with the sole
| justification being: _" Because software backups to the
| cloud"_.
|
| It is not good.
| stavros wrote:
| I don't understand how what you say relates to what was
| said. You don't need to trust Google/Microsoft for your
| Passkeys, you can use a Yubikey, or whatever else you
| want.
|
| If Google wants to only accepts its own Passkeys to log
| in to your Google account, that's as much its choice as
| any other site has for its authentication.
| danShumway wrote:
| > that's as much its choice as any other site has for its
| authentication.
|
| A site having the technical ability to determine not just
| its authentication mechanism but how that authentication
| mechanism is stored is not its choice and should not be
| its choice and is not its business.
|
| And its a clear degradation in user freedom over
| passwords, a system where it's impossible for Google to
| dictate that you use only a specific password manager to
| store and sync that password. It shouldn't be possible
| for Google to know how I'm storing a passkey.
|
| It's not their right to decide anything about that.
| They've never had that right. We're not taking a freedom
| away from Google, we're saying that Google should not
| have the ability to take away a freedom that we've always
| had, because they're _our_ devices and it 's _our_ login
| information; it doesn 't belong to Google.
| rootusrootus wrote:
| I suppose the answer is to use Apple, then? It sounds
| like you have something against attestation, which is a
| reasonable point, and Apple doesn't support attestation
| in their implementation of passkeys. Given the size of
| their customer base, that pretty much guarantees that
| _nobody_ is going to be denying passkeys based on lack of
| attestation.
| danShumway wrote:
| Yeah, I wrote this comment before I knew that Apple was
| dropping attestation. Them dropping attestation kind of
| renders the entire conversation moot, practically no one
| is going to require it if it means cutting off the entire
| Apple userbase. It's good news.
|
| It's honestly kind of the best possible situation short
| of attestation being outright removed from the spec. My
| bank doesn't understand "I should be able to use real 2FA
| instead of a text message", but they will understand "I
| should be able to log in from a Mac."
| ridgered4 wrote:
| What would happen if Apple just started using attestation
| at a later date? It is still in the spec after all. I
| could see some services being willing to drop Apple for
| competitive reasons. ChatGPT only works on Edge browser
| at the moment IIRC.
| danShumway wrote:
| :shrug: that would be a very bad problem if it happened.
|
| Removing it from the spec would be better for precisely
| this reason, but making it harder to use is the next best
| answer. Bing AI's browser restrictions for example are a
| pretty big restriction on the service -- that comes with
| penalties that will discourage many sites from going down
| that route.
|
| If Google also drops attestation for synced keys then it
| would become even harder to use attestation, and harder
| for Apple to go back on its decision. But yes, you're
| right, it would be better to have stronger guarantees
| about the future.
| lxgr wrote:
| > A site having the technical ability to determine not
| just its authentication mechanism but how that
| authentication mechanism is stored is not its choice and
| should not be its choice and is not its business.
|
| If that site is legally held liable for fraud happening
| due to credential compromise, as (hopefully!) would be
| the case for e.g. consumer bank accounts, I'd say there
| is at least some legitimate interest.
| danShumway wrote:
| > If that site is legally held liable for fraud happening
| due to credential compromise, as (hopefully!) would be
| the case for e.g. consumer bank accounts, I'd say there
| is at least some legitimate interest.
|
| I kind of disagree honestly. I think consumer bank
| accounts are some of the least secure accounts I have
| online. My consumer bank account has removed 2FA options
| over time. They've literally gone backwards on security.
|
| I don't think there's much evidence that holding banks
| liable for fraud means that they're going to responsibly
| make their services more secure. Consumer banks in the US
| at least are wildly behind the times on account security,
| and I really don't trust them to make choices about what
| device I use.
|
| What I do think banks do is invest a lot of effort into
| _looking_ secure, and I think that stuff like attestation
| would (if supported) provide an easy mechanism for them
| to look secure at the same time that they allowed anyone
| to get into my account with just a social security number
| and my mother 's maiden name. So I feel like, don't even
| give them the option. There's so much they can do to
| improve security before we ever start talking about
| requiring users to use specific hardware devices. Let's
| have them catch up on basic industry practices before we
| have that conversation.
| lxgr wrote:
| This is certainly true in the US in my experience, but
| not everywhere globally.
|
| EU regulations require 2FA both for logins on unknown
| devices and for every transaction initiation (whether on
| a known/trusted or new session), for example. Often, this
| happens in the form of dedicated "authenticator apps"
| that currently take quite frustrating/ineffective
| security measures like trying to detect whether the
| device is rooted.
|
| Attestation could at the same time make this actually
| secure and give users more freedom to e.g. use whatever
| OS/mod they want to (since the actual root of trust would
| be an external authenticator or potentially their phone's
| TEE/Secure Element, not the OS).
| danShumway wrote:
| I guess if this was regulated to be optional or regulated
| in such a way that it could _only_ be used for keeping
| keys on-device and couldn 't be used for locking out
| other devices from making accounts, then I'd be OK with
| it.
|
| But we don't have those regulations in the US, and banks
| here shouldn't have access to this. We are so behind on
| security, it just doesn't make sense to give them yet
| another tool to lock down devices while they're ignoring
| everything else they could be doing. I would at least
| advocate for some kind of pact from FIDO Alliance members
| that attestation will only be implemented for devices
| sold in countries that have that kind of regulation.
|
| Or, maybe there's a way to do attestation where it's
| entirely user opt-in and isn't something that the service
| provider can dictate? Or maybe there's a way to do it
| where it can't be used to verify the OS/manufacturer
| during signup, and can only be used to verify that it's
| the same device where the credentials were created? I
| think I'd be OK with that existing.
| vbezhenar wrote:
| Are passkeys somehow signed by Google/Apple? I thought
| passkeys are like ssh keys.
| stavros wrote:
| They are, except they have a vendor ID that allows you to
| tell which vendor made the device you're talking to. You
| can get Passkeys by any number of vendors, but any
| authenticating website can decide to only allow a few
| vendors to log in with it.
| rootusrootus wrote:
| > any authenticating website can decide to only allow a
| few vendors to log in with it.
|
| That's an excellent way of telling your customers you
| want them to go somewhere else. What's the upside?
| stavros wrote:
| I'm not sure, it sounds silly to me. I guess you can
| mandate "secure" brands?
| lxgr wrote:
| Synchronized passkeys by both Apple and Google don't use
| that mechanism (attestation).
|
| There's also the AAGUID, but without attestation, every
| implementation is free to provide Apple's or Google's,
| should websites ever start requiring that.
| bheadmaster wrote:
| "It's just misinformation" is just fancy-speak for "it's
| bullshit". The former sounds pretentious and (wanna-be)
| authoritative. I personally prefer the latter form.
___________________________________________________________________
(page generated 2023-05-08 23:01 UTC)