64

A typical web authentication workflow looks like this:

  1. User provides their credentials.
  2. Server validates credentials.
  3. If credentials are valid
    • Server generates a token.
    • Server keeps this token.
    • Server responds to the login with this token.
  4. Browser stores token.
  5. Browser makes requests with token.
  6. Server validates token and responds accordingly.

Normally, this token is stored in a cookie. The presence and validity of the token in a request lets the server know if the client making the request is authenticated. No token, no entry, which is effectively the same as not being logged in. So...

  • Can I just log out by wiping cookies instead of hitting logout?
  • What are the issues of just wiping cookies versus clicking the logout button?
Joseph
  • 741
  • 1
  • 5
  • 8
  • 8
    Auth tokens may also be kept in sessionStorage or localStorage. I assume you intend to delete that as well? – meriton Jun 01 '19 at 21:26
  • 3
    @meriton Yes, erasing the token from the client wherever it's stored, without using a site's logout button. – Joseph Jun 01 '19 at 22:13
  • 2
    Why not do both? For the reasons listed in @Ghedipunk’s answer, you could invalidate the session on the server side by logging out and then clear your cookies for good measure. – dalearn Jun 02 '19 at 11:20
  • There's nothing that "guarantees" you that a given web application will behave sanely when you delete your cookies/storage. Maybe a bunch of vital logic is executed when you use the logout feature. That would be a really shitty web app, and they should have really seen such an obvious use-case coming. – Alexander Jun 03 '19 at 15:27

5 Answers5

82

Can I just log out by wiping cookies instead of hitting logout?

Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are.

What are the issues of just wiping cookies versus clicking the logout button?

Web applications that manage authentication following the OWASP session management guidelines will invalidate the session on the server side when you log out explicitly. If you simply discard the cookie with the session token, the session may be subject to session hijacking.

Using door locks as an analogy for those who are not familiar with best practices of developing web applications (thanks to discussion in the comments):

Your account can be seen as a room in a building. When you log in, the building's owner creates a door and puts an automatic lock on it, so that only you can enter. Your session token is your key, and is typically stored in your browser's cookies, but can be stored in other places.

Discarding your token by deleting your cookies, clearing cache, etc., is simply destroying your copy of the key.

Explicitly logging off is asking the building owner to brick up the doorway. There's nothing guaranteeing that they'll secure your account, but as the user, you're explicitly making your wishes known.

There are various ways that an attacker can get a copy of your key, known as session hijacking, that are the responsibility of the site owner to mitigate, not the users.

First, the attacker can just guess. If the site generates session keys sequentially, or uses a low entropy pseudorandom generation method, this makes guessing much easier. Sites mitigate this through using high entropy tokens and periodic session recycling. Recycling sessions doesn't prevent access, but it makes it obvious when unauthorized access has been granted.

Second, the attacker can use session fixation: They give you a key before you log in, which you continue to use after you've logged in. Sites mitigate this by explicitly recycling the session when you log in.

Third, a Man-in-the-Middle attack. The attacker can see your key directly. TLS mitigates this. It is possible to decrypt TLS traffic through downgrade attacks, insecure implementations, and zero-day attacks, but these are far outside a user's domain, rare, and zero-day attacks against TLS tend to raise a LOT of noise when they're discovered (Heartbleed, et al).

As a user, your responsibilities are to log off and to hold the site accountable when they take shortcuts with security, much as your responsibility with your car in a public parking lot is to lock your doors. If the door locks are trivially bypassed, then its the manufacturer's fault, not yours.

Ghedipunk
  • 5,935
  • 2
  • 23
  • 34
  • 19
    Answer is true, but there are some session management systems that do not store session state server-side, instead saving it in a cookie in a cryptographically-safe way. So even logging out on the server does not render the cookie useless. – multithr3at3d Jun 01 '19 at 15:24
  • And sometimes logging out does not invalidate a token. Some servers retain the token after logout in case multiple devices owned by the user are using/sharing the same token. I seem to recall one of the OpenStack web components did that (I think it was Laravel, but maybe it was another front-end). The recommendation was something like, don't use OpenStack from an internet cafe or other place that offers public access... –  Jun 02 '19 at 02:16
  • There's also browser identification, such as used by LastPass and many banks, which will have to be repeated every time if cookies are cleared. – chrylis -cautiouslyoptimistic- Jun 02 '19 at 03:28
  • I strongly dissagree, a modern web-app may use localStorage or other non-cookie means to store session keys. It's not common, but not unheard of either. – Tomáš Zato Jun 03 '19 at 09:07
  • One reason is listed by Ghedipunk (token still being valid server side). Another thing is that some systems may store token into local storage instead of cookies. e.g. you can see this in OpenShift console. Then clearing cookie will not remove token from your computer. – akostadinov Jun 02 '19 at 05:32
  • 1
    @TomášZato, I am answering for a _typical_ web application, since that was in the question. I think additional answers with other, non typical session management will be useful, if you're willing to write one. – Ghedipunk Jun 03 '19 at 16:13
  • Security advice that is only applicable in *typical* scenarios is not a good security advice. You should still lock your car even though *typically*, nobody even tries if the door is open. – Tomáš Zato Jun 05 '19 at 07:45
  • @TomášZato, I'd argue that, using a door lock analogy, typically there isn't be a threat of an attacker being able to guess, coerce, or intercept a session token. As a user, you should still "lock the door" by logging out and invalidating the session. Or, to extend the analogy, logging out is bricking up the doorway, and deleting your local copy of the session token is just destroying your key; it can still be picked or the key may have been copied. I still think if you write another answer going over ways that sessions are identified other than cookies, it may be valuable. – Ghedipunk Jun 05 '19 at 15:39
  • So, Logging in inside incognito mode and just closing the window is not a good idea – Abhishek Choudhary Apr 15 '20 at 02:53
11

Some websites make use of non cookie based methods of storing data on a users computer, such as HTML5 local storage and flash player cache that may contain sensitive information.

For example your email client may store your draft email in local storage so that in the event you accidentally refresh the page/close the browser you will be able to resume where you left off. This sensitive data will normally be removed when you click the logout button on a well designed website and would not be removed by merely deleting your cookies.

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
Mohammad Ali
  • 271
  • 3
  • 11
  • 3
    Only insecure poorly designed applications store sensitive information on the client. That's why your comment is not correct. – mentallurg Jun 02 '19 at 22:16
  • 7
    @mentallurg On the other hand, there are really too many of those. – michaelb958--GoFundMonica Jun 03 '19 at 00:56
  • @michaelb958: You don't understand the problem. If application stores sensitive data on client side, this is a problem independent on logging out, because for instance connection can be broken and such data will not be deleted any way. So logging out does not make it essentially better. That's why please don't tell that logging out is better than deleting cookies. – mentallurg Jun 03 '19 at 01:51
  • 1
    @mentallurg if the connection is “broken” the average user will not be able to log out and will not be able to delete their session cookie(s). So they will be logged in when the computer is reconnected to the internet. – Mohammad Ali Jun 03 '19 at 01:53
  • @mentallurg I completely understand the problem. The comment was a reflection on the number of apps out there seemingly written by developers who don't. (Number: more than 0. Desired number: 0.) – michaelb958--GoFundMonica Jun 03 '19 at 01:54
  • @Mohammad Ali: Hmmm you too don't understand the problem. When connection is restored after a long time, cookies are expired and server does not detect any session and considers the user as not logged it and does not suggest to log out. So user cannot log out even if he wants to do it. So the sensitive data remain on the client. Means, saying that logging out is more secure than deleting cookies is wrong. – mentallurg Jun 03 '19 at 01:56
  • @mentallurg I understand the problem, I am just pointing out that many website do in fact do this. Also if the session cookie doesn’t expire(which is something many sites do), then what I said does hold true. – Mohammad Ali Jun 03 '19 at 02:15
  • @Mohammad Ali: In some cases there can be one behavior, in other cases other. But this is not how security problems are discussed. Even if there is a single case when your approach doesn't work, your solution is wrong. Now look at the OP. What should be the answer? The answer should be following: No, deleting cookies has THE SAME risks as logging out. – mentallurg Jun 03 '19 at 02:26
  • 3
    @mentallurg "Even if there is a single case when your approach doesn't work, your solution is wrong." I don't see why you think this is this case. Mohammad Ali is simply stating that logging out explicitly is *better* because it works more often than the proposed alternative, not that it works every time. If you need an approach to work for "every single use case" else it's flawed, then you might as well suggest that OP doesn't even bother logging out since there is always a non-zero chance the logout functionality doesn't work. – DasBeasto Jun 03 '19 at 17:18
3

Can I just log out by wiping cookies instead of hitting logout?

Yes, since the web application uses cookies to uniquely identify you,deleting cookies will log you out.

What are the issues of just wiping cookies versus clicking the logout button?

The logout button serves a special purpose in that it sends a request to delete the session and returns a response to delete the cookie in your browser as well. If you don't send a request to delete the session then the session still remains alive server side. Sessions do have a maximum lifetime and will be deleted by the garbage collector eventually.

yeah_well
  • 3,744
  • 1
  • 14
  • 31
  • 10
    As explained by Ghedipunk above, explicit logouts are used to prevent session/cookie hijacking. Especially on shared computers, there may be software to record all cookies made, so that even when people clear cookies (or close an incognito window) those cookies are maliciously kept. Explicitly logging out invalidates these cookies, so even if they were recorded, they can not be replayed to the server for authentication. – QuickishFM Jun 01 '19 at 16:59
  • 1
    *"Since the web application uses cookies to uniquely identify you,deleting cookies will log you out."* - I don't believe this is correct. Deleting a cookies is a client side action. The server knows nothing about a client removing a file. You have to explicitly tell the server to log you out. –  Jun 02 '19 at 02:19
  • @jww which is what i wrote here "The logout button severs a special purpose that it sends a request to delete the session and returns a response to delete the cookie in your browser as well" – yeah_well Jun 02 '19 at 05:45
0

There are no risks.

Someone has pointed out that it might increase the risk of session hijacking. But that is not true. If the application has session (is stateful), this session has a timeout. And after session expires there is nothing to hijack. If session is active, then the chances to hijack a session of an active user are are almost the same as for a "orphaned" session. Taking into account tools that quickly detect multiple request with invalid session IDs of somebody who tries to brute force session ID, there is no additional risk on the server side.

On the client side there can be more risk in case of log out than in case of deleting cookies. Log out invalidates session, but can keep some other sensitive data. For instance, when you log out from Google Mail, your user name is still kept in cookies; and when you go to Google Mail, you will see your user name prefilled. First, may be you don't want anybody behind your shoulder to see this user ID. Second, if in hurry, you may log in into a wrong account (of your multiple accounts). Similar problems may happen in other applications. Where as when you delete cookies your are sure there is nothing kept in your browser what you are not aware of; you will not be surprised by any data stored in cookies. So actually in case of log out the risk of negative surprises is higher than in case of deleting cookies. I have to say that when one deletes cookies one should also consider deleting local storage.

A single disadvantage that I see in case of deleting cookies is that server will use slightly more resources to keep session data until session is time out. But the question in OP is about risks for the client. So there are no risks. And now days the most applications have no state on the server; logging out means in such case just invalidating the token; there are often no resources blocked by session. So even "orphaned" session doesn't take any additional resources.

One more aspect to consider: Depending on application and on internet connection, logging out may take considerable time, a couple of seconds. Where as deleting cookies (and local storage) happens immediately and does not depend on server and on internet connection.

May be somebody will find other important points that I overlooked and will criticize my point of view. That's fine. I just wanted to encourage users not to follow any rules blindly, but to think about what is happening actually.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • 1
    I'd absolutely agree that the risks are _very_ minimal, but not that there are no risks. By default, PHP stores session data in the server's /tmp directory without any explicit expiration system other than the regular culling of files that had not been recently accessed. I've seen the cron job configured to be nightly, weekly, monthly, and even disabled. -- Just a minor nitpick, though. I find security -- and paranoia in general -- easier to deal with if I question any absolute statement. – Ghedipunk Jun 04 '19 at 17:24
-5

There is also the risk that you forget the password, although this is more likely to be an issue for someone who only rarely needs it not every session they go to a particular site.

Soronel Haetir
  • 1
  • 9
    I would consider not being able to access the site when the user has forgotten the password (even if this is the user) a security feature .. – DreamConspiracy Jun 02 '19 at 01:59