3 ms·

If we think about it in good faith, there are some cases where hash is used for PROTECTION. Like in a password storing of hash(salt+password). So while technica

by yonixw 5y ago

If we think about it in good faith, there are some cases where hash is used for PROTECTION. Like in a password storing of hash(salt+password). So while technically correct, in the day to day language we do use hash as an encryption alternative sometimes.

KSPAtlas 5y ago
An encrypted password is worse than a hashed one, since you only need it to be one way
mypastself 5y ago
Yeah, the definitions and analogies in the linked article are correct, but I doubt they’d be entirely clear to the uninitiated since they explain the processes but not applications for all three concepts. We get the “how”s but not all of the “why”s. I suspect it’s partly for the reason you’ve mentioned: the line between uses can sometimes get blurry. It’s a decent article that could do with some additional clarifications.
feldrim 5y ago
Calling it as an alternative might be an exaggeration. Both are used in security or as a protection like you mentioned. Yet, encryption is a way of storing data for a future[0] use in a secure manner while using the hash, you destroy the data and keep only the footprint. [0] Future can be nanoseconds later in any data-in-transit unlike data-at-rest, so I picked future to address the ambiguity of time measurement in different contexta.
less_less 5y ago
The article isn't just technically correct. Hashes and encryption are both parts of cryptographic systems, but their use cases are different. For example, implementing a password database as encrypt(salt, password) would be no good at all: the salt is also stored in the database, so an attacker who steals that database could easily recover everyone's plaintext passwords. Password databases should use a specialized, intentionally slow hash function, with a salt and preferably also with a secret key. That is, they should use something like argon2(secret, salt, password) or HMAC(secret,argon2(salt,password)) -- the latter so that you can keep the HMAC secret on an HSM. This is a common interview question for a reason. A candidate who thinks hashes and encryption are typically alternatives isn't ready to do secure system design.
- yonixw 5y ago
  I agree, just pointed out where the confusion might come from..

by yonixw 5y ago

KSPAtlas 5y ago

An encrypted password is worse than a hashed one, since you only need it to be one way

mypastself 5y ago

Yeah, the definitions and analogies in the linked article are correct, but I doubt they’d be entirely clear to the uninitiated since they explain the processes but not applications for all three concepts. We get the “how”s but not all of the “why”s. I suspect it’s partly for the reason you’ve mentioned: the line between uses can sometimes get blurry. It’s a decent article that could do with some additional clarifications.

feldrim 5y ago

Calling it as an alternative might be an exaggeration. Both are used in security or as a protection like you mentioned. Yet, encryption is a way of storing data for a future[0] use in a secure manner while using the hash, you destroy the data and keep only the footprint. [0] Future can be nanoseconds later in any data-in-transit unlike data-at-rest, so I picked future to address the ambiguity of time measurement in different contexta.

less_less 5y ago

The article isn't just technically correct. Hashes and encryption are both parts of cryptographic systems, but their use cases are different. For example, implementing a password database as encrypt(salt, password) would be no good at all: the salt is also stored in the database, so an attacker who steals that database could easily recover everyone's plaintext passwords. Password databases should use a specialized, intentionally slow hash function, with a salt and preferably also with a secret key. That is, they should use something like argon2(secret, salt, password) or HMAC(secret,argon2(salt,password)) -- the latter so that you can keep the HMAC secret on an HSM. This is a common interview question for a reason. A candidate who thinks hashes and encryption are typically alternatives isn't ready to do secure system design.

yonixw 5y ago
I agree, just pointed out where the confusion might come from..