TransWikia.com

Is it OK to store the user's plain-text password in a claim?

Information Security Asked on December 10, 2021

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.

One Answer

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!

Answered by LvB on December 10, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP