New answers tagged session-management
2
Yes, what you're saying makes sense.
By setting your cookie as an HttpOnly cookie, you're mitigating the risk of your partner's JavaScript having access to the user's session ID. Since your partner insists on getting a unique identifier for your customers, I see nothing wrong with sending them a securely hashed version of the session ID.
The key point here ...
0
The implementation 2/3 verification would work fine. I haven't tested this or even know if it's a viable method, but you could also implement a "changing key" of sorts where the session key changes with every request, lowering the attack window.
1
Is it feasible? Yes. It's a standard pattern for cookie-less session and was a de rigueur pattern for session management in JSP app for a number of years.
Is is a good idea? No, for a couple of reasons.
One of the primary vulnerabilities for a site that has a concept of session management is session hijacking, where the session id is sniffed and ...
3
It's a bad idea.
Encrypting the session identifier has no real impact on the security of your application. If the traffic is sent in plaintext (without SSL) anyone is able to read that encrypted session ID and then use it to impersonate the legitimate user.
Let's say my session ID is 12345. Every time I want to go to your house you ask me about my session ...
3
If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.
Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the ...
4
It's mostly just a gain. From a security perspective, sessions should expire quickly, but from a usability perspective, users don't want to have to constantly log in. If you are going to allow persistent login, then offering a mechanism to clear persistent logins is a good (almost mandatory) idea. This way a user can clean up after themselves if they ...
6
The feature is really useful from a security perspective as it allows users to easily notice if someone else is accessing the account. This is a really useful feature in the sort of attacks where the attacker would want to silently observe the account to obtain information without actually doing anything active which would draw attention to himself.
The ...
3
Yes there's a risk as this is a classic session fixation issue (OWASP Page). Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login. Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.
How much of an issue ...
-1
It's quite hard(more or less impossible) to figure out the session cookie of some other user. So if I modify my cookie, the server will just tell me that me session expired.
The session cookie is set by the server. A man in the middle cannot change what the server thinks the session cookie is.
Note that a man-in-the-middle attacker on a plaintext ...
0
This is a security concern, but not one that you can do anything about as the client can always set whatever session ID they want. If there is no session server-side with that ID then the user is likely to see a 'session expired' message and be forced to authenticate.
If an attacker is able to obtain the legitimate users' session ID there is the ...
1
"Session ID" is a general concept used in many places. It is "a name for a session". Whenever you have a session and you want to designate it (e.g. in a message in a network protocol), whatever you use to designate it is the "session ID". It can contain any characters or bytes that the said protocol says it can contain.
Every protocol is free to define ...
Top 50 recent answers are included
