Summary

The article discusses the security risks associated with Symfony's "RememberMe" feature and provides recommendations for enhancing user safety.

Abstract

The Symfony Security feature "RememberMe" allows users to stay logged in to an application for an extended period through a long-lived "REMEMBERME" cookie. While convenient, this poses a significant security risk as the cookie can be stolen through various means, including malicious browser add-ons, compromised operating systems, and the dark web trade of stolen browser data. The article emphasizes the importance of rotating cookies and JSON web tokens frequently, invalidating tokens when passwords are changed, protecting sensitive account areas with stricter authentication roles, and implementing custom token providers for better control over token management to mitigate the risk of identity theft.

Opinions

The author suggests that the "REMEMBERME" cookie's one-year expiration is a potential security vulnerability.
There is a concern that attackers can easily acquire stolen browser data, including cookies, to bypass two-factor authentication (2FA).
The article implies that many service providers may not have adequate measures to detect fraudulent activity resulting from stolen cookies.
The author recommends frequent rotation of cookies and tokens to minimize the window of opportunity for attackers.
Implementing a custom token provider is advised for more granular control over token invalidation, aligning with the principle of least privilege.
The author has personally verified the availability of stolen browser data on the dark web, reinforcing the urgency of addressing these security issues.

Using Symfony’s “RememberMe”? You Better Read This

Keep your users safe and your system secure

Photo by Flex Point Security Inc. on Unsplash

Are you using the well-known Symfony Security feature called “Remember me” ? When a user authenticates to your application, he can select the “remember me” checkbox to become logged in for longer.

This feature is powerful yet dead simple. During the log-in process, the user receives an additional cookie called “REMEMBERME” with an expiration date of one year.

If the session cookie is missing and the remember cookie exists and the user didn’t change his password, the user gets authenticated automatically.

Can you spot the danger associated with this feature? Think about it for a moment.

Digital identity theft

The problem is with the cookie’s longevity. This cookie is the golden key to getting inside your application. Let’s talk for a moment about digital identity theft.

Are you aware that somebody can steal your browser cookies? This can be done in several ways, including:

malicious browser add-ons,
compromised browser add-ons,
data loss due to a compromised operating system.

The last point may be especially severe. If an attacker acquires access to your user directory, he immediately gains access to all of your browser data, including cookies. He can then use those cookies to authenticate to the services you use.

Many large service providers incorporate additional measures to detect such fraudulent activity. Do you? It’s not easy.

Personal identity black market

Did you know you can buy gigabytes of stolen browser data; with cookies?

This way, today, attackers bypass 2FA authentication on some websites. It is an increasing problem and has been described recently by Julien Maury on esecurityplanet.com:

“Cybercriminals collect cookies or buy stolen credentials “in bulk” on dark web forums. Ransomware groups also harvest cookies”

To verify this information, I installed Tails OS inside a virtual machine and went sniffing on the dark side of the web.

True enough, after about ten minutes of searching, I found this little bargain, among others:

Protecting Symfony users from identity theft

Rotate cookies and JSON web tokens frequently to ensure user safety. The longer its Time-to-live value, the more time for attackers to re-use stolen credentials.

The “remember me” cookie includes an encoded user password. If the password is changed, the cookie will be invalidated during log-in (this the default behavior that can be configured differently.)

Use the IS_AUTHENTICATED_FULLY role to protect the most risky parts of the application, i.e. the password change form, account personal details form. Leave the IS_AUTHENTICATED_REMEMBERED for the rest.

Introduce a custom token provider to have complete control over circulating tokens. This way, if necessary, you will be able to invalidate tokens en masse or per user; or using any other logic of your choice.