He leído que al descifrar una contraseña, muchos programadores recomiendan usar el algoritmo BCrypt.
Estoy programando en C # y me pregunto si alguien sabe de una buena implementación para BCrypt. Encontré esta página , pero realmente no sé si es falsa o no.
¿Qué debo tener en cuenta al elegir un esquema de hash de contraseña? ¿BCrypt es una implementación 'buena'?
Respuestas:
Primero, algunos términos que son importantes:
Hashing : el acto de tomar una cadena y producir una secuencia de caracteres que no se puede revertir a la cadena original.
Cifrado simétrico : (generalmente conocido como 'cifrado'): el acto de tomar una cadena y producir una secuencia de caracteres que se pueden descifrar en la cadena original mediante el uso de la misma clave de cifrado que la cifró.
Tabla Rainbow : una tabla de búsqueda que contiene todas las variaciones de caracteres hash en un algoritmo de hash específico.
Sal : una cadena aleatoria conocida agregada a la cadena original antes de que se divida en hash.
Para .NET Framework, Bcrypt aún no tiene una implementación de referencia verificada . Esto es importante porque no hay forma de saber si hay fallas graves en una implementación existente. Puede obtener una implementación de BCrypt para .NET aquí . No sé lo suficiente sobre criptografía para decir si es una implementación buena o mala. La criptografía es un campo muy profundo. No intente construir su propio algoritmo de cifrado . Seriamente.
Si va a implementar su propia seguridad de contraseña (suspiro), debe hacer varias cosas:
Desafortunadamente, incluso si haces todo esto, un hacker determinado aún podría descubrir las contraseñas, solo le tomaría mucho tiempo. Ese es tu principal enemigo: el tiempo .
El algoritmo bcrypt funciona porque se necesitan cinco órdenes de magnitud más para descifrar una contraseña que MD5 ; (y todavía mucho más tiempo que AES o SHA-512). Obliga al pirata informático a dedicar mucho más tiempo a crear una tabla de arcoíris para buscar sus contraseñas, por lo que es mucho menos probable que sus contraseñas estén en peligro de ser pirateadas.
Si está usando sal y hash para sus contraseñas, y cada sal es diferente, entonces un pirata informático potencial tendría que crear una tabla de arco iris para cada variación de sal , solo para tener una tabla de arco iris para una contraseña salada + hash. Eso significa que si tiene 1 millón de usuarios, un hacker debe generar 1 millón de tablas de arcoíris. Si está utilizando la misma sal para cada usuario, entonces el hacker solo tiene que generar 1 tabla de arcoíris para hackear con éxito su sistema.
Si no está usando sus contraseñas, todo lo que un atacante debe hacer es abrir una tabla Rainbow existente para cada implementación (AES, SHA-512, MD5) y ver si una coincide con el hash. Esto ya se ha hecho , un atacante no necesita calcular estas tablas Rainbow .
Incluso con todo esto, debes estar usando buenas prácticas de seguridad . Si pueden usar con éxito otro vector de ataque (XSS, inyección de SQL, CSRF, et al. ) En su sitio, la buena seguridad de la contraseña no importa. Eso suena como una declaración controvertida, pero piénselo: si puedo obtener toda su información de usuario a través de un ataque de inyección SQL, o puedo hacer que sus usuarios me den sus cookies a través de XSS, entonces no importa qué tan buena sea su contraseña la seguridad es .
Otros recursos:
Nota: Recomiende otros buenos recursos. Debo haber leído una docena de artículos de docenas de autores, pero pocos escriben sobre el tema tan claramente como lo hace Jeff. Edite los artículos a medida que los encuentre.
No debe usar BCrypt en .NET. Usted debe utilizar PBKDF2 al igual que con la implementación marco construido en .NET. Es la única implementación de verificación criptográfica disponible de forma gratuita en .NET, además de ser el algoritmo recomendado por NIST .
StackId usó anteriormente BCrypt y se mudó a PBKDF2 por esta misma razón:
Para aquellos curiosos, estamos contraseñas hash con PBKDF2. El código correspondiente está aquí ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), a través de algunas capas de indirección. En una iteración anterior, estábamos usando BCrypt; pero se trasladó a PBKDF2 ya que está integrado en el marco .NET, mientras que BCrypt requeriría que verifiquemos una implementación (no es una tarea pequeña).
Kevin Montrose, 27 de mayo de 2011
(Enlace actualizado en GitHub)
Editar: El significado de verificado en términos criptográficos parece no entenderse fácilmente, una implementación verificada significa que se ha demostrado criptográficamente que se implementa sin errores. El costo de esto puede llegar fácilmente a $ 20,000 o más. Recuerdo esto cuando estaba investigando sobre OpenSSL y leí donde decían que no habían completado todo el proceso de verificación, pero si es necesario verificarlo completamente, pueden indicarle el camino correcto para ello y mencionar los costos asociados. Ciertos requisitos gubernamentales incluyen mandatos para algoritmos de cifrado verificados.
Las implementaciones de bcrypt en .NET no se han verificado. Al usar una implementación de cifrado no verificada, no puede estar absolutamente seguro de que no haya fallas intencionales maliciosas, como permitir una puerta trasera a lo que es cifrado o fallas de implementación no intencionales que resultan en datos criptográficamente inseguros.
Edición de 2014: para cualquiera que haya cuestionado la necesidad de utilizar algoritmos criptográficos verificados, observe la devastación provocada por el hack desangrado explotado en OpenSSL. Ese es el costo de usar una implementación no verificada. Es seguro ... hasta que descubra que cualquier persona puede leer todo el contenido de la memoria de su servidor.
El autor del cambio que introdujo Heartbleed, Robin Seggelmann, declaró que "omitió validar una variable que contenía una longitud" y negó cualquier intención de presentar una implementación defectuosa. Tras la divulgación de Heartbleed, Seggelmann sugirió centrarse en el segundo aspecto, afirmando que OpenSSL no es revisado por suficientes personas.
Esta es la definición de una implementación no verificada. Incluso el defecto más pequeño puede provocar la invalidez de toda la seguridad.
Edición de 2015: Se eliminó el lenguaje basado en recomendaciones y se reemplazó con absolutos. Comentario original integrado de Kevin Montrose para la posteridad.