[TheDong]

This isn't good security advice. Taking trunc(32, hex(sha512)) will still give you a result that is stronger cryptographically than taking the 32 characters hex(md5sum) would give you.

For more security, you of course can encode the sha512 hash in a format other than hex in order to let those 64 bytes be fewer characters. The hex encoding is only one of many encodings.

But the main point is that the solution to needing to store a shorter value is not to use a weaker hashing algorithm, but to truncate the result.

This is the reason that sha-512/256 exists as a truncated sha-512 even though sha-256 already existed.

[withinboredom]

This is even worse advice! If you have a small input, you want a hashing function that matches that size[1] of the input as closely as possible. Collisions aren't important here (so "strength" isn't important), just the randomness. MD5 and SHA families give you (mostly) random distributions. The bias in the results are practically meaningless.

[1] https://crypto.stackexchange.com/questions/12822/are-the-sha...

[phantom_rehan]

I was only trying to point out the apparent effect of randomness that hashes give. Randomness is the key here, since probably no one is going to brute force a unhashed password, since the password would already be known. Not all websites automatically truncate a password, although yes, using the first 'n' letters would be a good idea. Some websites straight up say the password is too long, and you might have to try and guess the limit.

I don't think the algorithm matters here, but only the length.

[tpetry]

The problem is some websites have very old password rules like uppercase characters and symbols. So you would need a hashing function which produces these, and change the algorithm per website depending on what they allow and disallow for password characters...