130

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 ...


89

This is not a trivial, simplistic question. There are several different aspects you need to consider, and several different mechanisms and countermeasures that apply to several different threats in several different scenarios that are affected by several different clients. Let's examine these one at a time. (There will be a TL;DR at the end...) If you're ...


82

First, linking a session to an IP address will not make it secure since the server could see many different users as using the same IP address for various reasons (all types of proxy servers, for instance: client, reverse proxy, CDN, etc.). Second, the same user could very well use different IP addresses for the same session. For instance, someone could be ...


60

There's no "one answer fits all" here. If it's simply a social media app, it might be sufficient to allow concurrent sessions, but also offer a way to terminate one or all sessions if the account is compromised. For many types of games, concurrent access means cheating, so should probably be disallowed, or at least designed in a way that the account can't ...


58

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 ...


56

Yes, if you can guess another user's session key then you can become them. This is why you need to have a unpredictable session key that can be revoked. There have been cases where best practice haven't been followed, for example Moonpig produced an API which used a session key that was the user's ID which is set on account creation as a consecutive number....


42

Yes it is possible, and this technique is widely used. It does have some minor drawbacks compared to stateful sessions: It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires. The use of a server-side secret ...


40

When logging in to a web service, a cookie is planted in your browser. This cookie has a unique ID value that identifies you while you're using the web service, and, possibly, when you come back later. If, somehow*, that identifier was stolen, the person possessing it could, possibly, use your account as if he was you. Logging out, usually, invalidates this ...


40

After a bit of searching, it seems some banks are giving this advice following an attack on a bank that allowed users or malicious websites to reuse persistent cookies after a user had logged out, allegedly because other browser tabs were left open on the site in question and so the browser had not cleared the cookies yet. The reason such a vulnerability ...


40

Yes, you should still mark your cookies as secure, for three reasons: You dont want them to be exposed just because of a server configuration mishap. What if you move your application to a server with a different configuration? HSTS is trust on first use. If your HSTS has expired but your cookies has not, the browser may send them unencrypted. Whether or ...


29

I've heard that cookies is less secure than the session. You must have misinterpreted something. In fact HTTP sessions are usually implemented using cookies. I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right? Sure you can change the cookie, but will it be accepted by the server as valid? If you take an ...


26

Yes. It can. Session information is stored in server side (except the session token) while cookies in the other way are stored in the client side (browser). So the attacker might change the session token to hijack a session. The attack is commonly known as session hijacking through cookie manipulation. But the attacker must use a valid session token which ...


22

Here are some suggestions. None of this will give you the same level of security as TLS would, though. Don't use the site unless you really have to. But since you ask, I assume you do. If you visit it, use a VPN (or Tor) as often as possible. An attacker would have to get in the middle of your VPN exit and the server in question, which is harder than ...


21

A more complete answer from http://hueniverse.com/2015/07/08/on-securing-web-session-ids/ 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 your system you should hire an expert ...


21

TLDR; SHA256 is good enough To answer this we need to look at why we salt, hash, and use multiple iterations of the hash, in the first place; Why do we salt? To protect users that have weak password entropy from having their password cracked (e.g. rainbow tables or two users with the same password). This is not an issue because UUID4 will have 122 bits of ...


19

In principle, values stored in sessionStorage are restricted to the same scheme + hostname + unique port, and if the browser has a clean exit these values should be deleted at the end of the session. However, according to this post it can survive a browser restart if the user chooses to "restore the session" after a crash (which means its values also exist ...


18

There seems to be some confusion between cookeis and session information here, so lets start by sorting that out: Cookies are stored on the client. The user can therefore change them if they want to. Session information is stored on the server. That means the user can not change it. "Never trust the client" is an old rule in security. That means that you ...


17

Why do Firefox and Chrome allow such easy leaking of these session keys? To make it easier for developers to analyze their network captures. The first time I used this feature was when trying to understand what protocol is exactly used by the web-based noVNC. Using this functionality, I was able to decrypt the traffic in Wireshark. I read some ...


16

From the perspective of the site developer, you should use the following: Adopt SSL: use SSL sitewide. Set the secure flag on all cookies. This will ensure that they are only sent over a SSL connection. Turn on HSTS. This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks. Search ...


16

Generically, it is possible to "store" state information on the client, even sensitive information such as authentication data; such storage is used to save resources on the server, e.g. to minimize database load. See these previous questions: Is it possible to have authentication without state Demystifying Web Authentication (Stateless Session Cookies) Is ...


16

Back in the day, AOL was notorious for aggressively load-balancing traffic between its internal network and the Internet across all its exit proxies. This meant that a request for a single web page and its content would come from many different IP addresses: if you pinned a session to a single IP address, the session would break before the "login successful"...


15

The connection between the client and the server does not use public key encryption (that is only used for the initial key exchange). A different algorithm is used for encryption (usually a symmetric encryption), such as AES-256-CBC on a TLS 1.2 connection. So unless you intercepted it, no one but the intended browser and the original server can decrypt the ...


14

In SSL, the client and server may engage in an abbreviated handshake only if both client and server remember the "handshake parameters" (in particular the negotiated pre-master secret). The "session ID" is how the client and server advertise their remembrance: the client sends in its ClientHello a copy of the previous session ID, and the server sends it back ...


14

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 your system ...


14

Not all browsers honor HSTS. IE mobile doesn't, for example; desktop IE only does since version 11; cloud-based browsers like Opera Mini don't. Marking your cookies as secure is trivial and good defense in depth.


13

It's for your security. This way people can't accidentally stay logged into their account, so anyone with access to your computer has full access to your bank account. This way thieves don't have motivation to break into your house to steal your computer not just for the value of the computer, but potentially to get access to your life's savings and use it ...


13

If a client is compromised then that client is compromised. Session tickets don't change that one way or another... Session tickets are a TLS extension by which the server pushes the session context into the client. From the point of view of the client, the ticket is opaque. To prevent ticket forgery or alteration by malicious clients, the server is ...


13

Session Hijacking through sessionId brute-forcing possible? Probably not. owasp says that a session identifier should be at least 128 bit long to prevent session bruteforcing. They give these example calculations: With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per ...


11

I'll try and provide an answer to this question in a manner inverse to the one's already posted above. What are the risks associated with idle sessions in web applications? Session Cookie Theft via XSS (if the session is not tied to the IP) Cross Site Request Forgery (on the idle but still authenticated session). Man In The Middle Attacks (using a sniffed ...


Only top voted, non community-wiki answers of a minimum length are eligible