Vulnerability of remember me functionality found in Laravel

Some time ago, a post was published with a detailed description of the vulnerability of the “remember me” functional in the Laravel framework. She allowed to impersonate any user by creating a fake login cookie. The developers then said that the hole was closed. But a more detailed look shows that only one head was cut off by the hydra. Even if you do not use this framework, it will still be useful for you to learn how not to implement such functionality on your site.



The main problem is that the Laravel token for authentication is simply an encrypted user id. Why is that bad? Firstly, if you steal or pick up the key used for encryption, you can log in with any user, without having to pick up his password. Of course, getting such a key is hard enough, but for example, the recently discovered OpenSSL Hartbleed vulnerability would allow it. But this is not the main problem.
')

What happens if someone steals your cookie?

In fact, your account is already stolen forever and you can not do anything with it. Since this is just your id, then such a cookie has no expiration date, you can access it even after a year, and even if you change your password. This opens another door for the invader: if he once picked up your password, logged in and then saved the cookie for himself, then changing the password will not help you again. Let's add here that intercepting your packets when you use open WIFI (for example at McDonalds) is very, very easy.

If not ID, then what?

There are many options for making remember_me safe, they all need some kind of unique random token, for example:

1) Create a label in which we save: user_id, token, expires_on, ip
2) When logging in with “remember me” enabled, we create a new random token, record the user's IP and also set the expiration date of the token.
3) When the user comes with a token, we check its validity on the plate
4) Log in user
5) Delete the old token
6) Create a new token as in point 2 and give it to the user

Since the token is completely random to pick it up is virtually impossible. To steal it is much more difficult, since it can only be used once. As an added bonus, we have a binding to the user's IP. Who is interested in detailed implementation I advise you to read the post on stackoverflow , which describes in detail the whole procedure of user authorization. I have brought a simplified example here in order to show in a contrast how primitive the Laravel approach is.

Moral: you can not trust the security of your application framework and hope that everything is handed over for you. By the way, the creator of the framework very badly accepted the criticism of his approach and demonstrated a complete lack of understanding of the approach with tokens .