Hacker News Reader

Comment by InitialBP | Hacker News Reader

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.

View on HN

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.

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...

> 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.

> 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.

Reply on news.ycombinator.com