0

I have a login page and for the password, the unique option it is to use an entry with the parameter IsPassword as true. But it is still a string, so in my view model I can't use SecureString for the binding, I have to use a string, that is a plain text.

My idea it is to store the credentials in SecureStorage to avoid to enter the credentials every time, as work many others applications in which is it not needed to log every time the application is opened. But I don't know if this is good option.

Is this, the use of string the unique solution or are there better options?

Thanks.

Álvaro García
  • 18,114
  • 30
  • 102
  • 193
  • It is not a good option. You should be storing the token, after the login is done. If you want to store something, at least store the HASH of the password. – H.A.H. Mar 02 '23 at 17:35
  • But if I store the hash, it only would be useful to compare if the password that user write is correct or not, comparing the hashed password from user with the stored hased. But it doesn't avoid to the user to have to write the password everytime the application is open. It is what I would like to avoid. – Álvaro García Mar 02 '23 at 18:21
  • You do not transfer the password as plain text. You do not store the password as plain text. You do not compare the password to plain text. This is a rule, so basic, that should never be broken, regardless what is the situation. If you have been sending plain text passwords, and saved them in your DB like that, you have messed up already beyond repair. And how you store it in the device is the least of your problems. I will say it again, the user writes the password > you hash it immediately > send it over encrypted channgel > server gives access token > you store the token. – H.A.H. Mar 02 '23 at 18:34
  • Yes, in the database it is needed to store the hashed password, not the plain password. But if i am not wrong, the user has to send the password to the server through a secure channel, then the server hash the password and compare the result with the hashed password in the database. If the user send the hashed password and the server only compares the hashed received from the client and compare it with the hashed password in the database, in practice is the same than store the password in plain text. – Álvaro García Mar 02 '23 at 18:39
  • The server hashes it too. This is 100% required. But I do hash it on the device as well. (I have never trusted the clients to provide secure channels, and I have to protect their users) If you can afford the certificate, you can skip the first hash. However, from 10 years of practice, I can assure you, you are never too safe and too prepared. And what do you waste? 1ms CPU time on the user phone? – H.A.H. Mar 02 '23 at 18:46
  • But do you mean you send the has to the server or send the password to server? Because if the server hash the has that receives from the client, it will not be the same than the stored hased. Sorry if it is a basic question, but I am starting to think about this and I have some doubts. – Álvaro García Mar 02 '23 at 18:52
  • 1
    If you have already stored some passwords (hashed only by the server) then your only option is to keep sending plain passwords, over secured channel. You should however focus on avoiding doing this very often. You need to generate tokens, and store those tokens on the client side. (Read a bit about what is refresh token too). When both tokens expire, the user has to re-login by hand. – H.A.H. Mar 02 '23 at 19:04
  • 1
    *"If the user send the hashed password and the server only compares the hashed received from the client and compare it with the hashed password in the database, in practice is the same than store the password in plain text."* The point of working with hashes is that plaintext is never stored anywhere. Given a secure channel, that is one level of protection. "Refresh token" gives a second level of security. If the token is somehow extracted, but sent from a different device, it is rejected. If one end of the channel might be compromised, two-factor authentication is next line of defense. – ToolmakerSteve Mar 02 '23 at 21:25
  • 1
    If great caution is needed, consider a `pin` approach, like Microsoft Windows hello. Send hash or refresh token, but require user to enter a short pin also. Three pin failures in a row, require whole password to be reentered. This prevents brute force pin breaking. Assuming pin is only valid for that user on that device. – ToolmakerSteve Mar 02 '23 at 21:30

0 Answers0