Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sick of spending time on Auth, we built an open source 'Stripe for Auth'

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 347 posts

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#261

Post by tialaramex »

munchbunny wrote: post #22

Interesting idea! I did a quick look through your site and have a few issues: 1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection? 2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this? 3. Password reset emails come from @su…

Note that WebAuthn (the standardized replacement for U2F, you should not deploy U2F today) is deliberately designed to authenticate to the site you're actually visiting. It is possible (but not necessarily in all browsers) to override this and authenticate to an iframe for example to allow a third party to authenticate but this creates yet a further problem to deal with:

Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.

Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.

But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.

And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#262

Post by movedx »

Armisael16 wrote: post #260
movedx wrote: post #257

Earlier quoted context omitted.

I don't believe that's required. I'm not saying I'm better than anyone else, I'm simply pointing out that having now slowed down and become more patient, I don't complain when accessing information from the other side of the planet takes 3 minutes instead of 3 seconds. That is what this essentially boils down to: convenience and patience. We're losing the latter because of the former.

You may want to work on your phrasing then, because that was sure the way it came off. You say that culturally we’re a certain way and then that you feel that you’re a better person for being different.

I'll take onboard for next time. Appreciate it.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#263

Post by RandallBrown »

dragonwriter wrote: post #240
RandallBrown wrote: post #228

Earlier quoted context omitted.

I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on. There's something very appealing about not having a password that I need to store anywhere for that service too.

> I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on. MFA usually uses channels that are intended to be relative low latency (or that don't require realtime out-of-band transmission, like TOTP). Email, OTOH, isn't generally reliably low-latency

Is there a technical detail of email that I don't know about that makes it less low-latency than a text message?

Email or text would work the same for this auth scheme anyway.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#265

Post by eloff »

pwdisswordfish4 wrote: post #248
eloff wrote: post #189

Earlier quoted context omitted.

I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where…

> We changed how our sessions work to get around it In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with. The only real quibble here might be that duplicate requests cost you unnecessary transit.

Duplicate POST requests are a violation of the HTTP standard because they are not assumed to be idempotent. I hope you're just misunderstanding the problem.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#267

Post by WatchDog »

Simple, JWT, pick one.

Really don't understand the obsession with JWT, especially if you don't need SSO.

Only real advantage of JWT, vs the tried and true random session_id+database approach, is that you don't need the DB.

What useful web application needs auth, and doesn't already have a DB?

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#268

Post by kennethh »

d33lio wrote: post #43
munchbunny wrote: post #22

Interesting idea! I did a quick look through your site and have a few issues: 1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection? 2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this? 3. Password reset emails come from @su…

I second this! Please prioritize TOTP / U2F over social logins. I might be off base here, but does anyone really leverage social logins anymore? Seems like it's the worst case scenario for auth in the case that a customer can no longer access the associated social account? Basically in every case you'd have to provide an antiquated flow for them to "re" sign-up with an email. I'm genuinely curious of the value add he…

I always use social logins if I can, much easier for me and no password to remember (even if I use password manager). I think most people (non techie) use social login.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#269

Post by mst »

eloff wrote: post #206
schoolornot wrote: post #201

Earlier quoted context omitted.

Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or f…

The changing ips were ok, it just made diagnosing the issue difficult in the logs. The duplicate requests (not at the packet level as TCP ignores duplicate packets) were the root cause of the issue.

Reminds me of the "fun" of dealing with a RADIUS system that would, about 20% of the time, send me two START packets for the same session ... with different sequence numbers.

This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)

Post reply on HN