Déjeme adivinar, está pensando que un servicio podría usar Honey Encryption en lugar de un proceso hash con sal (no necesariamente MD5) para almacenar las contraseñas de los usuarios y ofrecer una capa adicional de protección en caso de una violación de datos. Si pudiera funcionar para un solo usuario en su administrador de contraseñas, entonces podría funcionar para todos los usuarios de un sistema.
Esto es un error lógico.
El motivo por el que desea cifrado en un administrador de contraseñas es porque desea recuperar los datos. Entonces, sí, los métodos más fuertes de encriptación, e incluso las técnicas de engaño, pueden ser una buena idea. Pero esto no es tan seguro, tiene un proceso simple de sal y hash.
Desea un proceso hash porque es más fuerte que el cifrado, y esto se convierte en una opción viable si no necesita recuperar los datos, como en un proceso de verificación de contraseña como parte de la autenticación. El usuario proporciona una contraseña, la hash y la sal, y luego la compara con el valor almacenado en la base de datos de contraseñas.
Por lo tanto, si reemplaza el hashing por el cifrado (incluso si tiene características de engaño), reduce la fuerza del mecanismo de protección de datos. Mantén el hashing adecuado en el sistema de autenticación, pero si la idea de cifrado propuesta funciona, utilízala para tu propio almacenamiento de contraseña personal.