Usar un hash en lugar de datos de usuario

Hay dos cosas en mi interpretación de esto. Usted tiene un identificador, un mensaje y un cliente puede necesitar recordar un mensaje, pero para hacerlo, necesitarían un identificador (reemplazo) para mantener su privacidad, algo lo suficientemente fuerte como para que no se pueda adivinar. Por ejemplo:

MENSAJE ORIGINAL

FROM [email protected]
MSG: This product is giving me an issue

Inferiría que desea que su cliente muestre esto y cualquier mensaje para cualquier propósito, pero como no quieren que se almacenen sus datos personales, está buscando crear algo como esto:

FROM 7d9065d7076298c54b45b2672797cc7b
MSG: This product is giving me an issue

Si este es el caso, la principal preocupación sería si alguien pudiera descubrir el hash 7d9065d7076298c54b45b2672797cc7b (que es el resultado md5 de [email protected]). Por ejemplo:

$ echo [email protected] | md5
7d9065d7076298c54b45b2672797cc7b

Mientras que md5 se considera inseguro, esto se debe a que se puede generar una colisión. En este uso, un atacante cede poco en la creación de una colisión. Tendrían que ser capaces de determinar el valor del hash, no colisionarlo. En la práctica, debería estar bien, pero sería más adecuado agregar una sal (var result = md5 (salt + string);) o simplemente subir el hash a SHA512. Recuerde, el objetivo es proteger el identificador (dirección de correo electrónico) que se puede hacer en un grado decente de un ataque estándar / común / simple. Si puede o no soportar a alguien con recursos / intenciones es una pregunta diferente.

Si te refieres a un hash tanto en el mensaje como en el remitente, eso no es factible. Puede codificar el remitente y cifrar el mensaje. Incluso al hacerlo, si el sistema que contiene estos datos no está protegido por los principios de privilegios mínimos, vulnerabilidades, se convierte en un punto discutible.

MD5 es mejor que texto simple, pero solo marginalmente.

Si usa bcrypt con un salt, para encontrar todos los registros con el correo electrónico [email protected] , tendría que hash ese correo electrónico una vez por registro con ese registro de sal único. Eso se saldrá de las manos rápidamente, y como señala en su pregunta, no funcionará.

Lo que puede hacer en su lugar es usar un sal constante que sea el mismo para todos los registros. Entonces ya no se llama sal, sino pimienta. El valor de la pimienta debe ser aleatorio y tratarse con el mismo cuidado que un clave criptográfica , ya que sin ella es prácticamente imposible una fuerza bruta sobre los hashes.

Es importante entender que un pimiento no es tan seguro como una sal, ya que un forzador bruto en posesión de él obtendría la misma velocidad por no tener que calcular el hash una vez por registro como lo hace cuando realiza una búsqueda. Pero es mucho mejor que usar un algoritmo rápido como MD5 o SHA-256.

Una nota práctica: no estoy seguro si todas las implementaciones de bcrypt te permiten especificar la sal por ti mismo, y todas tendrán la sal incluida en la salida. Debe cortar esa parte antes de almacenarla, ya que el pimiento no debe almacenarse en la base de datos.