Is it appropriate to compare the correctness of a string by intercepting the first n characters of the hash result of a string?

Of course we need to save the complete hash result when we store the user password, but sometimes the hash result is very long, and in some cases it looks bloated. For example, I want to write a simple cookie anti-counterfeiting program. The idea is to reversibly encrypt the original cookie value with mcrypt, then add salt to the value to calculate sha256 and intercept the first 10 digits of the sha256 result and attach them to the final cookie value. During verification, you only need to split the cookie value, decrypt the previous character, and calculate the sha256 to compare the first 10 bits with the subsequent value. Is this safe?

Reply content:

Of course we need to save the complete hash result when we store the user password, but sometimes the hash result is very long, and in some cases it looks bloated. For example, I want to write a simple cookie anti-counterfeiting program. The idea is to reversibly encrypt the original cookie value with mcrypt, then add salt to the value to calculate sha256 and intercept the first 10 digits of the sha256 result and attach them to the final cookie value. During verification, you only need to split the cookie value, decrypt the previous character, and calculate the sha256 to compare the first 10 bits with the subsequent value. Is this safe?

The hash value of the password should not be placed in the cookie. You can generate an additional token to verify the login.

This approach is still very common. The 16-bit md5 is implemented by first calculating 32 bits and then intercepting the middle 16 bits. Of course, if it is too short, be careful of being brute force cracked.