Fast – One-click sign up, login and checkout | Hacker News Reader

Fast – One-click sign up, login and checkout

fast.co

66 pointscocoflunchy49 comments

I like that they incorporated under "Fast AF, Inc".

"Our mobile app is coming to iOS and Android devices with all new amazing features."

If your entire business centers around "one click"... then what features would that app even have?

You could imagine it'd be easier/nicer for the App to get the request instead of sending the email and simply click on a notification which does an auto-login.

Also being able to manage your logins and account via an App instead of their website which is always appreciated.

Good points. They should mention what's planned.

Features don't matter: the value proposition does, and if it solves a pain for a customer, it's a winner.

Is this a 100% proprietary authentication protocol? I'd say something snarky, but I'm still bitter about Mozilla Persona.

Mozilla Persona was on GitHub all along was it not? Not sure what the issue with that one was.

https://github.com/mozilla/persona

> # Self-hosting Persona

> This approach is not recommended most reliers. Persona has a large and complex codebase that has not seen significant development in several years, and Mozilla will not provide security or maintenance updates after 30th November 2016.

https://wiki.mozilla.org/Identity/Persona_Shutdown_Guideline...

Doesn't seem like a very good option for people today...

I know today it is abandoned, but I'm wondering about when it was actively developed.

It was a federated system. The idea was more or less that your email provider would host an instance of Persona, and if you were logged into webmail you could be logged in anywhere with a click or two.

But nobody used it. No email providers, no websites. You could fall back to Mozilla's Persona instance to try it out, but the user experience was not amazing. It kinda fizzled out.

https://wiki.mozilla.org/Identity/Persona_AAR

Yeah these closed-platform protocols can take a hike. Zero interest. Stop trying to build a business around the needless reinvention of the wheel.

I don't like frictionless sign up. It leads to anti-patterns like Google's "Sign in With Google" that appears 1-5 seconds after the page loads and with zero confirmation means it's trivial to click by accident. The moment you do your email is shared with the site you're on.

Any other antipatterns? Because that one doesn't seem to apply here.

It looks like a single-sign on (SSO) Identity Provider that's backed by just your email address.

It's not the worst idea, especially for low risk stuff. I'm not sure I'd use it for ecommerce though.

Even for high risk stuff probably as long as your Email is actually treated as important to secure (e.g. Security Keys and etc.)

I don’t see why you wouldn’t use it for e-commerce. Are you worried about CC numbers? Assuming Apple Pay, Stripe the CC is tokenised on the e-commerce store’s end.

Monzo do this for your actual bank account. Basically it relies on your email being secure. If your email isn't secure, you're fucked anyway.

Given the amount of people I've seen using 'forgot-password'-feature every time to log in, I wonder why 'email-as-identity-provider' isn't used more ofter. Especially for 'casual' sites you use rarely.

Any idea, other than maybe phishing?

I assume other than phishing it's also the poor UX of switching to your email inbox and then back to the browser, which can be especially bad on mobile.

That being said, I like the idea and have asked myself that question before as well.

And yet many people are already doing that because of two-factor security codes many services use to make sure it's you.

Doesn't Medium do this?

You can do this for logging into Slack IIRC (might be mobile only?).

Slack’s magic link works on mobile and desktop.

If you mean login through email link, firebase auth provides a very easy implementation of it.

Mozilla tried that once and failed. I really miss it. https://en.wikipedia.org/wiki/Mozilla_Persona

I've spent some time playing around with it and it seems like this particular implementation is unsafe.

Scenario:

1. I enter my email address on the sign in screen on Fast.co in Tab A.

2. I get an email with a "Login" button in it in Tab B.

3. I click the "Login" button and it opens Tab C and tells me I'm now logged in in Tab A.

4. I go back to Tab A and I'm logged in.

Here's the problem: A hacker sitting next to me see's me type my email in to Fast.co or some site that uses Fast login. They type my email in too. I get two emails with Login buttons. How do I know which one logs me in and which one logs in the hacker? If I click the wrong one, the hacker gets a cookie on their machine that gives them access to my account for 30 days.

Hopefully the link has to be opened on the browser that initiated the original login request.

It does not. I was able to start the login process on my desktop, click "Login" in the email sent to my phone, and it logged me in on my desktop.

Just tried the same and then entered my email again from another browser shortly after, as you suggested. The first sign in link expired but if your email client displays threaded messages you could very easily click the second and think nothing of it.

That would allow the attacker in straight away, while also allowing your original browser in with a bit of faff. There's an active session list, but presumably most users wouldn't be looking at that.

Certainly made me more sceptical as I was otherwise quite interested!

Perhaps an identifier can be used so the user can quickly verify the email matches the page.

It could be something like a sequence of 3 emojis because matching numbers is hard.

This could be a parody site for the SSO movement of the early 2010s.

> We’re not saying we’re famous, but.. [Product Hunt]

I don't know how to put it mildly, but ... jeez, lol. PH ranking doesn't correlate much with the quality of the products. All this says is that you managed to score some Internet points on a site popular in the SV echo chamber and that you think it's worthy a mention.

From the context they come this is quite something, I would say. It's a start up that made it to the front page of HN, product hunt, etc... :)

This is essentially a souped-up https://portier.github.io/

I applaud the initiative, since it removes the couple steps it takes a user to reset their password via "Forgot password" flows. However, this type of auth should really be self-hosted or baked into the most popular frameworks, instead of provided by (yet) another third party you'd have to trust with your users' email address (at the very least).

Pre smartphones I would have hated this, but I'd argue it's probably easier on mobile than desktop now, so probably quite useful. 99% of everyone I know has email pop up. You'd just click the pop up and click the button in the email (I assume).

Raises an interesting attribution problem when Gmail opens it in its own browser though... Unless the email is passing stuff as tracking, those ecom sales are gonna be hard to track...

I assume this idea behind this is to expedite the login and checkout process? If so, I don't see how it would actually be faster or easier. It's simple and easy for me to just grab the password from my password manager. I absolutely do not want to have to log in or check my email to log into a site unless it has something to do with 2FA - and even then I prefer an authenticator app.

you are not like most people. most people don't use a password manager, nor will they ever. Most use an excel file and have them written down somewhere... So when they are confronted with a login, and they don't remember the password, they either just leave or attempt to retrieve it or go through the mundane take of using the a dismal password retrieval process.

I'm not sure this is true anymore. Chrome and mobile browsers have built in password managers that automatically sync across your devices.

almost everyone i know has the remember password feature disabled because:

a) they don't want their passwords going Google. b) it's annoying when you saved the wrong one by mistake and now it auto-fills it every time. c) there is no reason to use one since they only use a bank of 5 or less passwords across all their accounts.

This looks like a fast acquisition target.

So if this is free, and they're paying to send emails.. how are they making money?

probably a cut of the order amount when you use their checkout.

VCs are paying for it :)

Paying to send emails? I assume you mean something like Twilio? For a company providing this type of service, I would imagine they would have written the core code themselves and email is pretty basic/simple to send (stuff like texting is much more complicated). I would be shocked if they actually just plugged in something like Twilio to farm out their core service.

Whether they pay for a bulk sending service or host a mail server and keep a few engineers, they're still paying.

I am wondering what makes them different from... Let's say passwordless Auth0...

I use the video conferencing site https://whereby.com and they have used a very similar scheme for quite a while now.

Seems I need to sign in to find out what the product is. Great.

i really want to know how this works.

Reply on news.ycombinator.com