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

Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#31

Post by InitialBP »

sam0x17 wrote: post #26
InitialBP wrote: post #24

Earlier quoted context omitted.

I'd go a step further and stay the author is really making security researchers look bad. Can't really blame anyone for being concerned about corporate retaliation, but there are most certainly institutions that would send an email on your behalf to disclose vulnerabilities to a security@ email if you wanted to remain anonymous out of a sense of caution. On top of that you've made some inflated comments on the genera…

I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arri…

According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#32

Post by withinboredom »

simonw wrote: post #15

I've been trying to figure out options for 100% robust protection against CSRF for late 2022 (without using csrftokens in requests, which are tried and tested but are a little bit cludgy to build and use). It's proving surprisingly difficult to research. Here are my notes so far: https://github.com/simonw/public-notes/issues/2 SameSite=Lax is almost but not quite the answer I'm looking for, for a couple of reasons: -…

Lax plus http-only+secure is probably the best solution atm. I can’t remember details, but IIRC, that should work for the last 10 years or so.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#33

Post by mcstempel »

I’m the founder/CEO at Stytch, and the amount of misinformation and direct falsehoods in this post are pretty jarring. I’m surprised this has gotten any traction on HN, but I’m happy to go point-by-point:

- OP claims we do not have a bug bounty program. We do have a private bug bounty program. We also triage all reports that are sent to security@stytch.com. In addition to this, we have an in-house security engineering team and work with an external firm.

- OP claims we do not have a responsible disclosure program. We do [1]

- On the point about CSRF, OP is correct that login CSRF scenarios are common with magic link products. For the uninitiated, Login CSRF is a vulnerability where an attacker gets a victim to log into an account controlled by the attacker, instead of their own. For example, an attacker could forward a magic link email to a victim, who clicks it unknowingly and ends up logged into the attacker’s account. Stytch adapted PKCE [2] to magic links so that applications have cryptographic proof that the device clicking on the magic link is the same device that originally requested the magic link. Our PKCE design was audited by our external security consultant. PKCE - as well as other more contemporary cookie-based CSRF measures - are not effective on mobile applications due to heavy use of webviews. Often, there is no guarantee that the browser on the device (perhaps an embedded webview within an application) that requests the magic link is the same browser that is opened by the email client when the magic link is received. For mobile-centric customers with workloads that are sensitive to login CSRF, we recommend pairing magic links with one of our second factor products such as SMS OTP, TOTP, or WebAuthn.

- On their point about OTP tokens, it’s unclear if they’re talking about our magic link product or our actual one-time passcode products. In either case, the author is incorrect. Each product behaves slightly differently. For email/SMS/whatsapp one-time passcodes, these tokens expire both a) after first-time use and b) if the developer initiates a new one. For magic links, the token is invalidated once it is consumed or when it expires (whichever comes first). Their description of default behavior is also misleading. For example, while a sign-up magic link defaults to 1 week expiration (and can be configured lower) due to common email confirmation flows at sign-up, a login magic link has a lower default expiration at 1 hour. For OTP codes, the default code expires in 2 minutes and the longest it can be valid for is 10 minutes (this distinction is by design as there’s less entropy with a 6-digit code than a magic link token)

[1] https://stytch.com/docs/#security_overview [2] https://stytch.com/docs/magic-links#email-magic-links_adding...

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#34

Post by mcstempel »

InitialBP wrote: post #31
sam0x17 wrote: post #26

Earlier quoted context omitted.

I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arri…

According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).

Hey there, I'm the founder/CEO at Stytch. I provided some more responses in this reply on the general post, but I'd also add that login and sign up links are invalidated after their first-time use

https://news.ycombinator.com/reply?id=33164969&goto=item%3Fi...

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#35

Post by mooreds »

InitialBP wrote: post #31
sam0x17 wrote: post #26

Earlier quoted context omitted.

I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arri…

According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).

> just invalidate them after use

I can't speak for Stytch, but I know at $CURJOB, we have run into issues with this where corporate phishing protection software invalidates one time use codes. I believe it does that because it retrieves links in emails before the user clicks on them. This was an issue several of our customers have raised. So it isn't as straightforward as you might think.

There's more details, including the workaround we ended up using, on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/629

PS I agree they should absolutely have guidance around link lifetime as well as safe defaults. Converting the links to one-time use seems like a good start.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#36

Post by jabart »

simonw wrote: post #15

I've been trying to figure out options for 100% robust protection against CSRF for late 2022 (without using csrftokens in requests, which are tried and tested but are a little bit cludgy to build and use). It's proving surprisingly difficult to research. Here are my notes so far: https://github.com/simonw/public-notes/issues/2 SameSite=Lax is almost but not quite the answer I'm looking for, for a couple of reasons: -…

95.75% is pretty close to solid for SameSite. Those same 4.25% of users who don't support same site are using IE6-10 (.15%), Firefox <2018 (.44%), Chrome <2016 (.35%). The amount of vulnerabilities in those browsers are huge and likely just are leaking cookies anyway through known issues that have since been patched. I'm not spending any time working bugs on IE 6-10 just to get to 100%.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#37

Post by mcstempel »

nrmitchi wrote: post #21
djbusby wrote: post #13

This reads like it boils down to Stytch sends magic tokens that both authenticate and don't expire. Is that right? And the fix is...expire properly and make the user re-auth or? Maybe it's like this to handle when the link is opened in a different browsing session?

I don't think that's exactly the point, but yes, it's what the author here is directly stating. Unless I'm misunderstanding, the underlying concern is that Stytch is: - A new authentication company, that focuses 100% on authentication, and - Has raised an absolutely insane amount of money for that, and - Has extremely novice and easy-to-fix issues, and - Those mistakes aren't being immediately addressed I'm not sayin…

I think your summary of how the post is framed is correct, but as the founder/CEO of Stytch, I wanted to call out that the claims of the author are incorrect. https://news.ycombinator.com/reply?id=33164969&goto=item%3Fi...

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#38

Post by sam0x17 »

Aaronstotle wrote: post #25
sam0x17 wrote: post #22

Earlier quoted context omitted.

It really wasn't a joke when we went through the process at Arist (YC S20) I can tell you. Pen tester found some really meaningful privilege escalation stuff we were able to fix before launching our new platform that was 100% specific to our system and never would have come up in an automated scanner and went through our entire threat model with great detail. Additionally, the automated scanners at least catch CSRF s…

Unfortunately there is a large quality range for pen-tests. There are some that are meant to check the box and others that actually find vulnerabilities.

Right but there is a ring of accountability -- the compliance vendor (Vanta) should only refer startups to good auditors and pen testers. The auditor should verify that the pen tester is reputable, and the pen tester should check for basic things like this that would show up in an automated scan. Every link in the chain seems to have failed here, but Vanta is the one that did the initial referring presumably.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#39

Post by O__________O »

O__________O wrote: post #16

Author links to the docs, but fails to mention if they emailed security@stytch.com - which has not only been in docs since at least late 2021, but also found doing a simple Google: - https://stytch.com/docs/#security_overview * Note: Search for “security@“ on link above. - https://web.archive.org/web/20210801185042/https://stytch.co... - https://www.google.com/search?q=stytch+security+disclosure To me, little strange…

Stytch CEO posted a response here:

https://news.ycombinator.com/item?id=33164969

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#40

Post by sam0x17 »

InitialBP wrote: post #31
sam0x17 wrote: post #26

Earlier quoted context omitted.

I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arri…

According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).

> the fix is probably straightforward

Something I totally agree with before you've passed multiple audits. At this stage it's more a question of how the hell did this slip by 2 pen tests and 2 external audits (since they will have had to renew their SOC-2 by now.

The "how this slipped through" is much more concerning than "what slipped through", though the "what slipped through" here is also rather serious imo.

Post reply on HN