2009-09-08 10 views
13

utilizo actualmente,
base64_encode() para codificar la contraseña de un usuario, esto funciona bien, ya que me permite utilizar simplemente base64decode() para decodificar la contraseña de una palabra y enviar a su correo electrónico si pierden su contraseña.mejor manera de codificar las contraseñas en PHP

Aunque he estado leyendo la contraseña y mucha gente parece decir que debe usar sha1() para codificar una contraseña. Estoy totalmente a favor de mejorar la seguridad de mi sistema pero si convierto para usar shal() entonces no podré enviar a un usuario la contraseña perdida allí.

¿Qué USTED usa? ¿Me puedes dar algún consejo? ¿Y hay una forma de descifrar una contraseña legible para enviar un correo electrónico a un usuario?

Al escribir esta pregunta, me acordé de que algunos foros no te envían una contraseña cuando se te solicita, sino que envían un enlace especial para restablecer tu contraseña, supongo que es porque no pueden decodificar tu contraseña ¿tal vez?

//what I use now 
$password_encoded = base64_encode($password); 

//what I am considering using 
$password_encoded = sha1($password); 
+4

Ver a preguntas como éstas realmente me hacen nunca querer crear un inicio de sesión de usuario en cualquier sitio por temor a su terrible seguridad, como el almacenamiento reversible de contraseñas. – umassthrower

Respuesta

41

Por favor, por favor, por el bien de sus usuarios no almacenar sus contraseñas en cualquier formato reversible! No importa si está codificado en Base64 o triple-DES 168-bit encryption - si es reversible, es exactamente tan seguro como si no lo codificara en absoluto.

No sitio web que tiene algún interés en protegerse a sí mismo o sus usuarios (o tiene un poco de sentido) enviará a un usuario su contraseña por correo electrónico. Lo único que podemos hacer, incluso remotamente cerca de la seguridad, es enviar a los usuarios un correo electrónico con un enlace único de uso único que les permite establecer una nueva contraseña.

  • tienda un hash (bcrypt o PBKDF2) de la contraseña que ha sido salted
  • tirar la contraseña original tan pronto como se haya HASHED ella. Excluirlo de la memoria.
  • requieren siempre al usuario crear su propia nueva contraseña a través de un canal SSL

Tratando de llegar a funcionar con cualquier otra cosa es sinceramente simplemente negligencia. Usemos un escenario muy común usado en discusiones de seguridad:

Usuario El correo electrónico de Frederic está comprometido. Esto podría ser dejar su computadora desbloqueada o usar una contraseña débil. De todos modos, una persona no autorizada tiene acceso a sus mensajes. Idealmente, esto no significaría nada más que algunas cartas de amor embarazosas leídas por un extraño. Lamentablemente, la persona no autorizada descubre que un foro le enviará la contraseña de Frederic en texto sin formato. Al igual que la mayoría de los usuarios, Frederic usa la misma contraseña para todo, incluida su banca en línea. Su nombre de usuario aparece en un correo electrónico de su banco. Ahora la situación es muy desafortunada.

Los usuarios confían en usted cuando crean una relación basada en credenciales con usted. Parte de esa confianza es que mantendrá esas credenciales como un secreto seguro entre usted y ellos.

relacionada

Muchas de las cuestiones e ideas que rodean han respondido muy bien en SO:

+0

@anonymous - ¿Por qué el DV? –

+0

False: "exactamente tan seguro como si no lo codificara en absoluto" –

+6

@ d03boy security by dark es lo mismo que no tener seguridad. En un sistema autónomo como un sitio web, todas las partes necesarias para revertir los datos, sin importar qué tan ofuscadas estén, necesariamente deben estar presentes. Entonces, si un atacante obtiene acceso al sistema, el atacante tiene acceso a todas las partes. –

6

Debe dejar que un usuario REINICIE una contraseña pero nunca RECUPERAR su contraseña. Es por eso que desearía utilizar un hash de una vía (SHA2) en lugar de una forma de cifrado que le permita decodificarlo.

Imagina si dejaste tu correo electrónico abierto. Simplemente podría solicitar recuperar su contraseña para algún sitio web, eliminar el correo electrónico, y nunca lo sabría. Por otro lado, si me pedías que restableciera la contraseña, la contraseña de la cuenta cambiaría y el propietario obviamente se daría cuenta de que algo anda mal. (Este es un escenario tonto pero el concepto es lo importante)

Hashes puede "revertirse" probando todas las combinaciones posibles de palabras (o usando tablas rainbow) hasta que se produzca un hash coincidente. Una forma de evitar esto es agregar/anteponer la contraseña proporcionada con un salt para que sea una cadena muy larga e impredecible. La sal debe ser una cadena única de datos única para la cuenta del individuo.

En PHP no hay función SHA2. SHA-2 es una familia de algoritmos hash, (SHA-256, SHA-384, SHA-512, etc ...)

hash('sha256', 'The quick brown fox jumped over the lazy dog.'); 
+0

Estoy tratando de encontrar sha2, no parece estar en mi php – JasonDavis

+0

Actualizado con sha-2 info –

10

Como administrador, que en realidad nunca tiene que recordar la contraseña de un usuario. Simplemente necesita saber si una cadena que alguna vez enviaron es idéntica a otra.

Si un usuario olvida su contraseña, no es necesario que le digan su contraseña anterior, simplemente puede hacer que proporcione una nueva.

Dado que no necesita conocer las contraseñas reales, usar crytographic hash de las palabras parecería una forma segura de almacenarlas. Sin embargo, se han creado grandes tablas de cadenas precalculadas para realizar fácilmente una búsqueda inversa de la cadena original. Estos se llaman rainbow tables.

Para evitar la búsqueda fácil de cadenas pre-calculadas, debe salt sus contraseñas antes de hashing them. La sal puede ser su nombre de usuario antepuesto, o su ID de usuario postfixed, cualquier información adicional que tenga en el usuario que sea permanente y que pueda agregar fácilmente a la contraseña durante la autenticación.

+0

Lo veo si tuviera que tomar un usuario envió la contraseña y agregó el número de ID de usuario que nunca cambia su contraseña, luego encripta esa cadena, ¿esa sería una contraseña salada? – JasonDavis

+3

@jasondavis hash, no encriptar –

4

Base64Encode offer no seguridad, porque cualquiera puede revertirlo fácilmente.

Si absolutamente necesita revertir la contraseña, una buena forma es utilizar una pregunta secreta y usar la respuesta como una clave de cifrado. Una vez que la contraseña está encriptada, descarta la respuesta (no la almacena). También utiliza el cifrado sha1 estándar para el momento en que necesita verificar que ingresó la contraseña correcta. Si el usuario quiere su contraseña, ingrese la respuesta a su pregunta secreta, y la usa para restaurar la contraseña y devolvérselo.

No es tan seguro como el cifrado basado en hash solamente, pero si necesita devolver la contraseña es un buen compromiso.

Es posible que desee ver en la biblioteca mcrypt para php http://ca3.php.net/mcrypt

1

Siempre eliminar mi cuenta sólo los sitios que me correos electrónicos mis datos. Dediqué demasiado esfuerzo y tiempo a memorizar largas contraseñas aleatorias para que me las enviaran en texto sin formato.

Use sha1() o hash no reversible superior para identificar la contraseña. Al autenticar una contraseña de usuario, recupere el hash y compárelo con el hash de la contraseña proporcionada durante la autenticación. Si coinciden, entonces el usuario es auténtico dentro de los estándares razonables.

$user = "joe"; 
$password = 'password'; 

$saved_hash = DB::Query("select hash from users where username = ".quote($user)." LIMIT 1"); 

if (sha256($password) == $saved_hash) User::authenticated(); 

Nunca, nunca envíe contraseñas por correo electrónico. Enviar un no predecible clave única,, generado, como por ejemplo en PHP:

$key = sha256(time().rand().$secret_seed); 

Enviar esta tecla para el cliente, para un solo uso, para establecer una nueva contraseña.

+3

Tuve que DV para la pobre demostración de SQL –

+0

¿Qué tiene de malo ese SQL? – bucabay

5

Absolutamente imprescindible en este tema es el propio You're Probably Storing Passwords Incorrectly de Jeff. Aquí está el resumen ejecutivo:

  1. No invente su propio esquema de almacenamiento de contraseñas "inteligente".
  2. Nunca guarde las contraseñas como texto sin formato.
  3. Agregue una sal aleatoria larga y única a cada contraseña que almacene.
  4. Use un hash criptográficamente seguro.
0

Usted tendrá que utilizar un hash (preferiblemente SHA1) con "sal"

+1

Creo que, aún más preferiblemente, usted querría SHA2 –

+1

A pesar de las preocupaciones de que SHA1 tiene un defecto matemático que puede resultar en colisiones más fáciles de encontrar, incluyendo una sal evitará que ocurra. Langauges como PHP no son compatibles con SHA2 en la biblioteca estándar, por lo que SHA1 es una alternativa muy adecuada. –

0

Usted puede hacer el hash en el servidor cuando se autentica en una consulta rápida:

SELECT * FROM user WHERE password = MD5(CONCAT(?, salt)); 
+0

Este es un esquema terrible hashing débil. Las contraseñas no deben ser hash con MD5, porque este algoritmo es demasiado rápido y la fuerza bruta es demasiado fácil. – martinstoeckli

Cuestiones relacionadas