I have a Yahoo Japan account and find this incredibly frustrating. Obviously they've measured it to be better on average, but if you already have a password manager, it's just an extra hurdle and waste of time when logging in.
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.
I'm not a fan of anything that takes me off the page I'm looking at or screen. I find it disruptive enough that I'll forget I'm logging in when I tab over to check my email and start reading some other message because the subject got my attention, especially if Ive been waiting half a minute for my "magic link." I also don't want to wade through notifications on my phone to check my authenticator or SMS. Ever since apple implemented auto password AND authenticator fill in with face/touch ID logging in has felt natural and frictionless again.
I saw a great pattern for this recently. The login page examines your email address to guess what web-based email you're using. It then crafts a link that takes you right to the search page, with a "from:login-noreply@example.com age:1h" search.
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.
The reason I'm still a bit skeptical about password-less authentication is because the cost savings opportunity is enormous. So enormous that it would be easy to lose sight of everything else.
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.
You can reduce password inquiries too by losing all your customers. It would be very Yahoo of them to lose thousands of customers and then promote the culprit because they reported that password request metrics got a lot better!
Not that I think that happened, but if it had to be any company that did that, they're a candidate.
> In the demo I’m hiding the button if “platform” authentication is not available.
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.
This website is ran by Google and mostly serves to promote their proprietary web technologies[1], and to sell web devs on some of their bigger and often times more questionable changes.
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
Yes, I was only indicating the affiliation and possible non-obvious agenda.
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 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.
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.
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
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.
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.)
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.
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.)
Slack and their magic links are probably the most common exposure your users will have to this model.
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.
I think this is relatively common for 'secure e-mail' (e.g. doctor-patient e-mail). You receive an HTTPS link by e-mail, click it, and then receive and enter an OTP to read the e-mail content.
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 use it on biztoc.com with a one-year expiration cookie — It sends you a direct magic link and a manual ~2hour pin that you can copy/paste. pin with a "—" separator for readability which gets ignored during validation.
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.
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.
The most obvious problem, though, is that it seems like you're out of luck on older/new/temporary/public/borrowed/reset/etc devices, which is a big change from just being able to log in wherever you need with just a secure password.
FIDO traded off convenience for security, and is incrementally building back usability features to what will hopefully be a more secure world. In particular, I'd be rather concerned about using passwords in most of the scenarios you describe where the OS is adversarial.
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...
How exactly are you bringing your "secure" passwords to the devices you mentioned? If the answer is "install and sync a password manager", that's something my mom will never do (short of having Chrome remember her password).
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.
If you're on OpenBSD then you're likely a person that skews more towards security on a security/usability spectrum than the average person. May I ask why you'd prefer passwords or magic links over WebAuthn with something like a Yubikey that's permanently attached to your Thinkpad?
As in most things security, it probably depends heavily on your threat model. For many high value targets, it is probably not great. For most of us? Probably better than you'd think.
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.
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.
Yahoo! Japan has the reputation of being used by the widest range of users in Japan, including a large demographic of people at the lowest end of the computer literacy spectrum. This is the group of (often elderly) people who may not even use any Google services at all but just kept using Yahoo! Japan ever since it became first available in 1996. It makes sense to stop forcing this crowd to self-manage their passwords (which, time after time they have proven, they can't) even at the expense of the techier demographic who are literate enough to take care of password managers and the like.
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 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.
The only thing worse than password based authentication is "something that I don't own" authentication: that is, my phone number, my email address, or my phone itself.
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.
SMS sign in and authentication also segregate users. Yahoo Japan does not accept non Japanese phone numbers making it a targeted market but a smaller internet. The internet is now turning into a surveillance system and ask too much information.
I am very annoyed by this “improvement”. Don’t know if it’s still like this but for example if I wanted to use PayPay on the we. (payment system owned by the same group), yahoo decides I no longer need a password and makes me turn it off (as part of the payment process) in favor of SMS auth.
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.
I was late to the FIDO announcement discussion from yesterday so I'll post this here - this is my anecdotal experiences but apparently a lot has issues recalling their own user ID and password for a domain. Note it's a set of three String, and it's one too many.
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.
I've seen implentations with some of these pieces, and I've found them universally awful. My many email addresses are not set up on all of the devices I use, requiring me to find a way to transmit the magic link from one device to another, often airgapped.
It's fine for a single device uses, but it breaks rapidly at scale.
i read sms was insecure because of sim swapping or something like that.
i like google authenticator app on android that generates a code that expires after a minute. that way no data is exchanged over the wire unless required.
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.
Many years ago while working support for a big brand enterprise Firewall company, I learnt that for any big business for which you expected security to be priority, the reality was - usability always wins, if you put your money to the contrary, you will lose
Fido auth may be ok but please, stop the "magic link" or SMS authentication.
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.
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/EdDSA or (rarely) >2048 bit keys for RSASSA. Not biometrics.
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.
>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.
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.