Live data from Hacker News

Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

news.ycombinator.com

21–30 of 52 posts

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

#21
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 saying that people aren't allowed to make mistakes, and auth mistakes can be very easy to make, but it's way more concerning if you're claiming to be the "Future of User Authentication" while making them.

Edit: formatting

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

#22
post #14
post #5

Even more damning, looks like they got a SOC-2 Type II via Vanta in July of 2021. I just had to go through SOC-2 Type II at two startups in the last few years so I'm very familiar with the requirements. How the hell did they pass multiple penetration tests and a third party audit with such blatent security issues that an automated scan would detect? If anything, I think this says something much more damning about Van…

SOC2 is a joke and pen testers usually do a terrible job. Almost all of SOC2 has nothing to do with whether you built secure software. It seems like pen testers usually just run standard scanners, report all the false positives, and then call the job done. If your software team has been writing millions of lines of code for years, how can you expect someone to find actual security issues in something they have never…

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 stuff. Somehow they even missed that here

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

#23

throwaway because I am in the ecosystem Stytch... is a weird business. It's unclear to me why they were able to raise so much money with such low revenue. It's almost as if the VCs really really wanted them to succeed, hoping and dreaming and throwing cash into the fire. there was a lot of fanfare around their founding team but not sure if they did that much at their previous employer.

To be fair, there are examples of this in almost every industry and/or software-product vertical.

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

#24

Either I'm missing something here or the login CSRF explained in the report is a very weird and not exceptional impactful vulnerability. As described the author is talking about using a CSRF attack to force someone to authenticate to a service that uses Stytch. Regardless this is a HUGE stretch to say "has no CRSF-protection in their authentication API". You've shown one instance where they don't have CSRF protection…

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 general security practices about this company with no real evidence and the vulnerabilities listed best-practices at best and inconsequential at worst.

I question the motives behind a post like this:

Does the author have some financial incentive to attempt to discredit Stytch? Does the author want to cause some panic/concern by making scary claims about Stytch? Does the author not truly understand the impact of their vulns and thing that this is a serious issue when it's not?

I can't say but the whole situation really sits wrong with me.

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

#25
post #22
post #14

Earlier quoted context omitted.

SOC2 is a joke and pen testers usually do a terrible job. Almost all of SOC2 has nothing to do with whether you built secure software. It seems like pen testers usually just run standard scanners, report all the false positives, and then call the job done. If your software team has been writing millions of lines of code for years, how can you expect someone to find actual security issues in something they have never…

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.

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

#26

Either I'm missing something here or the login CSRF explained in the report is a very weird and not exceptional impactful vulnerability. As described the author is talking about using a CSRF attack to force someone to authenticate to a service that uses Stytch. Regardless this is a HUGE stretch to say "has no CRSF-protection in their authentication API". You've shown one instance where they don't have CSRF protection…

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 arriving, and you have 7-x days to compromise their account. This is very different from almost any other magic link which by convention are always consume-on-use with a short expiration and often a context cookie reqiurement.

Imagine the CTO is screen sharing and a notification showing the code part of the link shows up without them noticing and now anyone on the call who noticed has a week to login as the CTO. This stuff can happen way easier than you think.

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

#28
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: -…

How about asserting that the referrer must have at least a matching origin, or better yet path?

I don’t immediately know of any sane configurations that strip a same-origin referrer, but that would cause every request to be blocked as cross-site.

Spoofing a third-party referrer to same-origin is rare, but occasionally done (I think uMatrix defaults to doing that). And unfortunately, it looks like Firefox at least (the only one I’ve checked) includes a trailing slash on third-party referrers rather than only including the origin (that is, it sends `Referer: https://example.com/` for different-origin requests rather than `Referer: https://example.com` like I hoped), so you can’t completely reliably distinguish between an actual first-party request of /, and a spoofed third-party request. But if you’re OK blacklisting the root path, it’d work.

(Actually, what about the Origin header? I’m a little rusty on current statuses and usages of the Origin and Referer headers; haven’t been doing loginny HTTP for a few years. Can’t remember how old the Origin header is, either. But is there some reason you’re not just going for it?)

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

#29
post #22
post #14

Earlier quoted context omitted.

SOC2 is a joke and pen testers usually do a terrible job. Almost all of SOC2 has nothing to do with whether you built secure software. It seems like pen testers usually just run standard scanners, report all the false positives, and then call the job done. If your software team has been writing millions of lines of code for years, how can you expect someone to find actual security issues in something they have never…

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…

I mainly work with financial institutions and most of them have had their first real hands-on pentest in just the past year despite receiving audits (nessus scans) quarterly to yearly by various entities for decades (FDIC, state department of banking, cyber insurance, and the ATM vendor).

There's a lot of stuff that comes up in a properly driven pentest that nessus just doesn't do. Never had a nessus operator pass the hash into domain admin or pretend to be a Spectrum technician and hide in the closet until after hours.

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

#30

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…

* "The Wayback Machine has not archived that URL."

* The google search you linked it took me 2 minutes staring at the results page before I notifed the part where the relevant information comes up. It's on a sub-link with the heading "Docs", 80% of the way down the page in an h3. That's pretty damn buried.

I think it's safe to say they essentially phoned in and checked the box on the whole security disclosure thing. Do they meet the requirement technically? Yes. But the info is actually pretty buried so much so that archive.org has never seen it before. Should be on their site footer.

Post reply on HN