He leído que cuando hash de una contraseña, muchos programadores recomiendan el uso de la BCrypt algoritmo.

Estoy programando en C# y se está preguntando si alguien sabe de una buena aplicación para BCrypt? He encontrado esta página, pero realmente no sé si es falso o no.

¿Qué debo tener en cuenta al elegir una contraseña esquema de hashing? Es BCrypt una ‘buena’, la aplicación?

InformationsquelleAutor Svish | 2009-01-26

2 Comentarios

  1. 142

    Primera, algunos términos que son importantes:

    Hash – El acto de tomar una cuerda y la producción de una secuencia de caracteres que no se puede revertir a la cadena original.

    Cifrado Simétrico – (Generalmente conocido como «codificación») – El acto de tomar una cuerda y la producción de una secuencia de caracteres que puede ser descifrada a la cadena original a través del uso de la misma clave de cifrado que cifró.

    Rainbow Table – una tabla de búsqueda que contiene todas las variaciones de los caracteres de hash en un determinado algoritmo de hash.

    Sal – una conocida cadena aleatoria anexa a la cadena original antes de que se fragmenta.

    Para el .NET Framework, Bcrypt aún no tiene un verificado implementación de referencia. Esto es importante porque no hay manera de saber si hay graves fallas en una implementación existente. Usted puede obtener una implementación de BCrypt para .RED aqui. No sé lo suficiente acerca de la criptografía para decir si es una buena o mala aplicación. La criptografía es un muy profundo de campo. No intente construir su propio algoritmo de cifrado. En serio.

    Si se va a implementar su propia contraseña de seguridad (suspiro), entonces usted necesita para hacer varias cosas:

    1. Utilizar un relativamente algoritmo de hash seguro.
    2. Sal cada una contraseña antes de que sea hash.
    3. Utilizar un único y largo de sal para cada contraseña, y el almacén de la sal con la contraseña.
    4. Requieren contraseñas seguras.

    Por desgracia, incluso si puedes hacer todo esto, una determinada hacker todavía potencialmente podría averiguar las contraseñas, que acaba de tomar de él un tiempo muy largo. Esa es su principal enemigo: Tiempo.

    La bcrypt algoritmo funciona, porque toma cinco órdenes de magnitud más de hash de una contraseña que MD5; (y aún mucho más de AES o SHA-512). Las fuerzas de la hacker a pasar mucho más tiempo para crear un arco iris de la tabla a la búsqueda de sus contraseñas, lo que es mucho menos probable que las contraseñas estarán en peligro de ser hackeado.

    Si eres de salazón y el hash de las contraseñas, y la sal es diferente, a continuación, un posible hacker tendría que crear un arco iris de tabla para cada variación de la sal, sólo para tener un arco iris mesa para uno salado+hash de la contraseña. Esto significa que si usted tiene 1 millón de usuarios, un hacker ha de generar 1 millón de tablas rainbow. Si estás utilizando la misma sal por cada usuario, entonces el hacker sólo tiene que generar 1 arco iris tabla con éxito hackear su sistema.

    Si usted no está de salazón sus contraseñas, entonces todo lo que un atacante tiene que hacer es abrir una existente arco iris tabla para cada aplicación hay (AES, SHA-512, MD5) y ver si alguna de ellas coincide con el hash. Este ya se ha hecho, un atacante no necesita para el cálculo de estas tablas de arco iris sí mismos.

    Aún con todo esto, tienes que ser el uso de buenas prácticas de seguridad. Si pueden usar otro vector de ataque (XSS, SQL Injection, CSRF, et. al.) en su sitio, buena seguridad de la contraseña no importa. Eso suena como una polémica declaración, pero piensa en esto: Si puedo obtener toda la información del usuario a través de un ataque de inyección de SQL, o me puede conseguir sus usuarios para que me dé sus cookies a través de XSS, no importa cómo es bueno es su contraseña de seguridad es.

    Otros recursos:

    1. Jeff Atwood: .RED de Cifrado Simplificado (ideal para una visión general de la mezcla)
    2. Jeff Atwood: Acabo de iniciar sesión como usted
    3. Jeff Atwood: Usted probablemente almacenar contraseñas de forma incorrecta
    4. Jeff Atwood: La Velocidad De Hash

    Nota: por Favor recomendar otros buenos recursos. He deberá haber leído una docena de artículos por decenas de autores, pero algunos de escritura como claramente sobre el tema como Jeff. Por favor editar en artículos como usted los encuentra.

    • tal vez agregar a la sal en el párrafo que la sal debe ser elegido al azar
    • Buena convocatoria, agregó. Aunque eso no es importante. Usted puede simplemente utilizar la marca de hora del inicio de sesión de la sal. La diferencia que hace es que el atacante tiene que volver a calcular el arco iris tabla para cada sal. Eso es lo que hace que sea difícil, que no es elegido al azar. Lo que es aleatorio agrega otra capa de obsfucation, pero que es inútil una vez que el atacante es capaz de ver a su base de datos (que es el problema que hace que todas nuestras penas en el primer lugar).
    • No realmente, la sal no tiene que ser un secreto, el justo único para cada instancia. Desde únicos (como en todo el mundo) no es posible, al azar es la mejor cosa siguiente. También, marca de tiempo no es una buena sal como no hay suficiente entropía.
    • Me gustaría tener problema con su declaración de «Si se puede utilizar con éxito XSS o de inyección de SQL, buena seguridad de la contraseña no importa». Por el contrario, si se puede con éxito XSS o SQL inject su sitio, buena contraseña de seguridad es aún más importante. La clave aquí es «defensa en profundidad» — se debe reforzar la seguridad en la medida de lo posible en cada capa de la aplicación.
    • Absolutamente; mi punto estaba perdido: no Se puede simplemente decir, ‘Hey, hemos hash y la sal nuestras contraseñas, «estamos ok»!’
    • Un punto muy importante a tomar acerca de BCrypt. No solo es lento, por lo configurably, de manera exponencial lento. Fue diseñado específicamente para mantener con la ley de Moore. SHA/AES son realmente diseñado para ser rápido mientras que el resto de seguro, ya que la plaintexts se cree que tienen una alta entropía. BCrypt del forte es el hashing de la contraseña porque se puede usar complejidad algorítmica como un sustituto de entrada baja entropía.

  2. 71

    Que no debe utilizar BCrypt en .NET. Usted debe utilizar PBKDF2 como es con el construido en el .NET framework de implementación. Es la única disponible gratuitamente criptográficamente verificado la aplicación en .NET, junto con ser el algoritmo recomendado por el NIST.

    StackId utilizado anteriormente BCrypt y se trasladó a PBKDF2 por esta misma razón:

    Para los curiosos, estamos hashing de contraseñas con PBKDF2. Respectivo código
    es aquí (
    http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135
    ), a través de un par de capas de direccionamiento indirecto. En una iteración anterior, se
    estaban usando BCrypt; pero se mudó a PBKDF2 como está integrado en el .NET
    marco, mientras que BCrypt nos requieran para verificar la implementación de la
    (no pequeña empresa).

    Kevin Montrose, 27 De Mayo De 2011

    (Link actualizado en GitHub)

    Edición: El significado de verificado en términos criptográficos parece no ser fácil de entender, verificado una aplicación significa que ha sido criptográficamente demostrado ser implementado sin error. El costo de este se puede llegar fácilmente a $20,000 o más. Recuerdo cuando estaba haciendo la investigación sobre OpenSSL y de lectura, donde se expresó que no ha completado todo el proceso de verificación, pero si usted necesita plenamente comprobado que se puede señalar el camino correcto para él y mencionó los costos asociados. Ciertos requisitos del gobierno de incluir los mandatos para verificar algoritmos de cifrado.

    La bcrypt implementaciones .NETA no han sido verificados. El uso de un sin verificar el cifrado de la aplicación no se puede estar absolutamente seguro de que no hay ya sea intencional malicioso fallas en ella, tales como permitir a un backdoor en lo que se cifra o no intencional de la implementación de las fallas que resulten en criptográficamente inseguridad de los datos.

    2014 edición: Para cualquier persona que se cuestionaba la fuerza de la utilización de verificado cryptopgraphical algorithims ver la devastación que fue forjado por el heartbleed hack explotados en OpenSSL. Que es el costo de usar un sin verificar su implementación. Es segura…. hasta que descubres que cualquier persona puede leer todo el contenido de la memoria de su servidor.

    El autor de el cambio que introdujo Heartbleed, Robin Seggelmann, declaró que él «se perdió la validación de una variable que contenga una longitud» y negó cualquier intención de presentar una aplicación insatisfactoria. Siguiente Heartbleed de divulgación, Seggelmann sugirió un enfoque en el segundo aspecto, afirmando que OpenSSL no es revisado por un número suficiente de personas.

    Esta es la definición de un sin verificar su implementación. Incluso el más pequeño defecto puede resultar en debilitar la seguridad en su totalidad.

    2015 edición: Eliminado recomendación basada en el lenguaje y se reemplaza con los absolutos. Incrustado original de Kevin Montrose comentario para la posteridad.

    • Para citar a los vinculados comentario: «[nosotros] se trasladó a PBKDF2 como está integrado en el .NET framework, mientras que BCrypt nos requieran para verificar la aplicación». Tenga en cuenta que el comentario no dice que el algoritmo es mejor, solo que SE Dev Team considera la incorporada en el PBKDF2 aplicación más fiable que una biblioteca externa (que es, en última instancia, un juicio de llamada).
    • He actualizado mi respuesta. Esto no es acerca de lo que el ENTONCES equipo considera segura, pero un juicio entre inherentemente demostrado segura o, con suerte, seguro. El último, cuando se trata de la criptografía es inaceptable.
    • Me gustaría añadir a esto que el propósito de BCrypt/SCrypt por encima y más allá de la clave de estiramiento (que PBKDF2 hace bien) es también forzar el uso de una gran cantidad de memoria, que a su vez reduce la cantidad de intentos que el mismo hardware puede hacer en paralelo. Mientras que esto es grande para realmente contraseñas seguras también podría tener problemas de rendimiento en un entorno compartido, donde los usuarios se conectan al mismo tiempo. Hay toda una capa de las pruebas de rendimiento requerida para una BCrypt puesta de largo PBKDF2.
    • BCrypt requiere muy poca memoria. Sólo SCrypt requiere cantidades significativas.
    • Sólo para hacerlo más claro, la verificación puede significar la algoritmo (BCrypt) se verifica, o su aplicación (.NET de código) se verifica. La aplicación se puede probar fácilmente, basta con comparar el resultado con otras implementaciones, si el resultado es el mismo, y por lo tanto correcto, entonces no backdoor pueden estar ocultos en el interior. La seguridad criptográfica proviene del algoritmo, no de la aplicación, así como una biblioteca devuelve el hash correcto valor de seguridad se puede utilizar. Un punto a cuidar es, cuando la biblioteca también crea una sal único en sí mismo.
    • la cuestión es acerca de la verificación de la aplicación Y el algoritmo. Sólo porque usted puede de entrada x obtener y en 2 implementaciones de doens no significa que impl2 no tenga fugas de información que totalmente compromete la seguridad. Un sin verificar la implementación, literalmente, podría hacer WebRequest.Send(salt, key, text); return verifiedImplementation(salt, key, text)
    • Me pregunto cómo LO migrado todos los bcrypt hash de las contraseñas para el nuevo hash? No necesitan la cruda contraseñas hash con el nuevo algoritmo?
    • Una manera en que yo lo he hecho en el pasado, cuando la gente sesión, pídales que restablecer su contraseña, guardar la nueva contraseña en el nuevo algoritmo de hash.
    • No creo que tienes que preguntarles a restablecer sus contraseñas. En la siguiente sesión (donde el suministro de su texto de contraseña) puede hacer lo que yo creo.
    • se agregó información citando la reciente heartbleed hack. La verificación no es «un juicio» es segura o insegura, por definición.
    • así que realmente creo que uno puede realizar una verificación y, a continuación, estar un 100% seguro de que es seguro?
    • que no es la verificación asegura. La verificación asegura que no es matemático / criptográfica de fallas en la implementación del algoritmo para su especificación. Muchos verificado implementaciones son inútiles ahora que todo el algoritmo fue invalidado principios de SHA-# algoritmos MD5 y la parte superior de mi cabeza. Este es exactamente el corazón sangrar problema, no es que SSL es inseguro (a pesar de que varios sabores son) fue un error en la aplicación que derrotó a la seguridad en su totalidad en un espectacular horrible manera de exponer directa lecturas de memoria para servidores conectados a internet.
    • Este es buenos consejos y me sorprende que haya tantos upvotes. La comprobación de un BCrypt implementación en un lenguaje administrado es mucho, mucho más trivial a la hora de verificar algo como toda una implementación de SSL en C. Heartbleed es completamente irrelevante; que estaría mejor mencionar algo como PHP tipo de coaccionar a los problemas con el hash comprobaciones de igualdad. Además mientras en gran medida adecuada en un sentido práctico, PBKDF2 es un KDF, no una contraseña algoritmo de hash, mientras que BCrypt es la más adecuada. Independientemente, tendría mucho más sentido utilizar Argon2 estos días de todos modos, para el que no es un bien probada C# biblioteca
    • sugerimos que lea este hilo antes de decidir lo que es un buen algoritmo de hash para su uso. en c# security.stackexchange.com/questions/35250/…
    • Véase también owasp.org/index.php/Using_Rfc2898DeriveBytes_for_PBKDF2
    • ¿Qué evidencia existe de que Rfc2898DeriveBytes ha sido criptográficamente verificado en todas las plataformas compatibles? Como yo lo entiendo, todos los certificada FIPS algoritmos nombres terminan con «CryptoServiceProvider» o «Gnc», que este no. Pero entonces, no es una función de hash, pero un generador pseudoaleatorio que usa una función de hash, así que tal vez no es necesario, pero entonces volvemos a la pregunta de, ¿cómo podemos saber si es verificada?
    • la publicación del NIST es la prueba. Se incluye en la segunda frase.
    • El enlace está roto, pero he encontrado el documento. Lamentablemente sólo habla acerca de los algoritmos; no dice nada acerca de C# o .NET Framework implementaciones de los algoritmos, que era mi preocupación. La deuda implícita por Kevin Montrose – y usted – que estoy tratando de validar es que el .NETO de las implementaciones de estos han sido verificados.
    • esta parece ser la mejor prueba de support.microsoft.com/en-us/help/811833/…
    • Mm, sí. Quiero MS iba a decir explícitamente si su Rfc2898DeriveBytes está certificada. Sólo se menciona explícitamente que «Los nombres de estas clases se terminan en «CryptoServiceProvider» o «Gnc.»» (lo que implica que no es certificada), pero supongo que al menos proporcionar un medio por el cual usted puede comprobar para asegurarse, es decir, establecer la opción de sistema operativo para permitir que sólo certificada FIPS algoritmos y, a continuación, intente ejecutar un programa que utiliza PBKDF2 y la hasher de su elección.

Dejar respuesta

Please enter your comment!
Please enter your name here