¿Un enfoque personalizado para proteger contraseñas de texto sin formato / nombres de usuario en la tabla de la base de datos?

4

Estoy en el proceso de crear una aplicación para permitir a los usuarios registrarse, conectar sus muchas cuentas de correo electrónico (como Gmail) al sitio y permitir actividades relacionadas con el correo electrónico ... como enviar un correo electrónico (no pregunte o diga "¡oh, el usuario puede ir a sus clientes de correo o la pestaña de Gmail para hacer eso!", lo sé, lo sé.) Se podría decir que estoy haciendo un cliente de correo en línea. Intenté explorar cómo ThunderBird, Outlook o el cliente de correo de Apple administran las credenciales de inicio de sesión, pero no pude entenderlo.

El Enfoque:

Cuando envían el nombre de usuario y la contraseña de su correo electrónico por primera vez a mi aplicación, hacemos lo siguiente:

  1. agregue el nombre de usuario y la contraseña con una clave de 30 a 40 caracteres (diferente para cada usuario)
  2. use el cifrado AES-256 (el nombre de usuario y la contraseña tienen diferentes claves almacenadas en otro lugar)
  3. luego almacene el nombre de usuario cifrado y la contraseña cifrada

Soy consciente de las teorías, los enfoques reconocidos por la industria para usar hashes de una sola vía y las muchas bibliotecas de código abierto, pero mi aplicación debe enviar las credenciales de correo electrónico del usuario, por ejemplo, cada vez que quieran enviar un correo electrónico.

Aquí hay una salida de muestra del registro de configuración de correo electrónico de un usuario almacenado en la base de datos (utilizando Rails):

#<EmailSetting id: 10, user_id: 3, 
username: "{\"v\":1,\"adata\":\"\",\"ks\":256,\"ct\":\"E1M3+Eza9w5yNIoBVS...", 
password: "{\"v\":1,\"adata\":\"\",\"ks\":256,\"ct\":\"8N/Ylh7IGiHKDz1QM7...", 
outgoing_server: "smtp.gmail.com", 
incoming_server: nil, 
email_connection_type: nil, 
outgoing_port: 587, 
outgoing_authentication_type: "plain">

Me gustaría asegurarme de que si alguna vez se compromete esta base de datos, puedo proteger al usuario de la mejor manera posible mientras presto un servicio.

Pregunta : ¿es esto lo suficientemente sólido como para proteger las credenciales de inicio de sesión del correo electrónico? ¿Hay algo que pueda estar olvidando al proteger la tabla de la base de datos?

    
pregunta Matthew Chan 21.09.2015 - 02:34
fuente

1 respuesta

1

Como proveedor de servicios, nunca debe almacenar contraseñas de manera que puedan recuperarse. Compararte con un cliente de correo electrónico es una mala manera de pensarlo y no tiene en cuenta la perspectiva de un atacante. Comprometer una instalación de Thunderbird solo obtiene un atacante una o unas pocas series de credenciales. Comprometer su servicio podría hacer que un atacante obtenga todas las credenciales de sus bases de clientes.

Como han señalado otros comentaristas, ahora tiene el trabajo de proteger el conjunto de contraseñas. Si eso está comprometido y el acceso a la base de datos es posible, ahora ha filtrado TODOS los nombres de usuario y contraseñas de gmail de sus clientes. Si tienes muchos clientes, esta es una mina de oro. No subestimes el poder de los atacantes dedicados.

Como señala Stephen Touset, debería utilizar la API de GMail , que no lo hace " t revela las contraseñas, pero usa tokens revocables utilizando el marco OAuth2 . Si estuvieras comprometido, todos los tokens podrían ser revocados. Eso no es posible si el atacante pudiera obtener todos los combos de nombre de usuario / contraseña.

    
respondido por el Steve Sether 20.07.2018 - 17:41
fuente

Lea otras preguntas en las etiquetas