[HN Gopher] Yahoo Japan's password-free authentication reduced i...
___________________________________________________________________
Yahoo Japan's password-free authentication reduced inquiries, sped
up sign-in
Author : feross
Score : 72 points
Date : 2022-05-10 16:33 UTC (6 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| 0x073 wrote:
| Scary that they use sms, because it's just insecure. Are they
| really use sms or is this the japanese fake sms email system?
| notlukesky wrote:
| Switching FIDO devices will seem to be a problem down the road
| like account recovery and a potential attack vector. Kicking the
| can down the road in a sense if mitigation measures are not taken
| from now.
| tialaramex wrote:
| How do you see "potential attack vector" ?
|
| I also don't see how account recovery can be really worse than
| for passwords.
| dathinab wrote:
| I'm not sure that is the case.
|
| They replaced passwords with FIDO/WebAuthn devices not added
| WebAuthn 2FA.
|
| So iff they use WebAuthn `authenticatorAttachment: "platform"`
| this will use TPM, TouchId and similar and should have very
| similar security as using a password + password manager (which
| you unlock by TouchId or similar). I.e. for the "common" user I
| would expect it to be the same security aspects minus the
| password manager being an additional attack surface. For users
| which 2FA secure they password manager or similar it's a
| different matter but thats not the common user.
|
| Similar as it's not 2FA you can have mostly the same auth reset
| workflows as with passwords (through with more requirements for
| things to happen on the same device which for most common users
| don't matter too much).
|
| I also amuse it uses "platform" and not "cross-platform" as
| there are just to few people which have a HSK (like a Yubikey)
| and also their attack surface is different, e.g. if you make a
| HSK the main auth criterion you should still add a PIN, or have
| a HSK with a fingerprint scanner or similar.
| dyml wrote:
| It's really great to see the adoption of WebAuthn rise
|
| I've been working on one of the leading open source servers for a
| couple of years and it's nice to see the real world benefits.
|
| If anyone is interested we run an API[0] that makes it really
| easy to get started with WebAuthn
|
| [0]: https://www.passwordless.dev/
| helloguillecl wrote:
| I must implement a members-only feature now in a website, where
| member access should be very infrequent.
|
| I'm considering implementing e-mail login (email OTP), but I have
| only seen it in Klarna. Therefore, I'm a bit worried of users not
| being familiar with the fact that they even if they didn't choose
| a password, they still have an account and/or profile.
|
| Any thoughts?
| ComputerGuru wrote:
| Craigslist on mobile defaults to logging in via a magic link
| sent to your email (you need to go out of your way to sign in
| normally). It seems to work fine for them and their particular
| user base. (I don't like it: the thought of context switching
| (both mentally and physically) and especially on my stupid
| single-function-at-a-time iPhone does not appeal to me.)
| Macha wrote:
| It's incredibly annoying, especially when there's delays in
| emails or short lived codes.
|
| * I have to go do something else and sometimes forget to come
| back to what I was doing
|
| * It can be tedious if I'm on a device which isn't signed in to
| my email
|
| * It's a problem when I use container tabs to compartmentalise
| my email and now the link from my email is opening in the email
| container and not whichever container I wanted it to.
| benmanns wrote:
| I've seen more places use it. Sometimes called "magic sign in"
| or "magic links."
|
| As a user, I don't prefer it, but I'm also very comfortable
| using password manager.
|
| We implemented it at Doximity but I'm not sure how it changed
| sign in experience/metrics. It's gated behind the "forgot
| password" link now rather than the default/only option.
| https://auth.doximity.com/magic_sign_in
| matja wrote:
| How do you mitigate the privacy risk of mail providers
| reusing email addresses for accounts when their customers
| stop paying for services? (e.g., I heard that fastmail do
| this).
|
| For example, user@example.com signs-in to your site and
| stores data they expect to be private, they stop using the
| mail provider and the mail provider deletes the user's
| account which allows it to be re-used, then another unrelated
| user signs-in to the site and takes-over the account.
|
| I imagine the only viable way would be a whitelist of domains
| of mail providers that are known to not recycle email
| addresses (like Gmail), or to also check if the WHOIS data
| for a domain changed.
| helloguillecl wrote:
| Wow thanks. I love the simple form you have there.
| dathinab wrote:
| It could be worth to check the state of WebAuthn without HSK
| (e.g. using a TPM).
|
| If this is available friction-less for most (non advanced)
| users then this could be a nice choice. And the email OTP is
| only needed when they login from a new device (which you can
| detect and handle it roughly like a password reset workflow).
|
| Through I'm not sure what the state of WebAuthn for non HSK
| use-cases is.
| dathinab wrote:
| I.e.: WebAuthn authenticatorAttachment: "platform"
|
| Using email OTP as "reset/new device" mechanism and fallback
| in case the platform doesn't support WebAuthn.
|
| Platform authentication means it uses TouchId/FaceId/etc.
| which people are already somewhat familiar with.
|
| And email OTP as password reset is something people are used
| to. (They are also often used to resetting passwords all the
| time on rarely used accounts.)
|
| The question is just how many of your users are on devices
| which support it. (And how hard it is to implement it with
| the tooling you use.)
| tialaramex wrote:
| Ten million is impressive. I'd be interested to know Google's
| numbers, obviously their employees have Yubikeys (or analogous
| authenticators) but I wonder how many of their users have
| enrolled.
| Johnyma22 wrote:
| So if you don't have access to your phone (auth device) you will
| have a bad time?
| slothtrop wrote:
| According to the source, FIDO is available in the browser or
| Windows/Mac.
| tialaramex wrote:
| If you choose only to authenticate with your phone then you
| can't authenticate without it, yes.
|
| If you "always" have your phone this probably doesn't feel like
| a big deal unless somehow Yahoo Japan is also their
| international embassy and gateway to access basic services,
| unlike the Yahoo! I'm familiar with.
| midislack wrote:
| I'm just not going to participate in this. I don't want to use
| extra devices, second devices, anything like that. I'm just not
| interested. Thankfully there are enough people like me around
| that this will never achieve any sort of meaningful widespread
| use. I think it's a fine option for people who want it but I
| don't.
| Snc wrote:
| While roaming authenticators are indeed separate devices,
| platform authenticators aren't; they're built into your
| existing device. If you're using a MacBook, you already have a
| Secure Enclave which you access through TouchID.
| StanislavPetrov wrote:
| Never giving my biometric information to any corporation,
| especially in the name of "security". I'll sooner live in a hut
| in the woods.
| jolux wrote:
| You can still use a Yubikey without giving up any biometric
| data. And with the way the implementation works on Apple
| devices at least, your biometrics are only stored in the secure
| element on the device, never transmitted.
| StanislavPetrov wrote:
| >your biometrics are only stored in the secure element on the
| device, never transmitted.
|
| Your biometrics are stored on the device Apple controls, not
| mine, because they are never getting my biometrics.
| Corporations and governments are free to implement whatever
| draconian invasions of privacy that they want in the name of
| "security" and "safety", but that doesn't mean the rest of us
| will go along with it. Certainly many will, and that is their
| choice.
| Snc wrote:
| WebAuthn does not pass any biometrics to relying parties.
| Rather CTAP, which stands for Client to Authenticator Protocol,
| is responsible for brokering credentials* between your
| authenticator (TouchID, Yubikey, your phone in the near future)
| and the client (in the case of WebAuthn and TFA this would be
| the browser).
|
| In most of cases, typically not even the operating system sees
| your biometrics; only the firmware in your authenticator does.
|
| * These are 256 bit keys for ECDSA or (rarely) >2048 bit keys
| for RSASSA. Not biometrics.
___________________________________________________________________
(page generated 2022-05-10 23:00 UTC)