I have a question about the login system.
I understand the security and usage of encoding passwords using hash functions instead of encryption.
I also understood that it is done several times by adding characters to it is done several times.(Salt and stretching)
So I have a question.
I'm thinking of using SHA256, but the act of hash cannot be undone.How do I migrate my system when I want to use a new type of hash?Or how did you migrate from SHA1 or something like that?
Of course, it's an SSL transmission, but when you send a password, you should encode it and send it.However, if you encode it, it cannot be undone.In this case, if I write the same processing as the server in js, the logic will be disclosed and I feel that it will not be safe.So I decided to encrypt it with a public key and a private key, but I think it's too expensive.How do you solve this problem?
Thank you for your understanding.
algorithm security
(This is a supplement to Suzuki's answer)
Message digest hash such as SHA256 is not recommended for password hash.An algorithm has been developed for password hash, so use it.
Argon2 is considered the best at this time.The competition to determine the superiority of the password hash algorithm has been judged to be the best in 2015.However, since it is relatively new, if your system is unable to use libraries or bindings immediately, you can use algorithms such as bcrypt, script or PBKDF2 as an alternative.It's been a while since they came out, so you should be able to use them in a variety of systems and language processing systems.
In addition, Argon2 and bcrypt start the hash value string expression with a prefix that distinguishes algorithms and parameters, so you can mix hash values from old and new algorithms if you want to switch algorithms during system migration.DB does not need to have a separate column to record the algorithm.
Password hash and message digest hash have the same principle as a one-way function, but implementation policy changes depending on the purpose of use.
Message digest has a large input, such as processing all messages on the communication path, so it can be calculated relatively quickly to process large amounts of data efficiently.On the other hand, the focus of the hash function for this purpose is to make it difficult to create meaningful data that has the same hash value as the specific hash value being targeted.MD5 and SHA1 are already weak for that purpose, but SHA2 is still OK at this time.
On the other hand, password hash has a very different nature: (1) input is short and usually only needs to be calculated once per session (2) an attacker only needs to find a match for a large number of hash values (3) and an attacker can calculate the hash value offline (before stealing DB).Therefore, contrary to the message digest hash, intentionally increasing the computational load is emphasized.Users don't mind increasing the hash value by 50 ms on a single login, but it's a big drag for an attacker who wants to calculate a large amount of password hash in advance.
This computational load can also be adjusted accordingly, as the computer advances keep up with it'sIn order to recalculate hash values from passwords at a later time, the load parameters used when calculating hash values are required.
Recently, large numbers of parallel computations have been available on GPUs, so simply increasing the computational load over time is not enough.Argon 2 also enhances the amount of memory required for calculation.
Recording the hash algorithm for each user is an old-fashioned method.
For general purposes, if the path is encrypted with SSL, the interval can be considered secure.If this is not reliable, all communication needs to be encrypted separately.
If the purpose is to increase authentication strength, it makes more sense to consider ways to enhance password authentication, such as two-factor authentication, one-time passwords, and authentication with user certificates.
If you write the same processing as the server in js, the logic will be published and it will not be safe
This is wrong in two ways.First, publishing logic is not a security concern.Even if the logic, hash value, salt, and stretch count are all leaked, it is very difficult to find the original password.That's the purpose of saving passwords as hash values.
It is not wrong that safety is not maintained, but the reason is wrong.There is absolutely no point in calculating and sending hash values on the client's side as long as it is a countermeasure against wiretapping.If a third party gets a hash value, it can be authenticated using the hash value.
If you really don't want to send a raw password to the network, you need to consider a mechanism such as encryption or challenge response authentication as described in fumiyas's answer.If your system requires such a level of security, we recommend that you consult an expert.
It is true that there is a computational weakness in saving passwords using SHA2 and a significantly larger number of stretching is required.If you need to be highly resistant to brute force attacks using large computational resources, you may need to consider another algorithm.
On the other hand, SHA2 is a highly reliable algorithm that has not found any fatal defects in its studies, both in selection and in production.
There are many advantages to new algorithms because they are made after studying old things, but it is also true that they are reliable because they are old (especially in the field of security).The algorithm itself may not be a problem, but it may also be a problem with the implementation.
Consider what algorithms to choose.
It's better to separate user authentication issues from communication path safety issues.
First, SSL is a communication path safety technology that includes encryption technology using a common key or public key.Usually, it's not something you implement yourself, just choose to use HTTPS to communicate with the server.
User authentication uses hash because it does not leave passwords as data on the server.The server administrator has access to all files on the server.If the simple method is to save the password as data and match it against the password entered by the user, the password will be easily stolen by the administrator.Also, even if you trust the administrator, if the root privileges are taken away by the intruder, the password is immediately stolen by the intruder.
For example, it's like putting cash on the desk in the house.
If left on the server in the form of a hash, it is impossible to reverse the password, so access to a file containing a hash for matching does not mean that the password was stolen immediately.
In this case, you have a bankbook and a cash card in your house.Even if a thief breaks into a house and steals them, it doesn't mean that the deposit was immediately stolen from a bank account.
If question 2 means you don't want to pass the raw password regardless of whether the communication path is SSL, SCRAM would be good.
© 2024 OneMinuteCode. All rights reserved.