Almacenamiento / recuperación segura de datos en una base de datos

Navega tus respuestas
4

Estoy realizando un desarrollo de C # relativamente amateur para un pequeño equipo de soporte al cliente y estoy trabajando con la API SalesForce en mi aplicación. Con SalesForce, el inicio de sesión mediante la API requiere que adjunte un token de seguridad a la contraseña. Debido a que mis usuarios son meticulosos, será necesario que (solo) el token de seguridad se almacene en la base de datos de la aplicación para que no tengan que ingresarlo cada vez que la utilicen.

Espero obtener algunos consejos sobre el mejor método para mantener este razonablemente seguro, ya que esta es mi primera incursión en cualquier tipo de seguridad seria. He estado leyendo y recogiendo el método de cifrado / descifrado AESThenHMAC de esto publicar .

Mis pensamientos sobre el proceso son los siguientes:

  1. En el primer inicio de sesión en la aplicación, se le solicita al usuario su nombre de usuario, contraseña y token de seguridad.
  2. El token de seguridad se cifra con SimpleEncryptWithPassword desde arriba con su contraseña como parámetro de "contraseña" y se almacena en la base de datos.
  3. En los inicios de sesión posteriores, se le solicita al usuario su nombre de usuario y contraseña, el token de seguridad se recupera y descifra, luego el usuario inicia sesión con la API de SalesForce.

Mis preguntas son:

  • ¿Proporciona esto un nivel razonable de seguridad para el almacenamiento del token de seguridad?
  • Si no, ¿por qué no y qué puedo / debo hacer para mejorarlo?

  • Si es así, ¿cuál de los siguientes es el mejor método para indexar el token de seguridad por el nombre de usuario en la base de datos?

    1. El nombre de usuario es texto sin formato
    2. El nombre de usuario está hasheado
    3. El nombre de usuario se cifra de la misma manera que el token de seguridad

Gracias de antemano por cualquier consejo / ayuda / entrada.

    
pregunta Jdinklage Morgoone 17.11.2013 - 23:32
fuente

2 respuestas

4

El objetivo de CWE 257 es forzar a la aplicación de autenticación para evaluar las contraseñas no descifrandolas y comparándolas con el texto sin formato, sino cifrando (o encriptando) el texto sin formato y comparando los textos opacos. Pero la tuya no es la aplicación de autenticación; Es técnicamente el cliente. Las aplicaciones tienen que almacenar las contraseñas para los sistemas de back-end todo el tiempo, no hay forma de evitarlo. Heck, incluso mi navegador almacena contraseñas de vez en cuando.

Además, el vector de ataque detallado en CWE 257 no se aplica aquí. Un administrador no puede realmente descifrar el token sin la contraseña del usuario, porque la contraseña es la clave. Así que en mi opinión no te preocupes por eso.

En general, creo que tu idea está bien. Podría considerar vincularse al dispositivo (por ejemplo, establecer una cookie persistente segura con mucha entropía) y requerir que el usuario vuelva a ingresar el token al cambiar de dispositivo.

Una debilidad es que el usuario tendrá que desenterrar su token nuevamente si alguna vez cambia su contraseña; esto puede disuadirlo de cambiarlo a menudo. Por otra parte, parece que su base de usuarios principal no puede ser molestada con cosas como esas de todos modos.

    
respondido por el John Wu 20.11.2013 - 00:38
fuente
1

Esta propuesta no es un buen método para almacenar credenciales de autenticación. más notoria es una violación de CWE-257 . Las contraseñas no deben almacenarse en un formato recuperable, nunca, ningún sistema debe confiar en este diseño. Almacenar contraseñas de esta manera también es una violación de CWE-916 , usando bcrypt es una mejor alternativa .

    
respondido por el rook 18.11.2013 - 03:58
fuente

Lea otras preguntas en las etiquetas

preguntas simples sobre cumplimiento de PCI Referencia de contraseña no segura por correo electrónico