231–240 of 247 posts
Earlier quoted context omitted.
CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.
Yes, that's precisely why CORS is a poor fit for authentication :)
Earlier quoted context omitted.
Yes, that's precisely why CORS is a poor fit for authentication :)
Sure, but I don't see why the tip in OP is "don't use CORS". To me that implies there is actually something insecure about using it.
Earlier quoted context omitted.
What they said.. - Your authentication problems are not unique to you; - The effort of implementing standards (whether it's front end like OAuth, OIDC, or SAML or back end like hashing) is a pain in the butt and easy to make bad choices; - If your project is successful or as your requirements change over time, now you have to figure out how to add MFA, password resets, internationalization, address security audits, e…
Hey man, funny thing, I just completed your 3 courses on Lynda.com on the REST API learning path yesterday. I did the Design one, the Validation and Authentication one and the OAuth/OpenID one. Good stuff. Also, I have a question for you, is there a good place to reach you?
you need an expert, someone that doesn’t need to ask this question.
Once we lost the user account DB at a startup to database data loss and some other day, someone logged into mongodb and dropped all the tables and backups were not test before, so they did not work. After that we no longer store these details. We've been using amazon cognito with lambda authorizers.
Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…
What’s the difference between a Bearer Token and JWT? I thought they were related?
A JWT token is composed of three parts: a header, payload, and signature.
The problem is that people can put sensitive info in the payload.
None of it is encrypted, it's only signed with HMAC.
Unless you're keeping track of the tokens, once a token is issued it's valid until it expires, due to it's stateless nature.
You can use a JWT as a Bearer token, but since it's only base64 encoded, you can pull out that payload data.
A truly opaque Bearer token will be meaningless to anything other than your server.
Play with the debugger here to see what I'm talking about: https://jwt.io/
Earlier quoted context omitted.
Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway. The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all.…
> competent attackers will simply run their code from the victim's browser and session What do you mean? JS even on the same page can't read HTTPOnly cookies. If you are assuming that the browser has been hacked then it is pretty much game over regardless of what you use.
Earlier quoted context omitted.
That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?
How can they send authenticated requests if they can't access your cookies and your backend ignores the cookie header?
Earlier quoted context omitted.
This is not accounting for reconnect scenarios. With sessionId, if the user loses the connection and reconnects, there will need to be another DB lookup to verify that the sessionId is valid. This is not the case with JWT. The validity of the JWT can be checked without any DB lookups. Also, this is a security consideration because a malicious user could intentionally send fake sessionIds to make us DoS our database.…
You can sign session ids to prevent DoS, and you can cache session ids to avoid database lookups, but you can't detect forged or stolen JWT tokens.
You can steal a JWT token the same way you can steal a session token.