When we store user passwords, we certainly need to save the complete hash results, but sometimes the hash results are very long and sometimes very bloated. For example, if I want to write a simple cookie anti-counterfeiting program, the idea is to first encrypt the original cookie value using mcrypt reversible encryption, and then splice the value into salt... when we store user passwords, we certainly need to save the complete hash results, but sometimes the hash results are very long and sometimes very bloated. For example, if I want to write a simple cookie anti-counterfeiting program, the idea is to first perform mcrypt reversible encryption on the original cookie value, then, the values are combined to calculate sha256 by salt, and the first 10 digits of the sha256 result are captured after the final cookie value. During verification, you only need to split the cookie value, decrypt the previous character, and calculate sha256 to get the first 10 digits and compare them with the subsequent values. Is this approach safe?
Reply content:
When we store user passwords, we certainly need to save the complete hash results, but sometimes the hash results are very long and sometimes very bloated. For example, if I want to write a simple cookie anti-counterfeiting program, the idea is to first perform mcrypt reversible encryption on the original cookie value, then, the values are combined to calculate sha256 by salt, and the first 10 digits of the sha256 result are captured after the final cookie value. During verification, you only need to split the cookie value, decrypt the previous character, and calculate sha256 to get the first 10 digits and compare them with the subsequent values. Is this approach safe?
The hash value of the password should not be placed in the cookie. you can generate another token to verify logon.
This practice is still very common. the 16-bit md5 is implemented by first calculating 32 bits and then intercepting the middle 16 bits. of course, it is too short to be cracked by brute force.