0

Imagine the following scenarion.

  1. User is authenticated and get an authentication cookie. Which means one shouldn't enter username and password once again. I store only username in authentication cookie.

  2. A hacker steals user's authentication cookie somehow. Admin decides to change a password for a user but a hacker is still authenticated and can access the system!

As far as I can understand authentication cookie can't be decrypted anywhere but serverside, isn't it?

Is it safe to store a password or a password hash as a custom claim in authentication cookie so I can compare it later and remove authentication from discriminated users? What's a best practice for it? Or am I doing or asking something completely wrong?

norekhov
  • 3,915
  • 25
  • 45
  • You can implement refresh tokens to add expiration to tokens. Even if a hacker gets it which you wouldn't know when then it will still expire. – jegtugado Apr 04 '16 at 13:27
  • Yes, that's a nice idea and I missed it but a bit complex since I need to store extra data while I already have a password which I can change. If a hacker ( theoretically ) can't decrypt a cookie than I can store a password there, why not? Or can he? – norekhov Apr 04 '16 at 13:36
  • You can never assume that a hacker cannot decrypt your data. `Refresh Token` exists for this sole purpose, so that user cannot abuse the access token for a long time. – Vishnu Prasad V Apr 04 '16 at 13:38
  • How about this, let's say you implemented refresh tokens and your user logged in. He now gets a token for authentication. Somehow a hacker got hold of that token. User quickly changes password so if the change password is successful you can force expire the previous token and grant the user a new one. Hacker now has an obsolete token. – jegtugado Apr 04 '16 at 13:42
  • The hacker wouldn't care less on decrypting the token. He would just use it for authorization by adding it to the request header as is. – jegtugado Apr 04 '16 at 13:44
  • 1
    @norekhov It is never been a good idea to implement security ourselves. ASP.Net Identity team thinks through all the scenarios you stated. Please look at **ASP.Net Identity** so that you can get ideas even if you do not plan to use it. – Win Apr 04 '16 at 13:58

1 Answers1

1

As far as I can understand authentication cookie can't be decrypted anywhere but serverside, isn't it?

Authentication Cookie is encrypted using Machine Key. It is hard to decrypt back without machine key, but it is not impossible.

Is it safe to store a password or a password hash as a custom claim in authentication cookie so I can compare it later and remove authentication from discriminated users? What's a best practice for it? Or am I doing or asking something completely wrong?

No, you do not want to store password inside claim. It won't solve the hacking problem, or even make it worst.

You can implement security stamp like ASP.Net Identity which basically logout user from everywhere.

Community
  • 1
  • 1
Win
  • 61,100
  • 13
  • 102
  • 181
  • Ok now I see. I used "Authentification" lib. What I missed is "Identity" lib. In my case I think it's easier to implement it manually than to use Identity lib. Thanks! – norekhov Apr 04 '16 at 19:08