Tag Info

New answers tagged

3

That should never happen. User is requesting your site via https://example.com. The user's browser will expect the server to provide a cert with hostname of example.com. Hacker can not MITM that as hacker will not have the example.com private key to sign a message and authenticate as example.com. User's browser will report an severe warning. If hacker ...


0

Adding ASP.NET Identity should not be that big of a job. Guide here. Session has not been designed as an authorisation mechanism. It has some characteristics that make it unsuitable such as using the same identifier pre and post authentication, making it vulnerable to session fixation. Also, it is difficult to check authorisation status for page access, as ...


1

Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in). Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ...


3

Eran Hammer, one of the maintainers of the yar session management module for NodeJS, had this to say on the matter: Disclaimer: like any security advice from someone who doesn't know the specifics of your own system, this is for educational purposes only. Security is a complex and very specific area and if you are concerned about the security of ...


29

The author of that JS library seems to have made a common, yet mistaken, assumption, though based on just enough knowledge to get things wrong. You can't just sprinkle magik crypto faerie dust and expect to get more security, like chocolate chips. What the author is missing is that once you sign the session id, and put that in the cookie - the signed ...


0

In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is ...


2

You've misunderstood the cookie issue for Safari/Chrome, I think. Both of them implement the RFC properly, whereas Firefox/IE have been more relaxed in the past. The normal rules are: Setting a cookie for xyz.com does not allow any subdomains to read it. Setting a cookie for .xyz.com allows all subdomains to read it. Setting a cookie for app1.xyz.com only ...



Top 50 recent answers are included