Techies, I don’t think it’s legal to store the decrypted User Password, either on your Database server or in the User Browser.
So I believe there’s more to be rethought here, first let’s think about back-end
, you should encrypt the password using some irrevocable algorithm, for example PBKDF2 + SHA256
, Blowfish
or BCrypt
, you possibly should find implementations over the internet.
Then the User to authenticate would send the user and password, the server would encrypt the password and compare it with the encrypted password in the bank, if successful, the server would return an Access Token and not the password.
Follow an example of 128-byte Token generation:
var tamanho = 8;
var index = -16;
var token = new byte[16 * tamanho];
for (var indice = 0; indice < tamanho ; indice++) {
Guid.NewGuid().ToByteArray().CopyTo(token, index += 16);
}
Console.WriteLine("Exemplo: " + Convert.ToBase64String(token));
//Exemplo: bopofs47dU6dt98TR8NULgqDQ6gOwb5LlUyJV36HO83sOatKfGjpSLuS6y0jOMJUOEv9pM5Roky3I0rlxfjB3CSrCCqVkfRKjolgL5lIFD/Gy37tjU3uR74iCZSZceiwhhUnIM3Mr0qWUjwqAThB6jupiPLbkiJKmeL1lZtM7vo=
You could store this Token in your Database as well as additional information... Access Date, IP, Host Name, etc... as well as an Expiration Date (Absolute or Relative).
Now we have the dilemma of where to store this Token
, the problem of SessionStorage
is that he is unique by Tab
browser, so if the user opens a new tab, he will have to authenticate again. then his option here would be the LocalStorage
, IndexedDB
and/or Cookies
... to store a token, I see no problem in using either one of them... I would particularly use Indexeddb.
Customer would need only send this Access Token, from it you will be able to identify the user.
The question is, why is the password included in the returned object? This makes no sense and is totally insecure, very!
– Filipe Moraes
As a rule never store credentials (encrypted or not) in the client.
– OnoSendai