2

I am doing my own login authentication system, and I want to do a robust system. I want to decide which direction I should take to keep the user logged in. I have put a question for each way, and also what I think the pros/cons are.

Cookie

  1. How safe is it to store a "User" object, with many properties (including encrypted pass) in a base64 string?

Disadvantage: Must be encrypted so the user can't easily manipulate data
Advantage: Can be set for longer periods of time, and can persist during sessions.

Session Variable

  1. How safe is to store sensitive plain text data?

Disadvantage: Only lasts for the server session.
Advantages: Cookie is automatically encrypted, and simpler to code than cookies.

What are other advantages and disadvantages?

  • 2
    Why are you doing your own login authn solution? Are you thinking that you can do better than existing systems? Do you just want to experiment? Will you be using your system in an actual app? – Neil Smithline Sep 17 '15 at 16:26
  • 1
    Because i want full control and customization in every step of the way. And yes, it is to be implemented. I just want to decide which way is better, that's why i am asking for opinions too. – Dillinger Sep 17 '15 at 16:40
  • 1
    You should not implement a custom authentication framework unless you have very strong business needs that prevent you from using the built-in .NET authentication system. New systems tend to have many flaws that have been shaken out by the tried-and-true systems. – Neil Smithline Sep 17 '15 at 16:42
  • 1
    Thanks for your input, but my question is about cookies vs session variables, not about what you think of custom implementations. Feel free to comment on the question subject. Thanks. – Dillinger Sep 17 '15 at 16:47
  • Cookies are stored/Sent to the user.. Nuff said imho. And really, listen to the other guys here. Implementing security yourself is like drawing a car with chalk and claiming it can transport you to the moon. – Pinoniq Sep 21 '15 at 19:08
2

1) how safe is to store an "User" object, with many properties (including encrypted pass) in a base64 string?

You should never store the password anywhere. It does not matter if it is encrypted or not. You should not even store an encrypted copy on the server side. You should use something like bcrypt to create a secure hash of the password that you use for validation.

2) how safe is to store sensitive plain text data?

A better question would be "how unsafe is it to store sensitive plain text data?" The answer is that it is very unsafe. Of greater concern than the encryption portion is that the question makes me think that you are planning on trusting spoofable data that comes from the client. You must never do this.

If you are to store information used for authentication on the client, it must be done in a secure manner. You sign (eg: with an HMAC) to make sure it isn't tampered with. You encrypt data to keep it secure. And you never store anything but a password hash (eg: with bcrypt) as they are so sensitive that even encryption isn't sufficient for them.

Finally, I strongly recommend that you don't actually use a custom authentication system for anything but playing around. Even the most experienced security developers' authentication systems take lots of help and testing and real life usage before they can be considered secure.

2

Cookie: Several issues here to consider:

  • The larger the cookie contents, the slower the site responsiveness from the user's perspective
  • The storage is unsafe. It is outside your control. Numerous attacks are available based on taking someone's cookies.
  • You are handing the encrypted password over to a potential attacker.
  • Given this scenario you cannot trust the data coming back to you from that cookie. It's been in the wild. You have provided no way of knowing if it has been altered, stolen, or extended. It's a great way for an attacker to escalate privileges, for example.

Session variable:

  • It is not safe to store plain text data. On a shared server, the session data are available to all processes.
  • It's easy to assume that something stored on the server is safe, but there are too many examples showing that is a bad assumption.

Are there any other advantages or disadvantages?

Yes, there are a LOT of vulnerabilities embodied in your suggested approach. This is not criticism. Do consider not re-inventing the wheel here. In the security arena, use a trusted system. I've learned this the hard way!

  • 1
    I understand you point of view, but i asked those questions to get more on the cookie/session variable information, that's why i used those extreme examples, and of course it isn't my approach (i.e: unencrypted sensitive data). – Dillinger Sep 20 '15 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.