https://github.com/magesuite/persistent-login

This module allows customers to stay logged-in for a prolonged amount of time in order to always have a reference to previous orders and so have an easy re-order. The module extends the existing Magento 2 functionality of the persistent cart.

Installation

Admin settings

There are no admin settings for the module, the functionality is enabled by default when installed.

Backend

How detection of login status works in Magento 2

Information about login status, cart identifier, etc. is stored in session storage. Every visitor of the shop has its own unique session data (even when not logged in).

Sessions are stored in a Redis server that stores data in the RAM memory of its server. Because sessions are stored for every visitor, allocated memory can fill quite quickly.

To reduce the amount of data stored session data of a single user has an expiration date and after some time of inactivity, it can be removed from session storage to make place for sessions of other active visitors.

One possible solution to this problem would be to increase the amount of RAM memory to store sessions longer but this approach does not scale well.

It’s hard to predict how much RAM would be needed to store all sessions for extended periods of time like 1 year.

But the most important reason why such an approach shouldn’t be used is that increasing RAM memory is very expensive.

How persistent login works

When a customer successfully logs in while selecting the “Remember me” checkbox special unique token is generated.

This token is then:

• saved into the database along with information to which customer id it’s associated to

• saved into the cookie storage of the customer’s browser

When the customer enters the shop and session data is no longer stored in Redis, Magento will detect the cookie, check if the token stored in the cookie is in the database, and if so it will recreate the session data of a logged-in customer.

Such an approach makes login status permanent as long as the cookie exists in the customer’s browser.

Security

Security is the biggest con of such a solution.

When talking about security there are three possible vectors of attack.

1. generating all possible token values hoping that we find tokens that will allow automatic login

2. stealing database contents

3. stealing the cookie

Ad. 1

Tokens are 50 characters long and generating all possible variations would take a very long time. Also, there is no easy way of checking if a specific token actually works other than actually entering the shop.

As consequence, it makes the operation of generating and verifying if a token allows login very expensive time-wise. It will require around half a second to check just one token.

Ad. 2

Tokens in the database are hashed versions of what’s stored inside the cookie. Gaining access to the database does not expose tokens that could be put into cookie in order for the hacker to log into the customer’s account.

Ad. 3

As a preemptive measure, the cookie stored locally in the browser is marked as HTTP only (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies ).

It means it cannot be read using JavaScript rendering XSS attacks that would inject malicious JavaScript code to steal the cookies impossible.

It is however still possible to steal the cookie when having physical access to a visitor's computer.

Frontend

The persistent login script (persistent-login.js) checks if persistent_login_used cookie is present. If there is such a cookie the script then checks if the customer is already logged-in. If not it sends a post request to persistent_login/persistent/login Backend code performs login when a customer enters a fully cached page and Javascript detects that it is not logged in currently. If the customer logged in during the current request the page is reloaded.