SHA1 vs md5 vs SHA256: ¿cuál usar para un inicio de sesión PHP?

No olvides que en las ciencias informáticas un error puede tener diversas resoluciones, no obstante aquí mostramos lo mejor y más óptimo.

Solución:

Ninguno. Deberías usar bcrypt. Los hash que mencionas están todos optimizados para ser rápidos y fáciles con el hardware, por lo que descifrarlos comparten las mismas cualidades. Si no tiene otra opción, al menos asegúrese de usar una sal larga y volver a hacer picadillo varias veces.

Usando bcrypt en PHP 5.5+

PHP 5.5 ofrece nuevas funciones para el hash de contraseñas. Este es el enfoque recomendado para el almacenamiento de contraseñas en aplicaciones web modernas.

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) 
    // Success! Log the user in here.

Si está usando una versión anterior de PHP, realmente debería actualizar, pero hasta que lo haga, puede usar password_compat para exponer esta API.

Además, por favor deja password_hash() genera la sal para ti. Utiliza un CSPRNG.

Dos advertencias de bcrypt

1. Bcrypt truncará silenciosamente cualquier contraseña de más de 72 caracteres.
2. Bcrypt se truncará después de cualquier NUL caracteres.

(Prueba de concepto para ambas advertencias aquí).

Es posible que tenga la tentación de resolver la primera advertencia haciendo un hash previo de sus contraseñas antes de ejecutarlas a través de bcrypt, pero hacerlo puede hacer que su aplicación se ejecute primero en la segunda.

En lugar de escribir su propio esquema, utilice una biblioteca existente escrita y / o evaluada por expertos en seguridad.

• ZendCrypt (parte de Zend Framework) ofrece BcryptSha
• PasswordLock es parecido a BcryptSha pero también cifra los hashes de bcrypt con una biblioteca de cifrado autenticada.

TL; DR – Utilice bcrypt.

Creo que usar md5 o sha256 o cualquier hash optimizado para la velocidad está perfectamente bien y tengo mucha curiosidad por escuchar cualquier refutación que puedan tener otros usuarios. Estas son mis razones

1. Si permite que los usuarios usen contraseñas débiles como Dios, amor, guerra, paz, entonces sin importar el cifrado, aún estará permitiendo que el usuario ingrese la contraseña, no el hash y estas contraseñas a menudo se usan primero, por lo tanto, esto es NO va a tener algo que ver con el cifrado.

2. Si no usa SSL o no tiene un certificado, los atacantes que escuchan el tráfico podrán extraer la contraseña y cualquier intento de cifrado con javascript o similar es del lado del cliente y se puede descifrar y superar fácilmente. De nuevo esto es NO va a tener algo que ver con el cifrado de datos en el lado del servidor.

3. Los ataques de fuerza bruta aprovecharán las contraseñas débiles y, nuevamente, porque le permite al usuario ingresar los datos si no tiene la limitación de inicio de sesión de 3 o incluso un poco más, el problema volverá a aparecer. NO tener algo que ver con el cifrado de datos.

4. Si su base de datos se ve comprometida, lo más probable es que todo se haya visto comprometido, incluidas sus técnicas de hash, sin importar cuán críptico lo haya hecho. Una vez más, esto podría ser un ataque XSS de un empleado descontento o una inyección SQL o algún otro ataque que no tenga nada que ver con el cifrado de su contraseña.

Creo que aún debería cifrar, pero lo único que puedo ver que hace el cifrado es evitar que las personas que ya tienen o de alguna manera obtuvieron acceso a la base de datos simplemente lean la contraseña en voz alta. Si se trata de alguien no autorizado en la base de datos, entonces tienes problemas más importantes de los que preocuparte, por eso Sony fue capturado porque pensaron que una contraseña encriptada protegía todo, incluidos los números de tarjetas de crédito, todo lo que hace es proteger ese campo.

El único beneficio puro que puedo ver en las complejas encriptaciones de contraseñas en una base de datos es retrasar a los empleados u otras personas que tienen acceso a la base de datos simplemente leyendo las contraseñas. Entonces, si es un proyecto pequeño o algo, no me preocuparía demasiado por la seguridad en el lado del servidor, en cambio, me preocuparía más por proteger cualquier cosa que un cliente pueda enviar al servidor, como inyección SQL, ataques XSS o la plétora de otras formas en que usted podría verse comprometido. Si alguien no está de acuerdo, espero leer una forma en que una contraseña súper cifrada es imprescindible desde el lado del cliente.

La razón por la que quería intentar dejar esto en claro es porque con demasiada frecuencia la gente cree que una contraseña cifrada significa que no tienen que preocuparse de que se vea comprometida y dejan de preocuparse por la seguridad del sitio web.

Como señaló Johannes Gorset, la publicación de Thomas Ptacek de Matasano Security explica por qué Las funciones de hash simples y de uso general, como MD5, SHA1, SHA256 y SHA512, son opciones de hash de contraseñas deficientes..

¿Por qué? Son demasiado rápidos: puede calcular al menos 1,000,000 de hash MD5 por segundo por segundo con una computadora moderna, por lo que la fuerza bruta es factible contra la mayoría de las contraseñas que la gente usa. ¡Y eso es mucho menos que un clúster de servidores de craqueo basado en GPU!

Salazón sin key estirar solo significa que no puede calcular previamente la tabla del arco iris, debe construirla ad hoc para esa sal específica. Pero realmente no hará las cosas mucho más difíciles.

El usuario @Will dice:

Todo el mundo habla de esto como si pudieran ser pirateados a través de Internet. Como ya se dijo, limitar los intentos hace que sea imposible descifrar una contraseña en Internet y no tiene nada que ver con el hash.

No es necesario. Aparentemente, en el caso de LinkedIn, utilizaron la vulnerabilidad común de inyección de SQL para obtener la tabla de base de datos de inicio de sesión y descifraron millones de contraseñas sin conexión.

Luego vuelve al escenario del ataque fuera de línea:

La seguridad realmente entra en juego cuando toda la base de datos se ve comprometida y un pirata informático puede realizar 100 millones de intentos de contraseña por segundo contra el hash md5. SHA512 es unas 10.000 veces más lento.

No, SHA512 no es 10000 veces más lento que el MD5, solo requiere aproximadamente el doble. Cripta / SHA512, por otro lado, es una bestia muy diferente que, como su contraparte de BCrypt, realiza key estiramiento, produciendo un hash muy diferente con una sal aleatoria incorporada y se necesitará entre 500 y 999999 veces más para calcular (el estiramiento se puede ajustar).

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

Entonces, la opción para PHP es Crypt / Blowfish (BCrypt), Crypt / SHA256 o Crypt / SHA512. O al menos Crypt / MD5 (PHK). Ver www.php.net/manual/en/function.crypt.php

Recuerda compartir esta reseña si te ayudó.

---

---

Utiliza Nuestro Buscador