Recently I created an account on an ecommerce website. As usual I entered my name and email, and then they told me to check my inbox, etc. – the usual. When I came back, however, there was no place to choose a password. I had my 1Password ready to generate and store a fresh super-complicated 32-character password…but never got the chance.
Instead I saw this:
If you select Magic Link, you get a “click here to login” email, and with a OTP you get a 6-digit string to input. Either way, after that you’re logged in and those are the only two methods.
Every time I returned to the site, on whatever browser or device, I either did the email/click tango or was already logged in since I had the cookie.
On the one hand, having to go out to my email and come back is rather tedious. I would have preferred a texted OTP given that Safari will automatically paste those in for you when the arrive (a nice ecosystem feature of the Mac world). And since I already have a password manager with excellent browser integration, a password might actually be easier for me to manage.
However, not everyone does, and it occurred to me that this system is really a win-win, with a small caveat.
For the user, there are no passwords, which is a huge plus for a lot of people. If you think about your usual usage patterns, you login once and then use a web site for a long time without logging in. After some period of time or when you switch to a different device you go through the mechanics again, and then there’s another long period where you’re logged in. You’re going to have to go through the motions at some point, and the benefit here is that you pay the price but don’t onboard any password management.
There’s an even bigger benefit for the site. They can still get hacked – someone could break in, steal their content, get a list of users, etc. But you eliminate the hassle of people’s accounts getting compromised because they reused passwords from some other site that was hacked. Also, if you get hacked, the attacker can create a lot of cleanup for you, but you don’t have to go to all your customers and urge them to change their passwords.
The small caveat is that email is not encrypted. However, in today’s world, the email is encrypted on its connection to whatever mail server they’re using (in this specific example, Postmark), and encrypted along the email journey until it hits my email provider (Gmail). While it’s on the Google servers, it’s not encrypted, but then between Google and my device, it is.
The site is using Stytch, a company that makes nice SDKs for this and can handle some of the work (e.g., actually sending the links/codes), but it would be easy for someone to roll their own solution.
What do you think of this? Secure? Convenient? The wave of the future? Let us know what you think in the comments below!
Related Posts:
I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.
I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308
- Crunchbits Discontinuing Popular Annual Plans – The Community Mourns! - November 20, 2024
- RackNerd’s Black Friday 2024: Bigger, Better, and Now in Dublin! - November 19, 2024
- It’s the Season of Giving and CharityHost Has Deals for You! - November 18, 2024
I use Stytch on an enterprise multi tenant phone system, for browser based phone logins, and for management administration pages. Works quite well. I’m not a huge fan of the magic link solution, so my system defaults to OTP codes sent via SMS (I intend to implement their Authenticator style codes as well, but haven’t yet). Stytch now also supports passwords for applications where that makes sense, and I plan to use that also. Although technically you can roll your own system, the Stytch SDKs are quite good, and in my opinion the cost is reasonable, so it saved us a lot of time. The one downside, at least in my application is that in a complex system you generally have to track users in your system (we do, for billing details, contact info, IM account sync, etc.) so adding Stytch requires us to keep our user DB in sync with what Stytch provides (we do this via calling their APIs when a user is created on our system). In a simpler system that may not be necessary, and you could fully offload your users DB to them.
Thanks for the comment! The site I used didn’t seem to support an authenticator (e.g., google authenticator, etc.) which I would have found more convenient than getting a code by email. I have to think it’d be cheaper for the site as well since they won’t have to pay a fee for whatever mail delivery service they’re using.
Microsoft has been on an anti-password path for a while now, and last year released an option to have a passwordless Microsoft Account (for email, Skype, Office, Xbox, etc.). Their login options are better than the example in the article. You can choose from Windows Authenticator App Push, SMS, Email, phone call, Yubikeys, and biometrics. Google is not far behind.
https://www.microsoft.com/security/blog/2021/09/15/the-passwordless-future-is-here-for-your-microsoft-account/