109

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


81

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


55

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


53

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


42

Summary. Yes, this is possible. It's not a browser bug. It is part of the as-designed functionality of cookies. There is no browser that is safe from this. Cookies are ancient technology and their security model is only loosely-integrated with the rest of the web. The details are messy and ugly. The gory details The site blog.example.com can set ...


41

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

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


38

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


34

"Replay attacks" don't really apply to cookies, because a cookie is by definition something which is meant to be replayed: the user's browser sends back the same cookie value, and that is how your server knows that it is the same user. What you want to avoid is someone spying on the line, observing the cookie value, and then sending the same cookie on his ...


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


28

The basic concept of a session identifier is that it is a short-lived secret name for the session, a dynamic relationship which is under the control of the server (i.e. under the control of your code). It is up to you to decide when sessions starts and stop. The two security characteristics of a successful session identifier generation algorithm are: No two ...


27

Cookies have, historically, been a source of numerous security and privacy concerns. For example, tracker cookies can be used to identify which websites you've visited and what activities you've done on them: Site A includes hidden iframe that points at a tracker service. Tracker service issues a cookie that identifies you, and logs your visit. Site B ...


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

The basics First, I assume you understand the most basic session ID security right: you are using an ID with sufficient entropy, and you use transport level security (HTTPS). Any approach to session ID (URL, cookies, whatever) that does not get those right is vulnerable, your question is specifically about ID in URL, so I will not discuss that further. ...


21

With tracking cookies, advertisers can track users across different websites and even across IP addresses (e.g. for laptop users). This has been going on since forever (literally since the beginning of advertising networks, like Google Adwords), but recently the media has been inciting the public against those cookies, blaming them as the root cause for ...


20

The key factors I always look for in a Project Definition spec are missing here: What are you protecting? Who are you protecting it from? What is the impact if it is compromised? If you are protecting your list of friends birthdays it is almost certainly overkill. If you are protecting Top Secret material from International or Corporate espionage then it ...


18

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


17

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


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

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


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

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


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

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


14

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


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

Beware of overkill, it is counterproductive. If your login system is too inconvenient or annoying, users will actively try to work around it. "Users", here, includes application developers and server administrators. login form is SSL secured This one is the most important, but not "alone". Theoretically, the whole site should be secured with SSL, not ...


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