[HN Gopher] Face ID and Touch ID for the Web
___________________________________________________________________
Face ID and Touch ID for the Web
Author : gok
Score : 378 points
Date : 2020-06-24 18:00 UTC (4 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| mtgp1000 wrote:
| No way this biometric data could possibly be abused, right?
|
| I'll stick to taping over my cameras, thanks.
| empath75 wrote:
| it never leaves your phone.
| mtgp1000 wrote:
| Yeah, and my personal data never left Equifax's servers
| either.
|
| You can't change your biometrics when they are inevitably
| hacked. If you even find out.
| orf wrote:
| I quite rightly trust Apple more than I trust Equifax.
| monocasa wrote:
| For all Apple's faults, they're pretty open about how their
| Secure Enclave works. I think they consider privacy to be a
| key differentiator, particularly when compared to Android
| and Windows. you can see this in how they didn't open a
| phone even given an FBI request.
| kohtatsu wrote:
| They didn't develop the capability to backdoor phones at
| the FBI's request.
|
| They are generally happy to hand over iCloud backups,
| which they did in that case and the FBI "lost" them IIRC.
|
| It was also an iPhone 5c, the last iPhone without a
| Secure Enclave, I believe they were able to get in with
| GrayKey.
| monocasa wrote:
| > They are generally happy to hand over iCloud backups
|
| That one they legally have to do when given a subpoena.
| Dahoon wrote:
| They could encrypt everything and not have the keys. So
| not really.
| monocasa wrote:
| The whole point of the backup is that you'll be able to
| access it even if you your device and it's keystore are
| destroyed.
| acdha wrote:
| Watch the video where he shows the JavaScript APIs being
| called: the website sees a standard public-key process
| using WebAuthn. You can use anything which can perform that
| protocol with zero change to the system -- if someone
| steals your phone, you don't need to change your face since
| the new phone will generate a new key and the biometric
| data is only used to unlock that key.
| ThePowerOfFuet wrote:
| PDF page 8:
|
| https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/ap
| p...
| ixtli wrote:
| Anonymous attestation is really interesting because, afaict,
| there really isn't a way to do this right now if my application
| wants to authenticate a "normal" user with a "normal" phone.
| EGreg wrote:
| What exactly does attestation do vs not having it? Can someone
| here explain clearly?
| tialaramex wrote:
| The attestation is a signed (digital) document saying basically
| "We are $manufacturer and we made this $product and we promise
| it has these desirable security properties".
|
| In WebAuthn the design is that a batch of (at least 1000 but
| usually far more) authenticator products should have such a
| document which Javascript can optionally request (together with
| proof they didn't just knock it off from another authenticator)
| when using the authenticator.
|
| If you demand multi-factor and aren't willing to take my word
| (as the user) that I'm using it, you could insist upon seeing
| the attestation and reject authenticators unless you can see
| the attestation and you like it. For example maybe Great
| American Bank accepts Yubikeys, but rejects the Apple iPhone
| because they believe Steve Jobs was Satan.
|
| Most sites should not use attestation at all. Firefox in
| particular can tell a site to fuck off when it asks for
| attestation. I'm happy to use high security WebAuthn but I
| don't want to have to tell you which products I use to do it.
| If your site does not _require_ WebAuthn for every user then
| almost by definition it makes no sense to demand attestation
| from users who choose to enable it.
|
| The use of "batches" is a privacy safeguard. If you permit
| attestation a site might know you have a Mattel Barbie
| Authenticator, but it won't know which one. If Mattel aren't
| selling many they probably put the same batch on the Buzz
| Lightyear Authenticator so a site can't even tell if you've got
| a Barbie or Buzz Lightyear.
|
| According to this video apparently (?) Apple thought that
| wasn't safe enough and so it has decided to do something else
| weird instead, but not yet. Whatever, for almost all web sites
| you should refuse attestation if given the option. _Maybe_ my
| bank needs to know I 'm doing MFA with a high quality product
| but there's no reason Facebook or GMail or anybody like that
| should ask.
| jacobr1 wrote:
| With passwords, the "proof" or "attestation" is that nobody
| knows my secret password. In practice this tends to be weak.
| Some reasons this is so includes:
|
| - the password is low-entropy/complexity, so it is guessable or
| brute-forcible. - the password is typed into the system, so
| keyloggers might observe it - the password might be stored
| insecurity by the server - the password is transmitted over the
| network and might be intercepted - the password is transmitted
| over the network, possibly to unintended recipients (like a
| phishing site) and thus is intercepted.
|
| One alternative is employing public-key/private-key crypto. The
| server sends some random data to the user. The user signs that
| data with their private key (this is the attestation part).
| Only the signed data, which is generated for this single
| authentication attempt is transmitted. And during registration
| only the public key is transmitted. The public key is used by
| the service to verify the attested data. The private key
| remains secret the entire time. Likely it remains secret even
| to the user's machine because it lives in separate hardware,
| such as a yubikey or secure-enclave. The key is also something
| that isn't going to be guessed because we are using modern
| algos with large bit-sizes.
| EGreg wrote:
| Sure but how is that different from JUST logging in with
| touchID or faceID? Without attestation?
| tectec wrote:
| Does anyone know if iOS devices support multiple users/bio
| metrics per device and could log a specific user in when they are
| using a shared device? I'm wondering if this could be used for a
| shared iPad on a factory floor to log users into their own
| account on our web app.
| turdnagel wrote:
| It's not really supported for Face ID - you can create an
| "alternate appearance" for Face ID but it doesn't work well if
| the people look very different. With TouchID you can register
| fingers from different people and it works fairly well, but
| again not really supported.
| jacobr1 wrote:
| Since we are really talking about WebAuthn and not just the iOS
| implementation, You probably could use alternative hardware
| (maybe android based) that supports the multiple-user biometric
| use-case. From the server/web-app side it still would just be
| WebAuthn.
|
| Looks like you use a separate device like this:
| https://www.ftsafe.com/Products/FIDO/Bio
|
| That supports fido2, hooked to any tablet to make it work.
| supernova87a wrote:
| So for the non-developer, is this basically as if any
| participating website could send an 2FA request to your iPhone
| (like the role of the SMS code but more secure), have the iPhone
| verify you by face/touch, and then confirm back to the website
| and let you in? (also like Google does with their app?). Or even
| take the place of a password?
| jacobr1 wrote:
| This really is just bringing WebAuthn to Safari. I've been using
| it via chrome w/ TouchID for our corporate okta SSO and it has
| been working great.
|
| WebAuthn is really just a way to make public-key/private-key
| crypto scale. The user never really knows about or interacts with
| the keys.
|
| The website doesn't store a password, they store a public key.
|
| The user doesn't know about the private key (paired to the public
| key) they just know how to unlock the private key via the yubikey
| or biometric device.
|
| The site sends some data to the user to sign, and they do so with
| the private key, then the site verifies the data was signed by
| the private key, boom: authenticated.
| sneak wrote:
| To think we could have had this a decade+ ago with TLS client
| certificates, if web browsers weren't perpetually stuck in the
| past.
| tialaramex wrote:
| Client certificates suck in a bunch of ways that WebAuthn,
| specifically designed to solve this problem, does not.
| Example:
|
| If the certificate used to sign into Hacker News as "sneak"
| is also used to sign into PornHub then I can correlate that
| to discern that "sneak" on HN uses PornHub. Whereas you can't
| do that with WebAuthn credentials - a separate credential is
| spun up for every single registration, it's completely
| useless everywhere except the one site it was issued for and
| can't be correlated to other credentials except via a
| cryptographic attack on the underlying primitives (ie
| breaking WebAuthn itself).
| ryukafalz wrote:
| There's no reason a browser couldn't have generated a new
| self-signed client certificate for each site, though; the
| fact that they don't offer that as an option is just a
| browser design decision.
| dividuum wrote:
| There was actually a <keygen> html tag used within
| <form>s to generate a keypair what was then supposed to
| be signed by the server and finally returned to the
| browser for local installation. At least that's how I
| understand it. It's been deprecated for a while now.
| ryukafalz wrote:
| Oh wow, yeah - I didn't realize that existed, and now I'm
| sad it never caught on. :(
| sirn wrote:
| ...which means a login is now tied to a browser, and you
| have to come up with a way to securely export or sync
| private key (bad idea?) or a way to link another browser
| to a login. Also user losing access to all their websites
| by accidentally uninstalling a browser doesn't sounds
| very user friendly.
| sirn wrote:
| How would you do the signing part though? Given that most CA
| don't do client certificate at all, nor it issue certificates
| with signing flags.
|
| Even if CA does sign client certificate, and website is
| expected to store its public key, it expose some privacy
| concerns since a public key is now Personally Identifiable.
| If a website must provide its own self-signed CA and require
| user to provide a CSR when registering for an account, then
| it becomes a huge overhead for both website and user to just
| login.
|
| I work with enterprise and the requirement usually requires
| client certificate. I never had a good experience setting it
| up even with a limited number of parties.
| snuxoll wrote:
| You don't need a public CA to do client certificate
| authentication. Hell, your computer doesn't even need to
| trust the CA that signed the key - it's the server on the
| other end that cares about that.
|
| This is precisely how WebAuthN works - but we figured out
| that we actually don't need to go through the headache of
| getting CAs and signing involved at all. Just store a
| public key attached to a user after they've signed in via
| traditional means and let the browser/security token manage
| the keys.
| acdha wrote:
| You have the blame misattributed: almost nobody used client
| certificates because they cost money ($100+/year). That meant
| there was little demand outside of a few spaces like
| government and absent usage there was not much pressure on
| the UI improvements.
|
| Client certificates are also worse for privacy and phishing
| resistance: with a certificate, if I can convince you to
| click on a link I get your identity. From the site's
| perspective, I don't have any way to tell whether the person
| with the certificate is the same person I saw or the person
| who compromised their computer or convinced a CA to issue a
| cert for someone else. Requiring key storage to be on a
| hardware enclave significantly reduces that risk, allows for
| the stronger attestation requirements mentioned, and also
| means that you're changing things from "trust anyone who can
| get a CA certificate" to "trust anyone who can do signatures
| from a previously-registered hardware key".
| 0x0 wrote:
| Cost money? Once upon a time, html had <keygen>
| cactus2093 wrote:
| How does this work if you need to sign in to a site on a
| borrowed computer while traveling or something? Is the private
| key derivable from a master password or something?
| jacobr1 wrote:
| A few options if you want to maintain MFA:
|
| For my Okta account, they support push notification to their
| app on my phone as an alternative authentication measure.
|
| Another approach is a bluetooth (or NFC) enabled device (like
| your phone) that actually caries the private key. When using
| a borrowed computer, the signed attestation data is shared
| with the borrowed system, but that can only be used once,
| since the private key is never transmitted.
|
| So basically you can either have a side-channel to another
| MFA method, or a relay where you don't need to trust the
| intermediary beyond the current session.
| namanaggarwal wrote:
| It's mentioned in the video as well that website should
| always use this as faster sign in option with providing other
| options alongside.
| sirn wrote:
| Similar to how you would sign in on devices/browsers without
| WebAuthn support or don't have physical token (Yubikey/etc.)
| with you: use a fallback method provided by a website. This
| is usually TOTP or a scratch code. The website need to
| implement it though.
|
| One thing to keep in mind is this is not supposed to be the
| only factor required to sign in. It should be used as a 2nd
| factor in the similar way to TOTP (but with much better
| usability).
| Skunkleton wrote:
| With Okta (since gp mentioned it), you would sign in with a
| password, then click the "yes its me" button on your phone,
| or you could use TOTP, or even a yubikey.
| sirn wrote:
| Okta is more of a SAML/OpenID Connect thing with built-in
| multi factor authentication than a replacement for
| WebAuthn, though. Okta could embrace WebAuthn Platform
| Authenticator as one of their authenticating factor if
| user is unwilling to install an app, but a website isn't
| expected to use Okta as a second factor in their
| authentication flow.
| jackson1442 wrote:
| OP is referring to how you already can sign in to Okta as
| a website, not as an authentication mechanism. You can
| create a sign in flow that goes like so:
|
| username -> password -> [ WebAuthn | Okta Verify Push ]
|
| This approach can be used on any website, just with a
| regular TOTP code in place of the proprietary Okta Verify
| Push.
| sirn wrote:
| Ah I didn't know you could do the Okta push without using
| their whole SSO suite. Thank you! I guess in this
| scenario Okta acts more like Authy proprietary OTP thing
| then.
| tomp wrote:
| Apple already kind-of supports this for iClout login. If you
| want to authenticate on a new device, you'll get a prompt on
| one of your _already authenticated_ devices to confirm the
| login. You still need the password, but it's really not
| necessary... if there was also some additional "privilege"
| system (i.e. that the same user account would have less
| privileges if logged in through a less secure method) it
| would be even safer.
| bfulgham wrote:
| You should pay special attention to the section about
| attestation, which is not something that is done in a privacy-
| focused way without an anonymous attestation authority (which
| is part of the iOS 14 feature)
| jiveturkey wrote:
| This has been a very long time coming. Apple finally joined FIDO
| in Feb of this year, so we knew it was right around the corner.
| adamleithp wrote:
| The keynote a few days ago failed to mention FaceID used to
| opening your mac... and this video shows/mentions FaceID on a
| macOS11 website?
|
| Seems they missed a step here with rolling it out, or are
| withholding the obvious. I'm assuming the latter.
| JimDabell wrote:
| This video shows Touch ID being used with a laptop, not Face
| ID.
|
| The interface is generic, so it should use Face ID on devices
| that have Face ID hardware, and Touch ID on devices that have
| Touch ID hardware.
| sirn wrote:
| Apple supports WebAuthn on iOS/iPadOS as well (since iOS/iPadOS
| 13) so presumably FaceID part is referring to iOS/iPadOS.
| paxys wrote:
| Happy to see Apple following an established standard for once.
| thowawaymom wrote:
| Don't mean to sound harsh, but is it just me or the speaker was
| borderline impossible to understand? What is that word again
| "authontication"?
| StavrosK wrote:
| If anyone wants to deploy this server-side, I made a Django
| library that's very easy to use:
|
| https://gitlab.com/stavros/django-webauthin
|
| You can see a demo login here: https://www.pastery.net/
|
| It allows the user to log in without a username or a password
| (untested on any Apple device as I don't have any, please file
| bugs if it doesn't work).
| xvector wrote:
| I think it's pretty ridiculous that Apple pours time and effort
| into stuff like this but apps have been able to steal from your
| clipboard for years.
|
| It reminds me of the phenomenon when researchers and engineers
| don't work on something that's useful for everyday users, instead
| prioritizing what they find exciting and cool. The security team
| is so busy dealing with absurd edge cases like nation-states
| attacking your enclave that they don't seem to care to address
| egregious and obvious holes in the security model like this.
|
| It's not that WebAuthn and passwordless isn't exciting or useful,
| it's just that there are much bigger fish to fry (clipboard
| paste, terrible permissions management, non-shitty VPN support,
| trackers in apps) that Apple seems completely uninterested in
| addressing.
|
| There really is no excuse, at least not when you're tooting the
| privacy/security horn so loudly, but let stuff like this pass by.
|
| Edit: have y'all thought of an actual counterargument instead of
| just downvoting? Is it really too much to ask security engineers
| at Apple to focus on actual major privacy holes in their OS than
| things like this?
| _fzslm wrote:
| i don't want to focus too much on why i think you're being
| downvoted but i would say it's probably because your message
| came across as quite reductive.
|
| > engineers don't work on something that's useful for everyday
| users, instead prioritizing what they find exciting and cool
|
| i get this, to some extent. i really do. but i don't think
| WebAuthn, sign in with apple, ios 14's recent microphone and
| camera usage indicators, etc. are not huge steps forward in
| terms of mobile privacy & security. (rough double negative. you
| get me.)
|
| i am pretty sure Apple knows about everything you stated, and
| would wager they are developing, or at least R&D'ing,
| effective, polished, "Apple" solutions to these problems.
|
| clipboard is a bit of an obscure one, but is absolutely a
| problem and must be addressed. but Apple is in the business of
| juggling user experience and privacy. it's quite difficult,
| because you don't want to get in the way of the user's intents
| and make things way hard to do. but you also don't want to make
| things so easy that bad actors can get away with bloody murder.
|
| granted, they still can, if they really want, but it's way
| harder. and slowly apple is killing the mice. it's a cat and
| mouse game. i think they're doing exactly what they should be.
|
| could they be doing more? hell yes. they should -always- strive
| to do more. but right now, this is better than last year, and
| the year before that, and the year... yknow.
| apl002 wrote:
| I miss touch id. Face ID is one of my least favorite things apple
| has done
| barbegal wrote:
| This isn't that revolutionary: LastPass already allows you to use
| biometric ID to authenticate and it works without any changes to
| the website.
| crispyporkbites wrote:
| Right but Apple have done it and they have actual market share
| and 100% control of the end to end device
| jrockway wrote:
| It also doesn't add any security. Your password can still be
| guessed or phished. When authenticating with a cryptographic
| token (U2F/WebAuthn), that vector goes away. (Even OTP can be
| phished... the phishing site can just ask you for the code.)
|
| Password managers do make it more difficult to get phished,
| since they will not know what password to autofill on
| phishing.example.com... but on the other hand, password manager
| users are used to having to force-fill a password. I have to
| take my password out of LastPass to log into Battle.net or
| Fusion 360, and websites like the Wall Street Journal create
| your account on dowjones.com but require you to log in on
| wsj.com (or maybe it's the opposite, I forget).
|
| With WebAuthn, more care is required for both the site operator
| and the user (have more than one way of logging in in case you
| lose your phone, make sure the enrollment and login origins are
| the same), but you are then open to fewer attacks.
| treebornfrog wrote:
| What happens in the instance that one wants to move away from
| webauthn?
| barbegal wrote:
| Security seems roughly equivalent, there is always a fallback
| method of authentication in case the user changes their
| device or forgets their password. Even biometrics on an
| iPhone can fall back to a 4 digit pin code.
|
| I agree there are advantages to using public key crypto but
| the reality is that it's more difficult to get right (and
| therefore not implemented) compared to a simple hashing
| function for a password.
| amluto wrote:
| WebAuthn is less phishing resistant than it should be. The
| original intent was that WebAuthn + token binding would
| ensure that, even if an attacker obtained a fraudulent
| certificate for a victim site and had an MITM position on the
| network, the attacker still couldn't steal a WebAuthn
| protected session. Alas, Chrome removes its token binding
| implementation, and WebAuthn no longer has this property. If
| you authenticate with WebAuthn, and there is a MITM, the MITM
| gets your session.
|
| (Conventional phishing is still prevented. If you go to, say,
| g00gle.com, the owner of g00gle.com can't reuse your
| authentication to authenticate to google.com. But this relies
| on your browser actually knowing what domain it's looking at,
| which relies on the CA system.)
| jacobr1 wrote:
| This is true, but it does prevent replay.
|
| So you are vulnerable to an active MITM, but they don't
| actually acquire any private secrets to be used to create
| their own sessions. MITM with passwords OTOH, gives the
| attacker your password.
| amluto wrote:
| That depends on how the site works. On most sites, when I
| authenticate with WebAuthn (or by any other means), I get
| a bearer token good for several weeks. So a single
| spoofed WebAuthn session gets the attacker access for
| quite a while.
| zuhayeer wrote:
| Interesting, Apple is letting you change your default web browser
| with this new iOS version, but also adding Face ID and Touch ID
| to Safari.
|
| Why would anyone want to build these features if they're so
| platform / browser specific? Does anyone know if these auth
| features might work on other browsers on iPhone?
| vbezhenar wrote:
| Last time I checked, efficient ad blocking worked only in
| Safari. If that did not change, it's another reason to stay on
| Safari.
| jchw wrote:
| It appears to be the WebAuthn standard (based on a quick look
| at the video so far) and so implementing it would enable you to
| leverage other Webauthn targets as well, not just on iPhone but
| on Windows devices and more.
| [deleted]
| aaomidi wrote:
| There isn't a reason it wouldn't work - the browsers all use
| the same engine anyway.
| abrowne wrote:
| If Apple lets other browsers using the engine have access to
| this feature.
| throw03172019 wrote:
| There are some differences between Safari and WKWebView. Some
| features are blocked.
| mathisonturing wrote:
| It's funny how much bashing Google gets for monopoly with
| Android, pushing users to use Chrome, Play Store and
| whatnot. While all of that is relevant, Apple's
| stranglehold seems much more and worse.
| naringas wrote:
| at least apple never pretended like iOS was open source
| jodrellblank wrote:
| Apple sells between 10-20% of smartphones per quarter[1],
| that implies Android makes up 80+% and Windows/Blackberry
| a neglible amount.
|
| How can Apple be a monopolist from such a small position,
| or have a "stranglehold" when they are outsold 4-8x by
| the competition?
|
| [1] https://www.statista.com/statistics/216459/global-
| market-sha...
| Dahoon wrote:
| So you are comparing Android vs iOS. You cannot see how
| that is Apples Vs Oranges? Just because something is
| based on Android doesn't make Everything Android vs iOS a
| direct comparison. Try Google Phones Vs Apple phones or
| Huawei vs Apple.
| azinman2 wrote:
| Sure it does. If what I want is not to be blocked by an
| OS that won't let me write my own JIT, then any android
| phone will work. And in that case, there's a ton of
| competition to chose from, and the JIT I write can
| (theoretically) work on any of them.
| jsight wrote:
| You are exactly right. I wish both platforms were more
| open.
| playpause wrote:
| This isn't really true any more. Apple requires their
| competitors' browser apps to use a 'webview' to display
| websites, and Safari does not use this. The iOS webview may
| share a layout/paint engine with Safari, but it is heavily
| restricted in other ways. Apps with webviews (like Chrome for
| iOS) can't have extensions, for example. But the subtlest,
| cleverest restriction is that webviews are forced to use an
| older and slower JavaScript engine. This ensures that
| websites feel a little slower in Apple's competitors'
| browsers. Another major upshot of this is non-Apple browsers
| can't offer the same modern JavaScript APIs to websites as
| Safari can. For example, last time I checked, 'getUserMedia'
| was not available on iOS outside Safari, meaning non-Apple
| browsers can't support web-based video conferencing tools
| like Jitsi. This also implies that websites running in non-
| Apple browsers won't necessarily have access to the APIs
| necessary request Face ID sign-in, unless Apple decides it is
| in their interests to make this available to webviews.
| untog wrote:
| > But the subtlest, cleverest restriction is that webviews
| are forced to use an older and slower JavaScript engine.
|
| AFAIK that hasn't been true for years. WKWebView (as
| opposed to the old UIWebView) lets you use the full speed
| JS engine.
| playpause wrote:
| Ah, just googled it, you're right, they did eventually
| make the Nitro engine available in webviews. But my main
| point is that it's not exactly the same, they restrict
| certain features, and so it should never be expected that
| modern functionality will work in webviews just because
| it works in Safari.
| devmunchies wrote:
| An example is the in-app browser that you see when clicking on
| a link in instagram, that goes to my online store. The browser
| is still in the instagram app, so they aren't already logged in
| to their account on my store. That person can quickly login
| without typing in an email and password.
| irrational wrote:
| My company recently started using Okta. This is the first time
| I've heard of webAuthn. Is there any relationship between Okta
| and WebAuthn?
| lukeramsden wrote:
| Not as far as I'm aware, WebAuthn is a standard, and Okta is an
| authn provider. You can use WebAuthn with many other things,
| like the Yubikey.
| elwell wrote:
| 1Password users can already have effectively the same experience.
| acdha wrote:
| Not as securely or cheaply: using 1Password this way either
| requires less secure TOTP codes (which are easily phished) or a
| separate token.
|
| Having this available to every Apple user on the web is huge,
| especially when you look at the network benefits of the Apple
| feature pushing all of the slackers (hi, every large financial
| company!) to implement secure MFA.
| toomuchtodo wrote:
| Apple users will get this natively without having to acquire
| 1Password. If you've bought into the Apple ecosystem and don't
| have needs outside of it (Windows, Linux), you can eliminate
| the need for a separate password manager. Similar to how iCloud
| Files is moving towards (but likely won't meet, while not
| needing to) Dropbox parity.
|
| This is making a friendly version of Yubikeys (using Apple
| devices) and password vaults for Apple users.
| WA wrote:
| For interested readers: 1Password does a few more things. For
| example, you can add 2FA to 1Password logins, so that
| 1Password replaces Google Authenticator with the immense
| advantage that you don't have to setup 2FA again if you get a
| new device.
|
| Just a happy 1Password user, nut related to them in any way.
| jdeibele wrote:
| I use LastPass for passwords and Authy for 2FA. I like the
| idea that two different programs have to be attacked to get
| access to Google, Facebook, etc. There's a little bit more
| friction than having both in one program but that's the
| point.
| bjelkeman-again wrote:
| Thanks I didn't know this.
| sygma wrote:
| Is it really 2FA if your password and your token are on the
| same device?
| Skunkleton wrote:
| Yes. 2FA protects, among other things, against
| compromised passwords. Having both on the same device
| does not reduce this protection.
| sirn wrote:
| One could argue that authenticating via 1Password is
| already multi factor in itself e.g. Master Password is
| Something You Know as the first factor and access to a
| 1Password Vault is Something You Have as a second factor
| (since you cannot login to 1Password with just username
| and password, but also requires a Secret Key that can
| only be acquired from a device that already logged in).
|
| In this case TOTP acts more like an insecure one-time
| session key.
| bdcravens wrote:
| I'm more of a fan of buy-in without lock-in.
| chanmad29 wrote:
| so one more instance of Apple effectively rendering a third
| party app useless. As an apple user, I love that I do not
| need to install an additional app but something does not feel
| right from an ethical standpoint. Or maybe I'm just being too
| touchy.
| lwhi wrote:
| You feel that way because it's ethically corrupt behaviour
| on the part of Apple. They are aggressively pushing out
| others.
| toomuchtodo wrote:
| I would rather have a native UX versus Bitwarden,
| especially if there's no additional cost (I have to pay for
| Bitwarden annually or spend time running a server) and an
| easy way to share creds with my partner (for delegation in
| the event of my passing).
|
| Competition and a free market has perils. May the best
| solution win.
| MetallicCloud wrote:
| You can use Bitwarden for free while using their servers.
| toomuchtodo wrote:
| Not for family plans, unless something has changed in the
| last year.
|
| Big fan of these feature being native client side. These
| are features, not products. We should all be a fan of
| improved security delivered to as many people as
| possible, with as little effort on their part.
| echeese wrote:
| I got a Yubikey earlier this year and was disappointed by Apple's
| implementation of WebAuthn it (doesn't work if there's a PIN on
| the device) but it looks like they're fixing that as well in iOS
| 14
| 0xCMP wrote:
| I'm hoping it works with NFC and not just the lightning one.
|
| Would be nice to have Yubikey replace my password and then
| allow me to enroll FaceID so I can keep signing back in.
| echeese wrote:
| The current Yubikey works with NFC on iOS, it just doesn't
| work if you add a PIN to it (which Windows Hello requires).
| They mention that they added PIN support in the changelog
| theboat wrote:
| If the web migrates to biometric sensors for authentication, I
| hope this won't suffer from vendor lock-in. When every new device
| ships with facial recognition and/or a fingerprint reader, it
| will be nice to login using my face/fingerprint irrespective of
| the device I'm on.
| munchbunny wrote:
| This looks like a WebAuthn implementation, in which case it's
| an established standard and lots of vendors have
| interchangeable implementations. For example, Windows Hello has
| been WebAuthn compatible (FIDO2) for a while for sites
| configured to accept on-device authenticators.
| acdha wrote:
| This isn't biometric authentication: it's WebAuthn, which is a
| public-key based system implemented by all major browsers
| (https://webauthn.io/). This particular implementation uses
| biometrics to unlock it but other implementations use a contact
| sensor (Yubikeys) or PIN, and the target website doesn't need
| to know anything about which particular mechanism was used to
| unlock the keystore.
| cgb223 wrote:
| We'd need to have a standard HTML element like <facial-rec> or
| something and let the browser handle mapping it to whatever
| specific hardware the device is using
| rovr138 wrote:
| The issue is that it's just a token that would simply say
| Passed/Fail. So it's trusting the client/browser.
| crispyporkbites wrote:
| If the token is signed you could validate it with Apple (or
| the vendor that implemented the face recognition on the
| device, eg Samsung, Nokia, pinephone etc).
|
| You just need an open standard, you could even embed the
| url of the validating api in the token, so anyone could
| create their own Face ID provider.
| duskwuff wrote:
| It's more than that -- from what I'm seeing, it looks like
| it's a cryptographic token, presumably signed by a
| certificate that's embedded somewhere inaccessible in the
| device (probably in the secure element).
| Spivak wrote:
| I don't see how this could ever be something not vendor-
| specific because without this being tied to "Log in with Apple"
| you're just saying "trust the client."
|
| Maybe that's fine if all you want is to "lock" a sensitive page
| to people who aren't the device owner but that's pretty limited
| compared to FaceID to actually log in.
| tialaramex wrote:
| It has no relationship to "Log in with Apple". It's a
| WebAuthn authenticator.
|
| Almost all web sites should just implement WebAuthn. On a
| suitable iPhone or Mac users will be able to sign in by
| touching the sensor or looking at the camera, while on my
| Pixel phone I touch the fingerprint sensor, on this Linux
| desktop I touch a Yubico Security Key.
|
| _If_ your site is paranoid that some crazy user will choose
| a bad WebAuthn authenticator, or deliberately sabotage their
| own security for some reason, then you can use WebAuthn
| Attestation to obtain a signed document from the
| authenticator (yes, over the Web) which proves that it is,
| for example, an Apple iPhone 25 Super Mega Plus. I don 't
| think you should bother doing that, but you can.
| chrismorgan wrote:
| This is an implementation of the Web Authentication API, and is
| exposed as a platform authenticator. There is no vendor lock-
| in.
| nimbius wrote:
| I dont see a problem with this as part of MFA, but here in the US
| our fifth amendment protections are pretty lax, and only cover
| passwords (sometimes). If the police wanted to force your
| fingerprint or face ID to log into a website (say, maybe a
| protest message board), they can do it just the same as they can
| force your blood draw during a DUI with a warrant from a judge.
| BiteCode_dev wrote:
| Giving my finger and face prints to the browser, the software
| with the biggest attack surface in the world, connected to
| internet no less, feels off to me.
| ThePowerOfFuet wrote:
| You're not giving them to the browser!
|
| https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
| lemoncucumber wrote:
| Native apps have long been able to use TouchID/FaceID and have
| never been able to access the actual finger/face print data.
| There's no way that iOS exposes your actual finger or face
| print to websites.
| brandonhorst wrote:
| All of that is managed by the Secure Enclave in exactly the
| same way that it is for all over auth on Apple devices. The
| browser doesn't touch it at all.
| thowawaymom wrote:
| Oh the almighty Secure Enclave, bow down to the Enclave...
|
| Do you even know what the heck an enclave is and how does it
| work? It's nuts that when a figure of authority uses a fancy
| shiny new word to describe some magic black box and the
| masses follow with no questions asked.
| nicky0 wrote:
| The concept has been around for years now, it is well
| understood.
| ThePowerOfFuet wrote:
| PDF page 8:
|
| https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/ap
| p...
| pgoggijr wrote:
| pretty straightforward to understand:
| https://support.apple.com/guide/security/secure-enclave-
| over...
| orf wrote:
| Do _you_ know how it works?
| thowawaymom wrote:
| That's the _point_ , not many do
| buzzerbetrayed wrote:
| K, but that doesn't mean the person you responded to
| doesn't know how it works. You are the one that doesn't
| know how it works, so why are you expecting people to
| listen to your opinion about the Secure Enclave?
| sosborn wrote:
| This might help: https://www.blackhat.com/docs/us-16/mate
| rials/us-16-Mandt-De...
| KMnO4 wrote:
| They're not giving your fingerprint or face image to the
| browser. They're simply providing the ability to authenticate
| using iOS hardware.
| anon102010 wrote:
| That's not how this works on apple. Basically your fingerprint
| scan is not sent to the browser, just the authenticated result
| of the scan (ie, yes, the fingerprint was so and so's).
|
| There have been some past complaints here about how Apple used
| to tie their fingerprint sensor into the secure element (third
| party folks couldn't substitute them). I actually liked that
| rule from a security standpoint, but obviously unpopular here.
| Same approach with faceid / touchID for the web.
| noodlesUK wrote:
| One of the reasons this is so important is that it makes it far
| harder to phish people. The webauthn APIs include the web origin
| in the authentication process, so it's not possible to use
| something like modlishka to phish people. If we use magic links
| or something similar like a QR code for adding new devices, or
| more users also have roaming authenticators with PINs, webauthn
| will massively massively reduce phishing success where it's
| implemented, as it's pretty easy to make website that doesn't
| have phishable credentials at all.
| motohagiography wrote:
| Linking biometrics to cryptographic authentication is difficult.
| When I worked on this problem about 5-6 years ago somewhere else,
| it came down to adding a separate applet for the biometric
| verification to the secure element, which then authenticated
| itself to the user authN applet, which was then authorized to
| generate the user authentication cryptogram.
|
| Biometrics are probabilistic samples of data, where cryptographic
| verification requires deterministic inputs. They are
| apples/oranges and that's what made this hard, so you need a
| connector for them. The attack on such a scheme means spoofing
| the biometric authenticator's validation message to the
| cryptographic authenticator, which, if this all occurs between
| applets on the same secure element, raises the bar for attacks.
| theogravity wrote:
| I wonder what part of the Web Auth APIs does iOS Safari support
| since MDN says most of the APIs are not supported.
|
| https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
| jedieaston wrote:
| I think that this is coming in the next release of Safari, so
| MDN is correct, it's not currently supported.
| gorgoiler wrote:
| Isn't this a classic example of the fragility of biometrics?
|
| If I move to a new device, iOS should be required to give up
| whatever secret key my face translates to, so I can log into
| websites.
|
| Simplistically, if iOS silently turned my face into the web
| password "g0rG0il3r", when I eventually migrate from iOS to
| something new, I'll have to be able take my face password with
| me, thus exposing that my face was only ever equivalent to a
| password in the first place?
| snuxoll wrote:
| WebAuthN is not supposed to be the only way you log into a
| service. The credentials are permanently tied to your
| Authenticator of choice, which can be lost or stolen at any
| time.
|
| If you change devices you just provision the new one for your
| account after signing in with a traditional
| username/password(/2nd-factor).
| GoMonad wrote:
| FIDO/WebAuthn has been designed to be first factor
| authentication (passwordless) as well as 2FA.
|
| Though, I agree lost and stolen devices are a problem whose
| solution space needs more exploring than simply multiple auth
| devices.
| bfulgham wrote:
| This is, of course, an active thread of discussion in the
| WebAuthentication working group.
| zaroth wrote:
| Apple is considering this to be multi-factor authentication all
| in one click, the something you have (the phone) and the
| something you are (FaceID or TouchID). For the site perspective,
| if you ask for attestation then you will have cryptographic
| evidence of this. No more SMS 2FA!
|
| Apple is promising to do something extra with their attestation
| process which they call "Apple Anonymous Attestation" to mitigate
| the issue where attestation allows tracking the same device
| across different websites even if they are using different
| usernames. Not included in the current release, but "coming
| soon".
|
| The process of enrolling an authenticator is presented as a "one
| and done" event, but of course the devil is in the details.
| Shared accounts would need multiple authenticators, and what
| happens when you upgrade your phone or lose your phone? I guess
| this gets handled like a password reset. You probably will want
| users to be able to add/remove authenticators, which means also
| having to name them.
|
| The enrollment process in this video highlights the upgrade path
| from a password login to a FaceID/TouchID login, but doesn't give
| us the UI flow of a new login. It seems like sites would need to
| implement a standard registration page and then perhaps swap out
| the password field with a Next button which would prompt for the
| FaceID/TouchID enrollment. Makes me wonder how does this compete
| with or tie into the 'Signin with Apple' if a site wants to offer
| one-click registration?
|
| Will my Mac and iOS devices automatically and securely sync the
| private keys between their respective Secure Enclaves so that I
| can signin from any of my devices after enrolling on just one?
|
| Lastly, how about the case when returning to a site where the
| user is on their enrolled device, but there isn't a cookie
| present. It looks like the site can detect that the device
| supports Webauthn, but I'm not sure if it can automatically
| detect that the device already has an account enrolled with the
| site?
|
| The call to 'credentials.get' includes the 'credentialIdBuffer'
| which is a value provided by the platform authenticator and saved
| during registration. But in the video they make it sound like
| 'credentialIdBuffer' is actually optional? It's not even clear to
| me in the official WebAuthn spec [1] if this value is required,
| or if the authenticator will just use the RP domain to present
| the user a list of available credentials? Ultimately I'm
| wondering if a user without a cookie will still have to type in
| their username before the site can prompt them for FaceID/TouchID
| authentication.
|
| [1] - https://w3c.github.io/webauthn/#dom-
| publickeycredentialreque...
| EGreg wrote:
| Just to state the obvious...
|
| Biometric data must always stay on your personal device in order
| to be secure from replay attacks, not to mention finding out more
| about you.
|
| https://amp.theguardian.com/world/2019/sep/04/smile-to-pay-c...
|
| Of course, in Apple's implementation, the data never leaves the
| device. Which is far better than, say, how facial recognition is
| used in China for payment where the merchant is the one operating
| the machine which scans your face.
| marinhero wrote:
| The video mentions the data never leaves the device and that
| the transaction is performed in the secure enclave of the
| phone.
| aarongray wrote:
| A fingerprint can be a personal password or it can be a
| government ID, but it can't be both. Since the U.S. government
| already has something like 200 million fingerprints on file, and
| many foreign governments collect fingerprints whenever you
| travel, these fingerprints are sometimes leaked en masse (https:/
| /en.wikipedia.org/wiki/Office_of_Personnel_Management...), and
| because they can never be changed, biometrics aren't my personal
| choice for a secure method of authentication.
| hn_throwaway_99 wrote:
| But I think you missed the point about the second factor,
| because there are really 2 factors here:
|
| 1. Something you have (e.g. your phone, in this case the Secure
| Enclave that stores the private key).
|
| 2. Something you 'know', e.g. your fingerprint.
|
| Just having the fingerprint itself is not sufficient.
| lifeisstillgood wrote:
| So roughly speaking this is WebAuthn for a web site, with the
| iphone acting as the dongle.
|
| It's a really good idea. I can see there being a big demand for
| just simplifying signin - I can easily see a time where it is
| worth not having the hassle of managing multiple signin processes
| and just choosing webauth or nothing.
|
| Edit: to be clear this won't affect B2C sites whose monetisation
| is based on getting as many people as possible. But imagine a
| saas business charging upwards of 100 bucks a month - they have
| something valuable to protect, and the security story just got a
| lot easier
| masklinn wrote:
| Is it webauthn or is it once again proprietary tech?
| sirn wrote:
| The video explicitly mentioned it is WebAuthn Platform
| Authenticator (1:54)[1].
|
| [1]: https://www.w3.org/TR/webauthn/#platform-authenticators
| monocasa wrote:
| It's webauthn from what I can see.
| BillinghamJ wrote:
| It'd be really nice to see this working with iCloud Keychain at
| some point too - so you can have FIDO working as a secure
| platform thing but with syncing and dealing with the problem of
| effectively losing your keys over time etc
| lstamour wrote:
| WebAuthn is generally about device authentication with
| credentials that can't leave the device, though that could
| change depending on where and how the hardware gets/stores
| it's tokens. Or if you rely on a third-party, like Apple, to
| store the tokens for you and use OAuth with an mfa indicator
| in the attestation?
|
| General advice: If worried about losing a device, try to
| register more than one. Even iCloud Keychain requires other
| hardware for authentication... same problem applies.
|
| Only way out is having a backup like taking ID to an Apple
| Store as a way to regain access... that varies right now by
| provider, but who knows. Maybe Login with Apple will go
| WebAuthn-compatible in future? (Haven't watched this video
| yet.)
|
| If you're an enterprise and worried about key authenticity or
| varying WebAuthN standards, you can look for specific types
| of keys or even request specific serial numbers of FIDO2
| dongles from the web browser, etc.
| BillinghamJ wrote:
| Not really a problem for me - I keep a set of six CTAP2
| keys registered on everything with careful labelling etc.
|
| But for normal people, we do need to get more of the
| balance into the usability side I think. The thing with
| iCloud Keychain is it can comfortably be recovered without
| breaking the end-to-end encryption with only a single
| remaining device, and many Apple users have as many as 3-4
| devices in the circle of trust
|
| It seems ideally some kind of "roaming platform" additional
| option would be good in the webauthn standard
| lstamour wrote:
| I agree, but it sounds like we're trying to get the web
| browser to simplify and implement OAuth2 and OpenID
| Connect via WebAuthn ... If we already have OpenID
| Connect, the only advantage to end users under that
| scenario is a login-with-Apple ease-of-use improvement.
| Seems more likely that we'll continue using OAuth2 and
| OIDC server side for this, for now... but maybe we'll end
| up standardizing the ways MFA is requested and presented
| by providers...
| monocasa wrote:
| Webauthn actually fully supports this model as "platform
| authenticators", ie hardware security modules built into the
| client system. You see this on the windows side too where
| "Windows Hello" integrates with the TPM and acts as a platform
| authenticator as well.
|
| No need to speak roughly.
| judge2020 wrote:
| * you don't need the TPM for Windows Hello to act as your
| security key. I can't enable BitLocker because there's no TPM
| yet I have Hello enrolled as a key for GH.
| tialaramex wrote:
| Yup. A site can even say "I want a platform authenticator" or
| "I specifically don't want a platform authenticator" during
| registration using the Javascript API.
|
| Most sites should just not care, but it's an option if you've
| determined there's a specific reason it matters in your
| application.
| philsnow wrote:
| ios/macos already let you copy/paste between them if you have
| bluetooth enabled on both sides and are signed in the same
| icloud account on both. I wonder if they're planning to let me
| authenticate/webauthn on macos using my phone as a platform
| authenticator?
| mc32 wrote:
| Does this mean integration with SaaS IDPs?
| the_gipsy wrote:
| FYI, fingerprint for WebAuthn already worked on Android, I
| tried it with my pixel phone.
| thowawaymom wrote:
| Oh the almighty Secure Enclave, bow down to the Enclave...
|
| I see so many comments mentioning Secure Enclave to any security
| objection as if it's a panacea. Do you even know what the heck an
| enclave is and how does it work? It's nuts that when a figure of
| authority uses a fancy shiny new word to describe some magic
| black box and the masses follow with no questions asked.
| ThePowerOfFuet wrote:
| PDF page 8:
|
| https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
| derefr wrote:
| > Do you even know what the heck an enclave is and how does it
| work?
|
| It's a isolated smart-card-like KMS core within the SoC, that
| has most smart-card guarantees (e.g. no side-channel attacks;
| tamper-resistance.)
| acdha wrote:
| Please don't spam the same comment
| thowawaymom wrote:
| I literally mentioned it one other time as a reply to a
| comment, that's hardly spam (the m stands for mass, fyi)
| monocasa wrote:
| They've been fairly open about how it works, and since then the
| binaries have been disassembled and backed up what they were
| saying.
|
| It's a pretty modified L4 (I want to say L4::Pistachio off the
| top of my head) that for some reason has had Mach-O support
| added and pretty much just acts as a keystore with a secure but
| upgradable boot sequence.
| acdha wrote:
| You may not know what it is but it's been well documented for
| years detailing what it is, what it's used for, and the built-
| in tamper-resistance features:
|
| https://support.apple.com/guide/security/secure-enclave-over...
|
| https://www.apple.com/lae/business/docs/site/iOS_Security_Gu...
| LockAndLol wrote:
| The last I read, if you wanted security then Face ID and Touch ID
| definitely weren't the way to go. I'd rather see Apple pick up
| something like SQRL[0] than continue down this path of pseudo-
| security. They work, but it's like having a half-blind doorman
| who can't tell if you're wearing a mask or if it's your real
| face.
|
| 0: https://www.grc.com/sqrl/sqrl.htm
| jmull wrote:
| > The last I read, if you wanted security then Face ID and
| Touch ID definitely weren't the way to go.
|
| Sounds vague and overly general. I don't think anyone can take
| this seriously without some more information.
| LockAndLol wrote:
| You are but a duck-search away
|
| Face ID defeated with glasses and tape
| https://appleinsider.com/articles/19/08/08/face-id-
| security-...
|
| Touch ID defeated by lifted fingerprints
|
| 2013: https://arstechnica.com/information-
| technology/2013/09/defea...
|
| 2016: https://appleinsider.com/articles/13/09/22/apples-
| touch-id-a...
|
| 2019: https://www.forbes.com/sites/daveywinder/2019/11/02/sma
| rtpho...
|
| Biometric "security" on phones is a gimmick.
| _jal wrote:
| Going to have to give serious thought to where I will and won't
| use this.
|
| There are a lot of implications - no ability to automate and
| giving others data on you were provably in front of some machine
| are two big ones.
| duskwuff wrote:
| That's a really interesting point. If this really does allow a
| web user to prove that a human interacted with the computer,
| it'd make for a really nice CAPTCHA replacement.
| jiveturkey wrote:
| it doesn't do that, since there's no attestation.
| bfulgham wrote:
| Yes there is. The video covers this clearly.
| Tepix wrote:
| Did you watch the video?
| jiveturkey wrote:
| where he says it is "not included"? (because the Apple
| secure enclave does not attest keys.)
|
| also where he falsely alludes to other attestations being
| identifying? sure, they can be, but they generally
| aren't.
| thephyber wrote:
| From the server side, isn't this just a WebAuth integration?
|
| How does the server know for sure if the client is on an iOS
| Safari browser on an iPhone with FaceID or a custom browser on
| any OS and any non-locked-down hardware being run with
| Selenium?
| jacobr1 wrote:
| The question is more along the lines of: does this provide
| more security than passwords for real users?
|
| Stealing a password is probably more easily done than
| stealing a private key that is never transmitted. The primary
| threat model is protecting the credentials of real users
| rather than protecting against fraudulent users (though some
| considerations have been made for that too).
| thephyber wrote:
| While what you say is true, it doesn't seem relevant to
| this thread.
| blintz wrote:
| Attestation. If a website requests it, the device will
| provide cryptographic proof that you used a specific vendor's
| device to store the resident credential. The proof is a
| certificate signed with a vendor's secret attestation key.
| Siira wrote:
| Can't the key get stolen if it's on the client?
| amluto wrote:
| Yes, but it's probably stored in the Secure Enclave, so
| it'll be hard work.
| bfulgham wrote:
| Correct. The key material is stored in the Secure
| Enclave.
| [deleted]
| 0xCMP wrote:
| It won't be the only sign in method unless the point is to only
| allow _that specific device_ to connect.
___________________________________________________________________
(page generated 2020-06-24 23:00 UTC)