You’re confusing hashing with encryption. Hashing is always fixed length, where as encryption is not. This is important because in hashing you’ll never need to know the original value. The original value is only used to generate the hash. No two (different) values should ever produce the same hash (i.e. collision). The weaker the hash (e.g. md5), the more likely you’ll get collisions.
Now with encryption, you do need to get back the original value (decryption), and as such the length of the encrypted data will vary based on the length of the original data. But encrypting passwords is bad because that means someone could potentially decrypt the encrypted data and learn your password, at which point nothing would stop them from accessing your system.
Now, that doesn’t mean that people can’t guess your password. In fact, there is a whole facet to information system security dedicated to what’s called brute force cracking; rainbow tables, password salts, etc. this is why password entropy (entropy is a term used to reflect data that will feed into a random number generator that is used in both encryption and hashing to do their black magic) is important. The more entropy (i.e. the more characters allowed, and the longer the password), the more difficult and time-consuming it is to brute force your password. Limiting password length or characters because of storage space is a myth, lazy as hell, or worse, developer inexperience/ignorance and is dangerous as hell.
I understand the difference, hashes being one way for a reason. The claim was that what is being hashed will control the size, which if true would give some suggestions on what was hashed. In reading through the wiki on hashing though the variations in size are controllable for what’s needed in application, not because of the hash contents as was stated.
You’re confusing hashing with encryption. Hashing is always fixed length, where as encryption is not. This is important because in hashing you’ll never need to know the original value. The original value is only used to generate the hash. No two (different) values should ever produce the same hash (i.e. collision). The weaker the hash (e.g. md5), the more likely you’ll get collisions.
Now with encryption, you do need to get back the original value (decryption), and as such the length of the encrypted data will vary based on the length of the original data. But encrypting passwords is bad because that means someone could potentially decrypt the encrypted data and learn your password, at which point nothing would stop them from accessing your system.
Now, that doesn’t mean that people can’t guess your password. In fact, there is a whole facet to information system security dedicated to what’s called brute force cracking; rainbow tables, password salts, etc. this is why password entropy (entropy is a term used to reflect data that will feed into a random number generator that is used in both encryption and hashing to do their black magic) is important. The more entropy (i.e. the more characters allowed, and the longer the password), the more difficult and time-consuming it is to brute force your password. Limiting password length or characters because of storage space is a myth, lazy as hell, or worse, developer inexperience/ignorance and is dangerous as hell.
I understand the difference, hashes being one way for a reason. The claim was that what is being hashed will control the size, which if true would give some suggestions on what was hashed. In reading through the wiki on hashing though the variations in size are controllable for what’s needed in application, not because of the hash contents as was stated.