1

For customer reasons, my web app authenticates the user against a proprietary user database using a simple API like bool authenticate(string username, string password)

In case the user changes his password or his account is closed etc., I will need to periodically (say every half hour) re-authenticate against the user database, but I obviously don't want to ask the user for his password every half hour.

I'm using ASP.NET core cookie authentication. Is it reasonably secure to store the plain-text password in a claim so that I can get it back when I want to re-authenticate? Of course the claims are signed and encrypted by asp.net and only ever transmitted over a secure channel.

It seems to me that compared to the risk of an attacker intercepting the original login request or interfering with the user's password manager, the additional risk associated with this approach is minimal.

The other approach I considered would be to generate a session Id to use in the claim and then store the mapping of session Id to plain-text password on the server. This would be even worse IMO.

Improve this question

1 Answer 1

Reset to default
2

it is NEVER ok to store a plain text password that is not yours. EVER!

the way to go about this is to validate the access you have and if the access check fails. ask the user for there changed password (e.a. re login)

you must assume that all data in any token transmitted between your server and a client is 'public'. use proper once tokens and try to go for a token authentication based approach (auth 2 / saml / etc).

basically treat the passwords of your users as secrets, you only store the salted hashed version. never the original!

Improve this answer
2
  • I'm not sure what you mean. The only access I have is an API that validates the user's password. Also the statement about assuming data transmitted between the server and the client being public doesn't make sense because in any pasword login scenario, the user is typing their password into a text box and it's being sent to the server.
    – Andy
    Jun 24, 2020 at 7:40
  • The initial password normally is send from client to server over a tls encrypted line. And is transformed into a hash asap. (And if someone was able to read the traffic indeed a risk). The goal is to minimise this vector. If the api does not allow for a sensible way to keep the session active (session refresh or session extension comes to mind). Than you could be forced to have your user relog every x hours. Or use a battle tested secret store, if you really think you must store those passwords yourself. (Hashicorp’s vault comes to mind).
    – LvB
    Jun 24, 2020 at 7:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .