SHA512 vs. Blowfish y Bcrypt [cerrado]


222

Estoy viendo algoritmos de hash, pero no pude encontrar una respuesta.

  • Bcrypt usa Blowfish
  • Blowfish es mejor que MD5
  • P: ¿pero es Blowfish mejor que SHA512?

Gracias..

Actualizar:

Quiero aclarar que entiendo la diferencia entre el hash y el cifrado. Lo que me llevó a hacer la pregunta de esta manera es este artículo , donde el autor se refiere a bcrypt como "hashing adaptativo"

Como bcrypt se basa en Blowfish, me llevaron a pensar que Blowfish es un algoritmo de hash. Si se trata de cifrado como lo han señalado las respuestas, me parece que no debería tener un lugar en este artículo. Lo peor es que está concluyendo que bcrypt es el mejor. Lo que también me confunde ahora es que la clase phpass (creo que se usa para el hashing de contraseñas) usa bcrypt (es decir, blowfish, es decir, cifrado). Según esta nueva información que me están diciendo (blowfish es encriptación), esta clase suena mal. ¿Me estoy perdiendo de algo?


2
No está mal; vea las actualizaciones de mi respuesta para obtener una explicación de cómo funciona bcrypt y por qué sirve para el mismo propósito que un algoritmo "unidireccional" basado en hash.
erickson

3
bcryptsimplemente tiene un "factor de trabajo" más alto por defecto. Se supone que SHA no ... a menos que use passhash9, que puede usar junto con un factor de trabajo. ¿Por qué esta pregunta cerrada? está lejos de ser respondida pero muy importante.

1
Link in question is down ...............
Pacerier

Respuestas:


320

Debería ser suficiente decir si bcrypt o SHA-512 (en el contexto de un algoritmo apropiado como PBKDF2) es lo suficientemente bueno . Y la respuesta es sí, cualquiera de los algoritmos es lo suficientemente seguro como para que se produzca una violación a través de una falla de implementación, no de criptoanálisis.

Si insiste en saber cuál es "mejor", el SHA-512 ha recibido revisiones exhaustivas de NIST y otros. Es bueno, pero se han reconocido fallas que, aunque no son explotables ahora, han llevado a la competencia SHA-3 por nuevos algoritmos hash. Además, tenga en cuenta que el estudio de los algoritmos hash es "más nuevo" que el de los cifrados, y los criptógrafos aún están aprendiendo sobre ellos.

Aunque bcrypt en su conjunto no ha tenido tanto escrutinio como Blowfish, creo que estar basado en un cifrado con una estructura bien entendida le da cierta seguridad inherente que carece de autenticación basada en hash. Además, es más fácil usar GPU comunes como herramienta para atacar hash basados ​​en SHA-2; Debido a sus requisitos de memoria, la optimización de bcrypt requiere hardware más especializado como FPGA con algo de RAM incorporada.


Nota: bcrypt es un algoritmo que usa Blowfish internamente. No es un algoritmo de cifrado en sí mismo. Se usa para ocultar irreversiblemente las contraseñas, así como las funciones hash se usan para hacer un "hash unidireccional".

Los algoritmos hash criptográficos están diseñados para ser imposibles de revertir. En otras palabras, dada solo la salida de una función hash, debería llevar "para siempre" encontrar un mensaje que produzca la misma salida hash. De hecho, debería ser computacionalmente inviable encontrar dos mensajes que produzcan el mismo valor hash. A diferencia de un cifrado, las funciones hash no se parametrizan con una clave; la misma entrada siempre producirá la misma salida.

Si alguien proporciona una contraseña que coincide con el valor almacenado en la tabla de contraseñas, se autentica. En particular, debido a la irreversibilidad de la función hash, se supone que el usuario no es un atacante que se apoderó del hash y lo invirtió para encontrar una contraseña que funcione.

Ahora considere bcrypt. Utiliza Blowfish para encriptar una cadena mágica, usando una clave "derivada" de la contraseña. Más tarde, cuando un usuario ingresa una contraseña, la clave se deriva nuevamente, y si el texto cifrado producido al cifrar con esa clave coincide con el texto cifrado almacenado, el usuario se autentica. El texto cifrado se almacena en la tabla de "contraseña", pero la clave derivada nunca se almacena.

Para romper la criptografía aquí, un atacante tendría que recuperar la clave del texto cifrado. Esto se llama un ataque de "texto plano conocido", ya que el ataque conoce la cadena mágica que se ha cifrado, pero no la clave utilizada. Blowfish se ha estudiado ampliamente, y aún no se conocen ataques que permitan a un atacante encontrar la clave con un solo texto plano conocido.

Entonces, al igual que los algoritmos irreversibles basados ​​en resúmenes criptográficos, bcrypt produce una salida irreversible, a partir de una contraseña, sal y factor de costo. Su fuerza radica en la resistencia de Blowfish a los ataques de texto sin formato conocidos, que es análogo a un "primer ataque previo a la imagen" en un algoritmo de resumen. Como se puede usar en lugar de un algoritmo hash para proteger las contraseñas, bcrypt se conoce de manera confusa como un algoritmo "hash".

Suponiendo que las tablas del arco iris se han visto frustradas por el uso adecuado de la sal, cualquier función verdaderamente irreversible reduce al atacante a prueba y error. Y la velocidad con la que el atacante puede realizar pruebas está determinada por la velocidad de ese algoritmo irreversible "hash". Si se usa una sola iteración de una función hash, un atacante puede hacer millones de pruebas por segundo utilizando un equipo que cuesta del orden de $ 1000, probando todas las contraseñas de hasta 8 caracteres en unos pocos meses.

Sin embargo, si la salida de resumen se "retroalimenta" miles de veces, llevará cientos de años probar el mismo conjunto de contraseñas en ese hardware. Bcrypt logra el mismo efecto de "fortalecimiento de claves" al iterar dentro de su rutina de derivación de claves, y un método basado en hash adecuado como PBKDF2 hace lo mismo; a este respecto, los dos métodos son similares.

Por lo tanto, mi recomendación de bcrypt se deriva de los supuestos 1) que un Blowfish ha tenido un nivel de escrutinio similar al de la familia SHA-2 de funciones hash, y 2) que los métodos criptoanalíticos para cifrados están mejor desarrollados que los de las funciones hash.


44
+1 gran publicación. Pero tengo dos preguntas. Blowfish fue reemplazado por dos peces hace más de una década, ¿no debería un sistema utilizar primitivas modernas? También miles de iteraciones parecen un desperdicio en sistemas como aplicaciones web donde muchas personas inician sesión en un momento dado. Por ejemplo, PBKDF2 solo se implementa en escenarios en los que 1 persona inicia sesión a la vez, como una función string2key para un sistema de archivos cifrado. Uso el adagio "Si es demasiado pesado para que el atacante lo levante, entonces es demasiado pesado para su servidor". ¿Qué piensas?
torre el

17
No creo que haya nada malo en usar una primitiva más moderna. Las vulnerabilidades a menudo se descubren con el paso del tiempo, y Twofish se desarrolló utilizando el conocimiento obtenido de Blowfish. Sin embargo, no estoy al tanto de las vulnerabilidades específicas que invalidarían el uso de Blowfish, por lo que también podría hacerse un argumento de "si no está roto". Tu adagio sobre los atacantes no me suena bien. Incluso si elige un algoritmo que requeriría años para que un atacante pruebe mil millones de contraseñas, consumirá una fracción insignificante de tiempo en una aplicación legítima.
erickson

15
Si observa la especificación de cualquier función hash, no verá nada sobre "sal". El único parámetro es el mensaje a digerir. Revise la especificación de cualquier cifrado, y verá que la función está parametrizada con una clave. La "sal" que puede (o no ) usarse junto con un hash es simplemente parte del mensaje. El algoritmo hash no lo requiere, no lo trata especialmente y no puede diferenciarlo del resto del mensaje. Entonces, si bien es cierto que los mensajes a menudo son alterados por la sal, un mensaje dado produce solo un hash.
erickson

1
@Andre D Como pentester, informo sobre las aplicaciones que bloquean cuentas y sobre las aplicaciones que no evitan la fuerza bruta. Idealmente, una dirección IP infractora debe resolver un captcha, además, si un nombre de usuario está dirigido (incluso si ese nombre de usuario no existe), esa cuenta debería resolver un captcha antes de autenticarse. Hacer cumplir un ratelimit de X por minuto también es aceptable. Relacionado: security.stackexchange.com/questions/25444/…
torre

2
@rook: aunque las aplicaciones de ratelimitación son una buena práctica, puede suponer en este caso que la base de datos se ha descargado y colocado en un equipo que no tiene el límite de velocidad que usted describe.
Ellert van Koperen

50

Estoy de acuerdo con la respuesta de Erickson, con una advertencia: para propósitos de autenticación de contraseña, bcrypt es mucho mejor que una sola iteración de SHA-512, simplemente porque es mucho más lento. Si no entiendes por qué la lentitud es una ventaja en este juego en particular, lee el artículo al que vinculaste nuevamente (desplázate hacia abajo hasta "La velocidad es exactamente lo que no quieres en una función hash de contraseña ").

Por supuesto, puede crear un algoritmo de hash de contraseña seguro alrededor de SHA-512 repitiéndolo miles de veces, al igual que funciona el algoritmo MD5 de PHK. Ulrich Drepper hizo exactamente esto , para la cripta de glibc (). Sin embargo, no hay una razón particular para hacer esto si ya tiene una implementación de bcrypt probada disponible.


3
Espero que mi respuesta deje en claro que una sola iteración de hash no es suficiente (lamentablemente, incluso este nivel rudimentario de conocimiento no se puede suponer). "Si se usa una sola iteración de una función hash, un atacante puede hacer millones de pruebas por segundo usando un equipo que cuesta del orden de $ 1000, probando todas las contraseñas de hasta 8 caracteres en unos pocos meses. Si, sin embargo, la salida de resumen se 'retroalimenta' miles de veces, llevará cientos de años probar el mismo conjunto de contraseñas en ese hardware. Bcrypt logra el mismo efecto de 'fortalecimiento de clave' al iterar ... "
erickson

@erickson: Sí, aunque creo que podría haber enterrado el lede allí. El punto que estaba tratando de hacer es que una comparación directa de bcrypt y SHA-512 no es realmente relevante, porque una es una función de derivación clave y la otra es solo una primitiva criptográfica, inadecuada por sí sola.
caf


1
El uso de miles de rondas de SHA-512 no es desconocido y dada su inclusión en varias cryptimplementaciones (incluso en PHP que uso), cuando leí la pregunta original, incluso asumí que eso era lo que el OP quiso decir cuando preguntó sobre SHA-512: que en realidad se refería a miles de rondas de SHA-512 vs bcrypt que usa cientos o miles de iteraciones en sí.
thomasrutter

33

Blowfish no es un algoritmo hash. Es un algoritmo de encriptación. Lo que eso significa es que puedes encriptar algo usando blowfish, y luego puedes desencriptarlo de nuevo a texto plano.

SHA512 es un algoritmo hash. Eso significa que (en teoría) una vez que hash la entrada no puede recuperar la entrada original de nuevo.

Son 2 cosas diferentes, diseñadas para ser utilizadas para diferentes tareas. No hay una respuesta "correcta" a "¿es mejor el pez globo que SHA512?" También podrías preguntar "¿son las manzanas mejores que los canguros?"

Si desea leer más sobre el tema aquí hay algunos enlaces:


18
Creo que la pregunta es sobre el uso de bcrypt como una protección irreversible para las contraseñas, al igual que el hash se usa para ese propósito.
erickson el

3
@erickson el texto "P: pero ¿Blowfish es mejor que SHA512?" me parece bastante claro y muestra que el OP no entiende las diferencias entre los 2 algoritmos
Glen

1
OP aquí. En realidad, según la respuesta de Glen de que el pez globo es un algoritmo de cifrado (que entiendo es diferente del hash), me doy cuenta ahora de que mi pregunta sí estaba confundida. Sin embargo, lo que es confuso ahora es que la clase phpass (utilizada para el hashing de contraseñas, creo) usa bcrypt (es decir, blowfish, es decir, cifrado). Si blowfish es encriptación, ¿cómo es que phpass lo usa para descifrar contraseñas, me parece un defecto, no? ¿Me estoy perdiendo de algo?
Chris

2
sin embargo, la pregunta pregunta cuál de las manzanas y los canguros son más adecuados para una tarea específica. Blowfish es una mejor función de hash que sha debido al tiempo que lleva hacerlo. La mayoría de las implementaciones de sha que he visto son muy rápidas. Desea un algoritmo lento para el hash de contraseña.
John Nicholas

Esta respuesta es correcta que Blowfish es un algoritmo de cifrado, pero en este contexto (por ejemplo, cuando se usa bcrypt) se usa como un algoritmo de hash derivando una clave de la cadena de origen y usándola para cifrar un número mágico. Esto lo hace irreversible, esencialmente una función hash. No puede calcular la clave a partir de un cifrado, incluso si conoce el texto sin formato y los datos cifrados.
thomasrutter

4

Blowfish no es mejor que MD5 o SHA512, ya que tienen diferentes propósitos. MD5 y SHA512 son algoritmos de hash, Blowfish es un algoritmo de cifrado. Dos funciones criptográficas completamente diferentes.


2

Recomendaría la implementación de la cripta basada en SHA-256 / SHA-512 de Ulrich Drepper.

Portamos estos algoritmos a Java, y puede encontrar una versión con licencia gratuita de ellos en ftp://ftp.arlut.utexas.edu/java_hashes/ .

Tenga en cuenta que la mayoría de las unidades modernas (L) admiten el algoritmo de Drepper en sus archivos / etc / shadow.


PWDTK sourceforge.net/projects/pwdtknet usa HMAC-SHA512, sin embargo lo hace durante muchas iteraciones para crear "lentitud", también conocido como Key Stretching, como otros han estado hablando aquí. BCrypt es mejor que un solo SHA-512 como se ha mencionado, sin embargo, si usa SHA-512 en algo como PBKDF2, entonces está bien seguro (siempre que esté usando una sal criptoaleatoria grande y suficientes iteraciones para forzar el tiempo para haga una tabla de arcoíris), la API que acabo de publicar fue creada por mí y hará lo que quiera en .NET si eso es para lo que está desarrollando (para beneficio de futuros lectores)
thashiznets

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.