No guardar el email en texto plano en la base de datos y/o variables SESSION

[AlbertoBSD]

Modo Paranoico ON

Post Original: https://albertobsd.dev/blog/es/2020/01/no-guardar-email-en-texto-plano/

Déjame repetirte el titulo

No guardar el email en texto plano en la base de datos, No se necesita, no se requiere, es mas seguro.

Según esta publicación (Lectura recomendada)

https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9

Bug bounty de 15mil $ USD

Si nos ponemos paranoicos, no deberías de conocer el email del usuario, No se necesita, no se requiere.

¿Que dato valido entonces? Un hash del mismo email protegido con alguna key, Importante: Que no sea reversible es decir que teniendo el hash no exista forma de volver al email y/o password originales.

Los siguientes códigos requieren de un archivo key_db.dat el cual se puede generar con dd leyendo de /dev/random o con el método que mas les guste.

Código (php) [Seleccionar] Expandir


/*
metodo con hash_pbkdf2
*/
$halgo = "sha256";
$iterations = 2000000;
$email = "user@example.com";
$password = "P4ssw0rd";
$salt = hash_file($halgo,"key_db.dat",true);
$salida_email = hash_pbkdf2($halgo,$email,$salt,$iterations,0);
$salida_password = hash_pbkdf2($halgo,$password,$salt,$iterations,0);
echo "hash email: $salida_email\n";
echo "hash password: $salida_password\n";


/*
metodo Iterativo con hash_hmac ()
*/
$i = 0;
$data_email = substr($email,0);
$data_password = substr($password,0);
do {
$data_email = hash_hmac($halgo,$data_email,$salt,true);
$data_password = hash_hmac($halgo,$data_password,$salt,true);
}while($i++ < ($iterations - 1));
$data_email = hash_hmac($halgo,$data_email,$salt,false);
$data_password = hash_hmac($halgo,$data_password,$salt,false);
echo "hash email: $data_email\n";
echo "hash password: $data_password\n";

/*
metodo Iterativo solo con hash  (data y key concatenadas)
*/
$i = 0;
$data_email = substr($email,0);
$data_password = substr($password,0);
do {
$data_email = hash($halgo,$data_email.$salt,true);
$data_password = hash($halgo,$data_password.$salt,true);
}while($i++ < ($iterations - 1));
$data_email = hash($halgo,$data_email.$salt,false);
$data_password = hash($halgo,$data_password.$salt,false);
echo "hash email: $data_email\n";
echo "hash password: $data_password\n";



Nota que coloque Iteraciones igual a 2 Millones ya que no sabemos en un futuro que tan feasible sea realizar algun forcebrute a los hashes.

NO SE NECESITA GUARDAR EL EMAIL EN PLANO
- El usuario no se acuerda de su clave? Pides el email y aplicas el mismo algoritmo, se busca en la base de datos y si coincide con alguno de los hash envias el email, basándose en el email que te enviaron obviamente validando que sea email valido filter_var($email, FILTER_VALIDATE_EMAIL)

NO SE NECESITA, ok quieres enviarles noticias o mensajes cada X tiempo
- Se puede utilizar criptografía simétrica para guardar el email pero si te hackean la base de datos y el código fuente, lo van a poder obtener ellos mismos

déjame Repetírtelo una vez mas NO SE NECESITA GUARDAR EL EMAIL EN TEXTO PLANO

Incluso solo se necesita recibir el email en texto plano en 2 ocasiones, solo cuando se registra (Para validar que sea valido) y cuando quiere recuperar su password.

Para el login diario podrías recibir  solo un hash del mismo

var email = CryptoJS.SHA512($("#email").val()).toString().substring(1, 127);

Se le quitan 2 nibbles de los extremos al hash antes de ser enviado, por si se llega a interceptar en transito por algun exploit, no se pueda determinar al 100% cual es el email inicial

Se podría aplicar lo mismo al password (Muy recomendable asi tu nunca vez el password original del usuario)

Saludos!

[@XSStringManolo]

Quien sería el esperpento que dejó los tokens en el js? xDDD

A los .js no se les aplica cross origen --'

Si el toquen estubiera incluso en otro html no serviría para nada a un atacante porque no puede automatizar la obtención para la explotación remota. Y aún así podrían usar Ing Social para que algún incauto les pasase el token de "dinero gratis". xD

15.000$ Me parece muy poco para lo que implica un bug de estas características. Podrían planear un ataque masivo simultaneo y dejar en ridículo la seguridad e imagen de Paypal.

[AlbertoBSD]

Algun desempleado en este momento.

Pero igual hay que analizar si el token estaba en el script, no creo que sea el único script que este de esa manera.

Y luego esta el hecho de que tienen que reimplementar todos las paginas que utilizen tokens.... 🤔🤔

Es tardado ademas, si ya estaban acostumbrados a trabajar de cierta forma, va a estar dificil que cambien de paradigma de un momento a otro.

Imaginate que mas guardan sin cifrar numeros de tarjetas, cuentas de banco..

Creo que voy a ir dando de baja mi cuenta de paypal.

Saludos

[engel lex]

me parece demasiado paranoico... el email es infomacion publica :s y a menos que sea un sitio "moralmente sensible" no hay razon para ocultarlo... a demas quieres almacenar info de tus usuarios, y si te dumpean la DB, los email son lo de menos preocupacion para ti

[MinusFour]

Bueno, "no se necesita" puede depender de lo que este pensado en hacer el sistema... Por ejemplo, si estoy subscrito al NYT por correo me imagino que ellos si necesitan mi correo .

[AlbertoBSD]

Por eso agrege lo de modo paranoico. 😅

Siendo honestos la mayoria de los sitios no nesecitan el email si solo quieren para un login se puede utilizar los metodos AOuth con twitter github google facebook y demas.

Analizemos si es para un blog -> Caja de comentarios a no ser que el usuario marque una casilla de que quiere hacer publico su email pues lo publicas y ya.

Pero realmente queremos poner esa opcion con tanto SPAM que llega para que quieres mas?

El detalle es el siguiente, si todo el mundo "developers" cifraran o hashearan bien los passwords no hay problema  el email puede estar en texto plano. Sin embargo no todos los developers lo hacen y a cada rato sale que dumpearon tal o cual base de datos, pueden reversear el password y probar la combinación email/password en todos los servicios conocidos. Como todo el mundo utiliza un password diferente en cada servicio No hay riesgo... 🙄🙄🙄

Si es paranoico pero es seguro a no ser que necesites estar mandando email a esas direcciones cada día entonces minimo que se guarde con un cifrado simetrico.

Asi si te dumpean la DB minimo el email no aparece en las listas tipo have i been pwned.

Bueno, "no se necesita" puede depender de lo que este pensado en hacer el sistema... Por ejemplo, si estoy subscrito al NYT por correo me imagino que ellos si necesitan mi correo .

Exacto si es para una lista de distribucion  donde no se guarde relacion con tu password esta muy bien.
En ese caso i podrias tener una tabla en modo paranoico para el login y otra tabla no relacionada para la lista de correo y si el usuario quiere darse de baja, que NO dependa de su login, sino de un token hash.

[@XSStringManolo]

Para cifrar programáticamente con simétrica, necesitas tener la clave simétrica almacenada para poder cifrar/descifrar.

[AlbertoBSD]

Para cifrar programáticamente con simétrica, necesitas tener la clave simétrica almacenada para poder cifrar/descifrar.

Si pues, si ya te hackearon toda la base de datos y el sistema de archivos incluso el codigo fuente pues nada te va a salvar.

Por eso digo que no tendria que ser reversible.

En el código que puse hablo de una key en un archivo la cual si solo hackean la base de datos no van a obtener, en ese caso la key solo sirve como un padding/salt a la hora de hashear iterativamente.

Mi postura sigue siendo que no se guarde el email de forma reversible.

Saludos.