3 ms·
Cool article - but the author didn't even scrape the surface of making this secure. Don't even use this in development. 1. Make sure to use HTTPS (TLS v1.2 or
by netsectoday 7y ago
Cool article - but the author didn't even scrape the surface of making this secure. Don't even use this in development.
1. Make sure to use HTTPS (TLS v1.2 or v1.3).
2. Tag your cookie as HttpOnly so only Node can read it (not the web browser).
3. Tag your cookie as Secure so it doesn't get leaked on a 301 HTTP redirect to HTTPS.
4. Add a HSTS security header to perform an automatic 307 internal browser redirect to HTTPS.
5. Plaintext passwords in the database? Use bcrypt.
6. Plaintext passwords across the network? Hmac it with a timestamp, send the digest and timestamp, validate the digest hasn't been used before and is within a specific time limit - stop credential replay attacks.
7. Include a CRSF token in the form post to stop login replay attacks across your SSO instances.
8. CSPRNG is very important! Make sure you use a cryptographically secure pseudo-random number generator!!!
9. Don't get hit by password timing attacks! Use Node.js crypto.timingSafeEqual(a,b) to verify a password (however this should just be bcrypt).
10. Lock your JWT token to your user agent and IP (an HMAC digest you can verify so as not to leak the original values if the token is compromised). Verify on each request.
I'm sure there are many more suggestions to fix this SSO solution that I haven't mentioned. This article is like explaining how to build a bank vault and the author decided a cardboard box was good enough for you.
- scrollaway 7y agoLocking jwt to IP breaks mobile auth where you may be hopping between wifis and 4g. Agreed with the rest of your post
- netsectoday 7y agoYes, you are right. You need to balance that tradeoff with your application/business risk profile. High-security applications or those not tailored for mobile can still lock the IP to the JWT.