1

I have a website which clients can log in to. Their username, encrypted password and some additional info is stored in an SQL database on the server. I am setting up a cookie to remenber the user for some days.

I read everywhere I should not save the username and password in the cookie for security reasons. I have to say I am not sure to see why. The cookie is stored on client side right? Thus it is his username and password he is able to see, what is unsafe in that?

Anyway I pretty sure there are good reasons and it is just I cannot see it, I read the solution is to do that:

  1. hash and encrypt the password
  2. store the login information to a file on the server
  3. give the file a unique name
  4. store the name to a cookie
  5. each time you receive the cookie with the correct file name, look up the file and retrieve the login information.

So I should generate a unique ID to store in my database and associate it with the user.

How can I achieve that?

Matt
  • 72,564
  • 26
  • 147
  • 178
Laetis
  • 1,159
  • 3
  • 14
  • 25
  • store username in session. store session id in cookies. – Peter Apr 24 '15 at 09:25
  • You can md5 current timestamp to get the uniq id. – jcubic Apr 24 '15 at 09:25
  • Cookies can be stolen and/or hijacked. If you only store a session in your cookie, only that's what can possibly be retrieved. Otherwise the attacker could get all of the user's information right from a single cookie. – Etheryte Apr 24 '15 at 09:28
  • You might want to look at this SO answer which covers many aspects of authentication: http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication#477578 – gyo Apr 24 '15 at 09:34
  • @Nit so in addition you can keep IP and browser name and compare it – Peter Apr 24 '15 at 09:35
  • @Peter Neither of those are a good metric as they can change when you'd still expect a cookie to work: 1) taking your laptop to a different network, your IP changes but you still expect to have a working cookie; 2) updating your browser, your useragent string changes but you still expect everything to work as before. – Etheryte Apr 24 '15 at 09:36
  • @Nit yes this happens, you need to relogin. there is no other way – Peter Apr 24 '15 at 09:40
  • @Peter This is obviously not the case when you use cookies properly? See any website, even this one you're on right now. – Etheryte Apr 24 '15 at 09:42
  • @Nit Google uses this. I am 100% sure you need to retype your password if your IP is changed. There are lot of other websites which do that. There is no other option to prevent session hijacking. – Peter Apr 24 '15 at 09:43

3 Answers3

3

You don't need to store the username and the password. You could instead store a session key (saved in database) with an expiration date.

If you store username and password locally that is not a huge problem if the user is at home, but what if the user is not at home ? What if the user is not on his own computer ?

Even encrypted, some "bad guys" could get it.

alexf
  • 1,283
  • 9
  • 20
antoinestv
  • 3,196
  • 1
  • 22
  • 39
  • "but what if the user is not at home ? What if the user is not on his own computer ?": I see the problem. I think that won't be the case for my web app (which user will prbably use at work) but in general I agree and prefer do thinks proprely. I like the session key idea. Thanks. – Laetis Apr 24 '15 at 10:04
  • You could use the session key, but unless the remember-me token serves EXACTLY the same function as the session identifier then confusing the 2 will cause problems with authentication management, and any non-identity related information maintained in the session such as stock control. It will still have an impact on system capacity even if it is exactly the same thing. – symcbean Apr 24 '15 at 14:08
1

The problem is that the user can change the cookie value. So he can set the username to someone else's name.

Instead of putting the username in the cookie, put the unique filename in the cookie. This is essentially how PHP sessions work -- they put all the session data in a file, and set a PHPSESSID cookie with the name of the file.

Barmar
  • 669,327
  • 51
  • 454
  • 560
1

should not save the username and password in the cookie...not sure to see why

Because the user may not be in exclusive control of the client - e.g. a public access terminal, or even with a personal computer, this extends the attack surface for malware. The longer lifetime of the entity compared with a session identifier increases the attack surface too.

And if it's not properly encrypted and re-validated then the user can easily change the data to that of someone else.

As to the remainder....

give the file a unique name

File? What file? You are trying to implement a surrogate authentication token. The specifics of how you do that depend on the programming language and the policy you want to implement. Should the system allow for the user to store tokens on multiple machines (which implies multiple concurrent values)? Should it be strongly tied to the machine it was initially assigned to (in which case how do you establish the identity? Using the IP address or user agent has limitations)?

Generally you should store the mapping between the token and the account (and additional meta data such as machine identity and expiry) on the server.

symcbean
  • 46,644
  • 6
  • 56
  • 89