Protegiendo las contraseñas de los usuarios en aplicaciones de escritorio (Rev 2)

Question

Estoy creando un cliente de Twitter y estoy evaluando las distintas formas de proteger la información de inicio de sesión del usuario.

IMPORTANTE: Necesito proteger los datos del usuario de otras aplicaciones. Por ejemplo, imagina lo que sucede si un bot comienza a robar contraseñas Twhirl o Hotmail / GMail / Yahoo / Paypal de las aplicaciones que se ejecutan en el escritorio del usuario.

Aclaración: pregunté esto antes sin la parte 'importante', pero la interfaz de usuario de stackoverflow no ayuda a agregar detalles más adelante dentro de la conversación Q / A.

• Al parecer, el hash no lo hace
• ofuscar de manera reversible es como tratar de esconderme detrás de mi dedo
• Los sonidos de texto sin formato y posiblemente sean promiscuos
• Requerir que el usuario escriba su contraseña cada vez que la aplicación sea tediosa

¿Alguna idea?

Answer 1

Esto es un catch-22. O bien, debe hacer que el usuario escriba su contraseña cada vez o lo almacene de forma insegura (ofuscado, encriptado, lo que sea).

La forma de solucionar este problema es que más sistemas operativos incorporen administradores de contraseñas incorporados, como el llavero de OS X. De esa manera, simplemente almacena su contraseña en el llavero, el sistema operativo la mantiene segura y el usuario solo tiene que escribir 1 contraseña maestra. Muchas aplicaciones (como Skype) en OS X usan Keychain para hacer exactamente lo que estás describiendo.

Pero como probablemente estés usando Windows, diría que solo debes ir con algo de ofuscación y cifrado. Creo que puedes ser un poco paranoico con los robots de robo de contraseñas; Si su aplicación no tiene una base de usuarios grande, las probabilidades son bastante bajas de que alguien la apunte y específicamente intente robar las contraseñas. Además de eso, también tendrían que tener acceso al sistema de archivos de su víctima. Si ese es el caso, probablemente tengan un virus / gusano y tengan problemas mayores.

Answer 2

Creo que te estás perdiendo la imagen más grande aquí:

Si el escritorio está comprometido, eres F # *% ED!

Para robar una contraseña de su programa, un virus tendría que estar ejecutándose en el sistema como administrador. Si el virus lo ha logrado, robar contraseñas de su programa está muy abajo en su lista de cosas maliciosas que quiere hacer.

Answer 3

Guárdelo en texto sin formato y déjele saber al usuario .

De esa manera, no hay conceptos erróneos sobre qué nivel de seguridad ha alcanzado. Si los usuarios comienzan a quejarse, considere sobre una constante publicada en su sitio web. Si los usuarios siguen quejándose, " ocultar " la constante en su código y dígales que es una mala seguridad.

Si los usuarios no pueden mantener a las personas malas fuera de la caja, en efecto todos los datos secretos que tienen son conocidos por el Dr. Evil. No importa si está encriptado o no. Y si pueden mantener alejadas a las personas malvadas, ¿por qué preocuparse por almacenar contraseñas en texto simple?

Podría estar hablando aquí, por supuesto. ¿Hay algún estudio que demuestre que el almacenamiento de contraseñas en texto sin formato da como resultado una seguridad peor que el almacenamiento confuso?

Answer 4

Si está creando un cliente de Twitter, use su API

Twitter tiene muy buena documentación , por lo que te aconsejo que lo leas todo antes de crear un cliente. La parte más importante en relación con esta pregunta es que no necesita almacenar las contraseñas, almacene OAuth token en su lugar. Debe usar la etapa xAuth para obtener el token de OAuth y luego usar otras API de Twitter con este token OAuth donde sea necesario.

  

xAuth proporciona una forma para que las aplicaciones de escritorio y móviles intercambien   nombre de usuario y contraseña para un token de acceso OAuth. Una vez que el token de acceso   se recupera, los desarrolladores habilitados para xAuth deben deshacerse del inicio de sesión y   Contraseña correspondiente al usuario.

Nunca almacena contraseñas si puede salirse con la suya

Usando OAuth lo peor que puede pasar es que un tercero (black hat hacker) tenga acceso a esa cuenta de Twitter pero no a la contraseña . Esto protegerá a los usuarios que utilizan ingenuamente la misma contraseña para múltiples servicios en línea.

Utilice un llavero de algún tipo

Finalmente, estoy de acuerdo en que las soluciones prefabricadas, como el llavero de OSX, deben usarse para almacenar la información confidencial de OAuth, una máquina comprometida solo revelaría la información de los llaveros actualmente desbloqueados. Esto significa que en un sistema multiusuario solo los usuarios registrados tienen sus llaveros convertidos en vulnerables.

Otras limitaciones de daños

Es posible que haya algunas cosas que no haya tomado en Google para " mejores prácticas de seguridad " y comienza a leer lo que pueda ser relevante.

EDIT (en respuesta a la solución de caso general deseada deseada)

Desea, sin la intervención del usuario, acceso a un servicio en línea. Esto significa que, por lo general, usted tiene, como máximo, control de acceso de nivel de usuario a las credenciales de autenticación a través de algo como Keychain.

Nunca he usado el llavero OSX, así que ahora hablaré de SELinux. En SELinux también puede garantizar que estas credenciales de autenticación solo se otorgarían a su programa. Y si continuamos con el nivel del sistema operativo, también puede firmar todos los procesos desde el arranque hasta la criptografía, para estar seguro de que ningún otro programa pueda imitar su programa. Todo esto va más allá de un sistema de usuario típico y, dado este nivel de configuración, puede estar seguro de que el usuario no es lo suficientemente ingenuo como para comprometerse, o que un administrador de sistemas es lo suficientemente competente. En este nivel podríamos proteger esas credenciales.

Supongamos que no vamos tan lejos para proteger esas credenciales, entonces podemos asumir que el sistema está comprometido. En este punto, las credenciales de autenticación se ven comprometidas, la ofuscación / cifrado de estas credenciales en el lado local no agrega ninguna seguridad real y tampoco almacena una parte o la totalidad en un servidor de terceros. Esto es fácil de ver porque, dado que no cuenta con la participación del usuario, su programa necesita iniciarse para obtener esas credenciales. Si su programa puede hacerlo sin entrada, también lo puede hacer cualquiera que haya revertido el protocolo de ofuscación / encriptación / servidor.

En este punto es una limitación de daños, no almacene la contraseña como credenciales de autenticación. Use OAuth, sesiones de cookies, hashs salados, etc., todos son solo tokens que representan que en algún momento en el pasado usted demostró que conocía la contraseña. En cualquier buen sistema, estos tokens pueden ser revocados, caducados y / o intercambiados periódicamente por un token nuevo durante la sesión activa.

El token (sea cual sea su forma) también puede contener información de autenticación de entrada no de usuario adicional que restringe su capacidad para usarlos en otros lugares. Por ejemplo, podría encapsular su nombre de host y / o dirección IP. Esto dificulta el uso de las credenciales en máquinas diferentes, ya que la imitación de estas formas de credenciales requeriría el acceso al nivel adecuado de infraestructura de red.

Answer 5

Después de una nueva reflexión, creo que encontré un camino. Usaré la autenticación ASP.net para la aplicación de escritorio de mi aplicación, almacenaré sus credenciales en línea y dejaré que el administrador de contraseñas de Internet Explorer maneje el almacenamiento en caché local de este par secundario o credenciales para mí.

Solo tendré que autenticarme a través de un formulario similar a la API de Facebook durante el primer inicio de sesión.

Answer 6

No lo entiendo ... ¿por qué el cifrado no es bueno? Use una clave grande y guárdela en el almacén de claves de la máquina (asumiendo Windows). Hecho y hecho.

Answer 7

OSX: Usa el llavero

Windows: usar CryptProtectData y CryptUnprotectData

Linux: use el anillo de claves de GNOME y KDE KWallet