Cómo proteger las contraseñas cuando el sitio está abierto (duplicar)

Una implementación criptográfica adecuada no se basa en la oscuridad. Todavía debe resistir incluso cuando se conocen los métodos de hash y / o cifrado, siempre que la clave (por ejemplo, la contraseña) aún esté protegida.

Como han señalado otros, no debe utilizar un sal estático para su base de datos de contraseñas. Esto casi anularía el propósito de una sal, al permitir que un atacante realice un cálculo previo de una tabla de arco iris que será útil contra una gran cantidad de contraseñas.

En lugar de eso, cada contraseña debe tener un salt único que se genera aleatoriamente cuando se crea la cuenta. El método para generar las sales y para codificar las contraseñas puede ser público. Las hashes de sales y contraseñas deben guardarse en una base de datos segura.

Sin embargo, esto no es una panacea . Aún debe tomar las medidas adecuadas para proteger la confidencialidad de la base de datos de contraseñas. Por supuesto, si su sitio es vulnerable a la inyección de SQL, se podría tomar la base de datos de contraseñas. Y luego, por supuesto, es solo cuestión de tiempo antes de que todas las contraseñas se descifren independientemente del mecanismo de salado o hash.

La sal única por usuario, no evita completamente que la contraseña se vea comprometida. Solo lo retrasa al agregar otro elemento al proceso del cual un atacante no tendrá conocimiento previo. Compara los siguientes escenarios:

• hash sin sal: el atacante ya podría tener una tabla de arco iris pre-calculada para su mecanismo de hash, y podría tener todas las contraseñas descifradas el mismo día de la recuperación de la base de datos.
• Sal estática (pública o privada): una vez que se conoce la sal estática (ya sea a través de la inclusión en el código de fuente abierta o el compromiso del sistema), el atacante solo necesita generar una tabla de arco iris uno para rompe cualquier contraseña en tu base de datos. No estoy muy familiarizado con cómo van estas cosas, pero parece que podría ser algo que valga la pena esperar si la base de datos de contraseñas de destino es bastante grande o protege algo de valor real.
• Sal única, almacenada de forma segura: no se puede esperar que una cantidad de precálculo funcione de manera efectiva contra esto, a menos que el atacante tenga una base de datos inconcebiblemente grande que contenga tablas de arco iris para todas las sales posibles. A falta de eso, el atacante tendrá que forzar cada contraseña individualmente. Dada una implementación criptográfica adecuada, esto probablemente tomará más tiempo del que el atacante, o cualquiera de sus descendientes previsibles, pueda permitirse.

Hay mucha buena orientación en las respuestas y comentarios aquí. Te sugiero encarecidamente que lo mires. Además, recuerde la Regla # 1 de la criptografía: no haga rodar su propio criptografía.

Idealmente, debería generar un salt aleatorio para cada cuenta de usuario y almacenar el salt en la base de datos. Si bien el código para generar las sales podría ser público, las sales en sí no deberían.

La mayoría de los marcos web tienen una forma estándar y generalmente segura incorporada para almacenar contraseñas, así que lo mejor es investigar antes de implementar algo desde cero.

Esto no solo te ahorrará tiempo sino que también será más seguro que tu propia implementación, especialmente si tienes poca experiencia en escribir código de seguridad específico.