¿Es una buena idea almacenar las direcciones de correo electrónico solo como hash?

6

Actualmente estoy creando un servicio web en enlace similar a enlace que debería ayudar a los usuarios a obtener código LaTeX a partir de fórmulas dibujadas. Es parte de mi tesis de licenciatura y uno de los objetivos principales de este proyecto es facilitar la investigación en el campo del reconocimiento de escritura a mano en línea. Eso significa que quiero compartir todos los datos que obtengo de los usuarios.

La forma más fácil de hacerlo sería simplemente volcar la base de datos. De esta manera, podría hacer mi copia de respaldo y un volcado para los investigadores en un solo paso.

Solo hay dos partes en las que vacilo en compartirlo con el público tan pronto como otros usuarios utilicen mi sistema: direcciones de correo electrónico y contraseñas.

Contraseñas

La contraseña se almacena con hash y con sal (esto significa que almaceno md5($userpass.$salt) y $salt que es una cadena aleatoria de 8 caracteres con caracteres de A-Za-z0-9 - se genera la sal para cada usuario). ¿Es eso suficiente para que esté bien hacer esto público?

La parte principal de la pregunta es sobre la dirección de correo electrónico: en este momento, la almaceno como texto sin formato. Pero estoy pensando en almacenar un hash de la dirección de correo electrónico solamente. Este hash no se pudo eliminar, porque mi función de inicio de sesión funciona de la siguiente manera:

El usuario ingresa $email y $password . Ambos se envían como texto plano al servidor. Entonces el servidor hace (como pseudocódigo):

$pwdb, $salt = query(SELECT password, salt FROM users WHERE email = :email)
if (md5($password.$salt) == $pwdb) {
   Logged in
} else {
   Wrong password
}

Direcciones de correo electrónico

No importa si :email es $email o md5($email) o md5($email.$applicationwide_random_str) . Pero no puedo crear una nueva sal para cada usuario sin tener que pasar por cada uno de ellos (lo que probablemente no sería tan malo cuando creo que nunca tendré más de 10,000 usuarios).

Preguntas

  • ¿Cuánto tiempo tomaría "deshacer" un correo electrónico (por ejemplo, [email protected] o [email protected] ) que tiene un sal aleatorio de 8 caracteres adjuntos (por ejemplo, FHCJ81ru ) con hardware "estándar" (< $ 1000) cuando ¿No conoces la cadena al azar? ¿Es cuestión de segundos, minutos, horas o días?
  • ¿Es malo si la gente puede hacer eso? Quiero decir, también podrían simplemente enviar correos electrónicos y ver lo que reciben. En mi servicio, no hay muchos datos personales involucrados:
    • símbolos y fórmulas manuscritos
    • eventualmente se entregó
    • eventualmente cuando / donde la persona aprendió a escribir
    • eventualmente el idioma del usuario
  • ¿Por qué no hay servicio hash en la dirección de correo electrónico? (ok, no sé si no hay servicios que lo hagan, pero nunca he leído eso: las contraseñas de hashing son comunes, pero las direcciones de correo electrónico de hashing? Nunca escuché eso).
  • ¿Es una buena idea codificar los correos electrónicos si desea utilizar el correo electrónico solo si el usuario ha perdido su contraseña e iniciar sesión? (Pensé en usar OpenID, pero la mayoría de las personas no saben qué es)
pregunta Martin Thoma 08.05.2014 - 19:43
fuente

2 respuestas

17

Al final, hay dos preguntas: qué debe almacenar y qué debe compartir.

Lo que debes almacenar

El almacenamiento de la dirección de correo electrónico tiene la ventaja de que puede ponerse en contacto con los usuarios. Muchos sitios desean poder contactar a los usuarios que no están actualmente conectados. Por ejemplo, los sitios de comerciantes quieren poder notificar a los usuarios que su pedido ha sido enviado o que su pago ha sido rechazado. Muchos sitios tienen notificaciones de correo electrónico configurables. Es posible que los sitios deseen informar a los usuarios de una violación de la privacidad o la seguridad; las personas tienden a preferir que se les notifique de forma privada en lugar de conocerlas en las noticias. Y eso sin contar todos los propósitos nefarios (sendind --- spam --- "promociones").

Si decide que nunca necesita ponerse en contacto con los usuarios, almacene ( lento y con sal . No MD5 o SHA-2, sino PBKDF2 o bcrypt o scrypt.) hashes de correos electrónicos. Pero ten en cuenta las limitaciones.

Supongo que utilizará las direcciones de correo electrónico como identificadores únicos de usuario. Esto tiene un inconveniente: a veces las personas cambian los correos electrónicos. Por ejemplo, en el mundo académico (al que es probable que pertenezcan muchos usuarios), las personas a menudo usan su correo electrónico de su institución actual, y luego el próximo año este correo electrónico se vuelve inutilizable. Esto puede eliminarlos de las cuentas que están demasiado vinculadas a una dirección de correo electrónico. Asegúrese de permitir una forma de transición (lo que puede ser complicado si necesita acceso a la dirección de correo electrónico anterior para agregar una nueva).

Lo que debes compartir

Forzar brutalmente un hash salado requiere enumerar todas las posibilidades. El tiempo que se tarda en probar una posibilidad es un parámetro de configuración de un hash lento: debe hacerlo tan lento como lo admita su servidor, pero no más lento. Por lo tanto, la respuesta a "¿Cuánto tiempo tomaría" deshacer "un correo electrónico" es literalmente "lo que usted elija".

De todos modos, cuánto tiempo lleva la fuerza bruta en su base de datos de correo electrónico no es la pregunta decisiva. Obviamente, verificar que un correo electrónico está en su base de datos es práctico, su servidor lo hará todo el tiempo, y esto permite que alguien que conozca los hashes responda la pregunta "¿Bob tiene una cuenta?". Esto ya es una violación de la privacidad.

Lo mismo ocurre con la contraseña: incluso permitir que terceros comprueben si la contraseña de Bob es errónea. No es tan malo como revelar la contraseña de Bob, pero sigue siendo malo.

Por lo tanto, la respuesta simple es: no comunique a terceros las direcciones de correo electrónico o contraseñas, ni los hashes de ellas. Si accidentalmente se filtran hashes incluso, esto es una violación de la privacidad. Cuando comparte datos, use identificadores sin sentido para las cuentas de usuario, por ejemplo, ID secuenciales o UUID aleatorios.

También tenga cuidado con el alcance del alcance en su base de datos. Si almacena demasiada información sobre un usuario, esto puede permitir la identificación y hacer conexiones. Este es un problema común con las bases de datos médicas: si sabe que Alice estuvo en el Hospital Riverside del 1997-02-25 al 1997-03-03 y del 2001-07-21 al 2001-07-28, hay un registro de un solo paciente que ingresó en el Hospital Riverside en febrero de 1997, se retiró en marzo y fue ingresado nuevamente en julio de 2001; se identificó a Alice aunque su nombre nunca fue expuesto. No es probable que esto sea una preocupación con la información que planea almacenar ahora, pero téngala en cuenta.

    
respondido por el Gilles 08.05.2014 - 20:23
fuente
1

Nunca exporte datos de usuario, incluso en forma de hash, es probable que alguien encuentre una manera de romper el cifrado / hashing.

Tan solo exporta las tablas de datos relevantes, no la tabla de usuario. Tendrá referencias de clave externa en sus datos, por lo que sabrá qué elementos pertenecen al mismo usuario, pero será una cuenta de número anónimo para quien esté utilizando los datos volcados.

    
respondido por el marlene 09.05.2014 - 02:29
fuente

Lea otras preguntas en las etiquetas