2

I'm a little confused about Charles Miller's article, "Persistent Login Cookie Best Practice" because I can't understand how the code prevents someone stealing the cookie and login in a different computer.

I have seen and read the following topics:

  1. https://stackoverflow.com/a/244907/3355243
  2. https://stackoverflow.com/a/30135526/3355243
  3. https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

In all of them it explains how to implement a more secure login system, although I can't figure out how it prevents from stealing a cookie, copy paste into the console and login with it, even if dealing with two different fields (series/selector and token).

document.cookie="theCookieNameFromWebsite=theCookieValueFromVictim";

The paragonie.com link says:

CREATE TABLE `auth_tokens` (
    `id` integer(11) not null UNSIGNED AUTO_INCREMENT,
    `selector` char(12),
    `token` char(64),
    `userid` integer(11) not null UNSIGNED,
    `expires` datetime,
    PRIMARY KEY (`id`)
);

The automatic login algorithm looks something like:

  1. Separate selector from token.
  2. Grab the row in auth_tokens for the given selector
  3. Hash the token provided by the user's cookie with SHA-256
  4. Compare the SHA-256 hash we generated with the hash stored in the database, using hash_equals()
  5. If step 4 passes, associate the current session with the appropriate user ID

How d'hell this prevent me from stealing the cookie and use it to log me in the account of my victim?

Community
  • 1
  • 1
Linesofcode
  • 5,327
  • 13
  • 62
  • 116
  • 1
    It doesn’t. At the bottom of the article it explicitly states what the two additional advantages of this approach are. – CBroe Sep 19 '15 at 11:05
  • http://jaspan.com/improved_persistent_login_cookie_best_practice link is broken – nafg Aug 13 '19 at 00:17

1 Answers1

1

It does not prevent anything. Only encrypting the HTTP messages with TLS (commonly known as HTTPS) will ensure that no one steals your users' cookies (please note that HTTPS must be applied across the entire domain, not just login pages and "secret" areas.

As for what this method does, quoting the article:

  • An attacker is only able to use a stolen cookie until the victim next accesses the web site instead of for the full lifetime of the remembered session.
  • When the victim next accesses the web site, he will be informed that the theft occurred.

The advantages here are that the user will be notified of the theft as soon as possible, rather than silently dismissing the other session, or worse, treating the user as the attacker.

Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
  • I understand your point of view, but then why would I need two fields? A simple field saving the session_id or a token would do the same job. The only (improvement)difference I see with this approach is if the thief has access to the database. Quoting: With this failsafe in place, if somehow the auth_tokens table is leaked, immediate widespread user impersonation is prevented. – Linesofcode Sep 19 '15 at 13:08
  • If you only ever keep the session ID, and use that as identification, you have no way of knowing who the imposter is, when two present you with the same session ID cookie, or even if there is an imposter. – Madara's Ghost Sep 19 '15 at 13:10