0

I am storing some basic information to use in order to display information per user. I am currently using cookies to store and retrieve them, however I would like to employ a more secure tactic. I read that using local storage would be more secure and better to use, however, they don't seem to have any expiration date (like cookies) and unless you use a session storage, they will be stored indefinitely, which I don't want. However I don't mind using local storage if the information is encrypted, however with current encryption libraries, I have no idea how to use them.

Storing:

  • username
  • login attempts
  • whether the user is locked out or not

Some things to note: what I am storing is not being used for authentication, only to display error messages. I am using tomcat 8 to handle authentication and running the server (along with lockouts). Even though its not being used for authentication, I don't want to store the username unsecured or without expiration (1-2 days max).

Also, I'm not using an sql database (or other type) but plan to implement later, so don't suggest or ask about it.

I'm looking for the most secure method possible with relative ease, we have other security measures implemented, but don't want to leave any security holes open.

Lloyd Smith
  • 77
  • 3
  • 16

1 Answers1

0

There is no such thing as secure that is purely client-side with two-way encryption. If you are able to decrypt something on the client-side, so can others.

Also, there are no particular security differences between session storage, local storage, and cookies. They're all client-side and able to be read by JavaScript on the same domain.

If you really want things to be secure, you have to store in on the server side, and transfer it only over HTTPS. Anything else is merely security through obfuscation, at best, which isn't real security.

As far as expiration, there is no automatic expiration with either local storage or session storage (other than the session storage will be cleared when the session ends). You could implement some with JavaScript, but that would only involve throwing away values when they are too old, and wouldn't happen until they visited your page.

The best you could do that is almost pure client-side would be to store some kind of key on the server, and when you go to decrypt, it needs to request the key (over HTTPS) from your server and use that to decrypt. That way, they can't decrypt it without having some kind of proper authentication onto your server.

However, if you're doing that, you might as well just store the info on the server in the first place.

samanime
  • 25,408
  • 15
  • 90
  • 139
  • Ok, so what ways would I be able to either 1. store the information on the server (everything seems to store it client side) or 2. use a key to decrypt it? also I forgot to mention I'm using HttpOnly and Secure tag for the cookies atm. – Lloyd Smith Jun 22 '17 at 18:14
  • You can store it on the server in a number of ways. Databases or application sessions are both common. It depends on your server-side application and framework, but there are numerous ways. Typically you'd store a session ID in a cookie on the client side. Then when they request info, that session ID is sent to the server, the server uses it to look up their creds and status, then handles the request as normal. For a key, you'd do something very similar, and then provide that key to the encryption. I recommend against the key though... less secure and more work. – samanime Jun 22 '17 at 19:59
  • Ok, first you know this isn't for authentication as that's already handled through tomcat? and second, I'm already using a cookie and want something more secure. Also I can't use session IDs because they user hasn't been authenticated and all i get from session id is null. – Lloyd Smith Jun 22 '17 at 20:03
  • A user can have a session ID even if they aren't logged in. Session IDs and user info are usually related, but a session ID is a wholly independent concept. Cookies aren't meant to store secure information. A session ID isn't generally considered a sensitive bit of information, which is why it's put in the cookie and used to retrieve the sensitive information from the server. If a user has access to data, two-way encrypted or no, that data is by it's nature insecure. That's why secure client-side things use one-way encryption and information kept off-machine for real security. – samanime Jun 22 '17 at 20:15
  • Well I'm not trying to store sensitive information via cookies, only the username, login attempts, and lockout time in order to display error messages. We have an encrypted server that we are maximizing its security, however I'm working on the website part of it to ensure its as secure as possible. We'll have an SSL cert attached to it, and I've also disabled cross-site scripting. I just want to cover my bases and ensure there are no open security holes. I just need a more secure method on how to store basic information and some examples or something to go off of. – Lloyd Smith Jun 23 '17 at 13:25
  • If it's not sensitive information, there is no reason to try to encrypt it. Just store it as plain text. My point is that no matter how you try to secure it, it'll only be security theater, not real security, so don't waste time with it. Work with the areas that require real security, which it sounds like you're doing already. The info you just mentioned would all be perfectly fine to store server-side. Using HttpOnly and Secure is probably as far as you need to go. – samanime Jun 23 '17 at 13:47
  • Ok, so you're saying I don't need to do anything? or should/could I store it server side for a bit more security? and if so how would I do that? – Lloyd Smith Jun 23 '17 at 13:51
  • The values you have mentioned (username, login attempts, lockout) are perfectly fine to store client-side (as long as the lockout is only for display, not for actually controlling the lockout) unencrypted in cookies and I wouldn't do anything more with them then you have (httpOnly and secure, though you could drop httpOnly if you need to access them via JavaScript).. – samanime Jun 26 '17 at 10:55