Yahoo Japan's password-free authentication reduced inquiries, sped up sign-in
web.dev
web.dev
This effectively overrides all of the improvements in password managers, especially OS-level ones, in recent years. On iOS, for example, the system suggests a strong password on account creation and then autofills very quickly and easily both on the web and in apps, so it's secure and you never have to think about it. But now with this change, you don't even have that option and you always have to wait for the email, open your email, click the link to go back to the app/site, and then go back and delete the email.
This way, the user just clicks a link and if the email is delivered quickly, they see only that message.
Although I agree with others, just let my password manager auto-complete, I don't want to load my email.
About a third of Yahoo Japan's customer support requests where password inquiries -- the FIDO Alliance estimates the cost of a single password reset inquiry at $70.
It's hard to look at those numbers as a manager with bottom line responsibility and not want to go full password-less.
But as a startup your main interest should usually be growth, cost reduction is best addressed after you hit a critical mass.
It feels like the jury is still out on whether password-less converts better -- this article says it does, but doesn't go into depth. Anecdotally it seems to frustrate a lot of people (me included).
Password-less may be great, I just know that in enterprise the support cost savings are going to distort or render all other arguments moot. We have a long history of ideas that have come out of FAANG, worked well for them, and been cargo-culted into the rest of the world where they promptly turned out to be a bad choice.
Not that I think that happened, but if it had to be any company that did that, they're a candidate.
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
This seems broken in Firefox for me.
e: To be clear, the "⬅ Go ahead... click it." doesn't have anything to the left of it. Refreshing temporarily shows a button that goes away.
Also, the word to the right of Passwordless.dev is cropped off, so I see:
Paswordless.dev nentation Get
Started
->
What device are you on? Unfortunately your device seem to not support “platform”-authentication (built in, TPM based)
I test for platform support but mistakenly only hide the test button, not the text queue. Thanks for telling me.
No TPM - it's a AMD Zen 3 CPU.
I can use YubiKey's WebAuthn demo[1] just fine with my YubiKeys.
The API itself work great with yubikeys (“cross-platform”) and I use them myself.
Ok, good to know why.
Maybe it might be worthwhile removing that text, or replacing it with a "We'd like to show you, but the demo has requirements that your computer doesn't appear to meet" or something like that. Without that knowledge, it just looks like the site is broken and I have no ability to tell why without digging into JS/whatever.
They already made some vague announcement about FIDO recently, so this is obviously part of the same campaign. A campaign cannot exist without a target/goal, meaning Google is up to something!
1 (edit): Which I'm totally fine with, but they could certainly be slightly more transparent about it
Imagine BP or Shell were operating a website greentechtoday.peace without this relationship being very obvious at all, and an article about some specific technology appeared on that website and was linked here on HN.
Personally, if I weren't aware of the affiliation I would appreciate for it to be pointed out to me - and so I'm doing exactly that for others here.
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?
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
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.
Any service that allows resetting passwords by email has this risk, unless the service supports MFA and the user configures it.
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.
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.)
* 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.
The difference is that you don't have an account, just individual e-mails.
Some sites also use e-mail OTP as a second factor (e.g. Steam and Humble Bundle).
I can't speak on behalf of them, but I absolutely loathe sites/services that require logging in through email. It's fine if it's just one log-in option, but if a site makes it the only option, it's very likely I will not be using that site. From what I've heard from peers (both tech-savvy people using password managers and less-tech-savvy people confused by the seemingly-random tie-in to their email login), I've never heard anyone actually say they like the flow. In my experience, they very strongly dislike it.
If you're doing it to "increase security", I recommend taking an approach closer to Steam: if someone logs in from a new or unrecognized device, send a code to their email and require them to confirm. It's still intrusive, but way less so since you have to deal with your email way less often.
If it’s truly rare for someone to need to login it seems fine to me. If you keep session cookies around for a long time all the better.
But if you need to re-login semi-regularly it’s a pain.
The FIDO Alliance made an announcement last week where major vendors commit to expanding support for multi-device FIDO credentials ("Passkeys") and using a phone as a roaming authenticator (This is admittedly another device). Both of which significantly mitigate your concerns without any security tradeoffs. See https://fidoalliance.org/apple-google-and-microsoft-commit-t...
So either the passwords weren't secure, or we're only building for power users, or we're ossifying on the browser password manager (and keeping passwords) as the way to manage credentials.
I also don't see how account recovery can be really worse than for passwords.
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.
And hey, if you don't like SMS, you can just use FIDO instead and let Touch ID / Face ID / Windows Hello / etc do their thing.
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.
I can't lose access to my password because I don't pay a bill, or because of an opaque process where someone accused me of "unauthentic behavior", and the trust and safety board suspends my account, promptly unpersoning me unless I can make it through an appeals process that is about as fair as a witch trial.
Each and every time I use it I have to go to the yahoo settings and the convoluted process of turning sms auth off to go back to a password.
I don’t trust sms auth a bit. My number is probably my weakest link and I don’t want to ever have to rely on it. I’m sure an attacker could just pretend to be me and take it over in no time
I set it back to password and just stopped using their services
I really wish people would stop calling it this, and call it what it really is. Biometrics. I don't use that, and I won't, ever. At least until Mountain Dew Verification Can becomes real.
Passcode to "open a phone" is fine, E-mail to identify yourself is sort of okay, E-mail and password to unlock(?) the website, barely, but E-mail and password and website URL as a single set makes their head explode. Password managers are a bit too clunky at current stage. And hence an overarching web service operators goes for alternative methods such as magic link, device IDs, migration codes and other login-free login methods. I guess this is one such case.
Registration requires only an email address. You get a link by mail that you can use to log in. If the link is used within 5 minutes you are fully logged in but this expires after 1 hour. After it expires, or if you use the link again you get very limited access. Sensitive things and things you don't need frequently are hidden and disabled. With limited access you can request a new full access link. If you lose the link you can request a new one that will only work after 24 hours. Very sensitive things trigger a confirmation email. If you do not log in in 90 days your limited log in link is further limited to requesting the 24 hour delayed link.
It's fine for a single device uses, but it breaks rapidly at scale.
Even with very fast delivery, having to switch email or SMS still take time and interrupt the signin process. We all know how costly it is to switch context.
(My company similarly insists on not capitalizing the first letter of the name in English text, ugh)
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.
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/EdDSA or (rarely) >2048 bit keys for RSASSA. Not biometrics.