Tag Info

New answers tagged

0

Is there any way we can avoid it? Yes, you could have a rolling session key. i.e. the server will generate a new Session ID to store in the cookie every n number of requests. The Set-Cookie header will only be sent once, so if there are two browsers logged into the same session, one of them will be using the old, invalid session. You could have a small ...


4

You could leverage local storage, but then you also risk exposing it a multi-user or public computer, or usability fail if the user uses multiple computers. In your email solution, you could add a special code/token/password in addition to your identifier. So you have the identifier (UUID) and then a secret. You do still have an exposure if the email is ...


2

Whether it's bad for security depends on whether the information they're entering could be considered "sensitive". Would it matter to the applicant if someone else could guess (however unlikely) their session id and get access to whatever data they've already entered? (Is confidentiality of the data important?) Would it matter to the organization who is ...


0

Cookies have an option to force encryption. Simply add secure; to the cookie header: Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly; httpOnly; protectes the cookie from JavaScript. See How can I check that my cookies are only sent over encrypted https and not http? Also keep in mind that users IP might change ...


2

The difference is : OAuth 2.0 is a standardized protocol, and there is many implementations in differents langages (JAVA, Python, PHP, JavaScript...etc) for both client and server sides. So you don't need to follow this article to implement something which "seems" similar to the OAuth 2.0 protocol and probably not secured. For the cookie-based token ...


4

The attacker never logs into the site with their credentials, they just access a page to get the session id, so while they pass on a valid session id to the victim, they do not pass on an authenticated session. When the victim logs into the site, the session is now authenticated and the attacker can access it as the victim.


4

The easiest way to invalidate all in memory sessions is simply to restart your application server(s), which will clear the in memory session cache and make everyone's session cookies invalid. Also, if you are using a login framework that supports persistent logins (you are if you have a 'remember me' checkbox on your login form), then you can and should ...


1

So long as your token is sufficiently long enough, I think you would be OK using simply SHA256. I'm not very familiar with PHP, but it looks like you are creating tokens of length 200, which would be more than sufficient. The reason that I would think that SHA256 would be OK is that the search space for a length token is so gigantic that it doesn't really ...



Top 50 recent answers are included