CODEWITHSUNDEEP
securitycookiessession-cookies
Josh Smeaton
Josh Smeaton

Reputation: 48720

Whether or not to use persistent cookies

We've just had a security auditor flag our use of persistent cookies to maintain login state in our web application. As a bit of background, our web application is multi-tenanted, but no (or not many) operations are destructive. There may be - depending on the tenant - sensitive information available through our portal.

Back when we designed our application, we discussed the use of persistent cookies, and decided that we should based on usability. We didn't, and still don't to a degree, deem the information available as sensitive. Our users are fairly novice and we were more concerned with having hundreds of reset password requests.

Is the use of persistent cookies for logging in deemed a security risk? Is the trade off in usability even a discussion when we're talking about operational data of some fairly big businesses?

We haven't had any questions regarding persistent cookies before - not from any of our clients. Would it be worth implementing a 'tick to persist' that defaults to off to satisfy both sides?

Upvotes: 3

Views: 5570

Answers (2)

damiankolasa
damiankolasa

Reputation: 1500

Persistent cookies, are used for a variety of reasons, and to support numerous functionalities. If your app has absolutely nothing "sensitive" then, you can use persistent cookies for permanent authentication, and then issue re-authentication to access user account details, or do some changes (i.e. change password, or e-mail address). You mentioned that your users, are novice, so I don't think that they know that if someone else uses their browser they will also be authenticated without knowing his or her password (I would point it out to users).

But there is a reason why security critical apps like online banking, do not issue a persistent login cookies, although they could, because before making any changes to your account balance you have to re-authenticate out of band (via mobile, or some form of OTP). But it's considered insecure, and maybe it is because knowing someone's balance is already invading their privacy.

So if your app is not controlled by any government authority, and you're not bound by any law in your country, and you implement re-auth on sensitive parts of your app, then issuing 2-3 week persistent cookie for authentication, is not a significant security threat.

Upvotes: 3

Alexander M
Alexander M

Reputation: 1

If persistent cookies are not to be trusted, Fatfredyy's suggestion sounds great.

However, if the problem is unsecure use of persistent cookies, why not encrypt them?

Upon either ticking "Remember me" or by default a cookie is generated including some unintelligible unique ID for the user and an encrypted part containing verification. The key to the symmetric encryption is stored in the DB with the user ID and never shared with the user. When the user revisits, you use the ID to access the key and decrypt the rest, verifying that no tampering has been done.

When an attempt to fiddle with the userid has been identified, display a message to the user and change the encryption key, requiring the user to re-authenticate.

This would enable you to use persistent cookies while not compromising the users.

Upvotes: 0

Related Questions