4 ms·
1. You could do the same in a BasicAuth system. 2. How is validating the session-cookie validity different from validating the username/password?
by usrbinbash 5y ago
1. You could do the same in a BasicAuth system.
2. How is validating the session-cookie validity different from validating the username/password?
- jerf 5y agoFor 2, in many cases validating username/password requires hitting an external system. If you want to give your IT department a fun day, write a moderately popular internal web service that accidentally hits LDAP freshly for every single web request. It's really easy to accidentally do in some environments. Session cookie validation will typically only involve local resources. For many of my internal tools I don't even bother with a database and just store it in local RAM, especially when I have no other database involvement, because having all sessions reset every few months during a reboot or restart is worth it to not have to stand up a database solely for that purpose. In that case it's just a quick lock&lookup in a map/dict/whatever your language favors to see if the token matches or not.
- marcosdumay 5y ago> How is validating the session-cookie validity different from validating the username/password? Validating codes is done with fast crypto algorithms, while validating passwords uses purposefully slow algorithms.
- freedomben 5y agoA non-trivial difference is that to validate password you need to run it through bcrypt or similar algorithm which is intentionally slow. With a token or cookie, you can use a regular fast hashing algorithm.
- usrbinbash 5y agoNothing prevents me from using BaseAuth for the login, and then issuing a session cookie to the user.