support - twitter restaurar contraseña
Protección de contraseñas de usuario en aplicaciones de escritorio(Rev 2) (7)
Estoy haciendo un cliente de Twitter, y estoy evaluando las diversas 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, imagine lo que sucede si un bot comienza a robar contraseñas Twhirl o Hotmail / GMail / Yahoo / Paypal desde aplicaciones que se ejecutan en el escritorio del usuario.
Aclaración: pregunté esto antes sin la parte ''importante'', pero la IU de stackoverflow no ayuda con la adición de detalles más adelante dentro de la conversación Q / A.
- Hashing aparentemente no lo hace
- Ofuscar de manera reversible es como tratar de esconderse detrás de mi dedo
- El texto sin formato suena y de manera propagable es promiscuo
- Exigir al usuario que escriba su contraseña cada vez haría que la aplicación sea tediosa
Algunas ideas ?
Creo que te estás perdiendo la imagen más grande aquí:
Si el escritorio está en peligro, ¡eres F # *% ED!
Para robar una contraseña de su programa, un virus debería estar ejecutándose en el sistema como administrador. Si el virus ha logrado eso, robar contraseñas de tu programa está muy abajo en su lista de cosas maliciosas que quiere hacer.
Este es un catch-22. O bien haces que el usuario escriba su contraseña cada vez, o la guardas insegura (ofuscada, encriptada, lo que sea).
La forma de solucionar esto es que más sistemas operativos incorporen administradores de contraseñas incorporados, como el Keychain de OS X. De esta forma, solo almacena su contraseña en Keychain, el sistema operativo la mantiene segura y el usuario solo debe ingresar 1 contraseña maestra. Muchas aplicaciones (como Skype) en OS X usan Keychain para hacer exactamente lo que usted está describiendo.
Pero dado que probablemente esté usando Windows, yo diría que solo tiene que ocultarse y encriptarse. Creo que puede ser un poco paranoico con respecto a los bots que roban contraseñas; si su aplicación no tiene una gran base de usuarios, las probabilidades son bastante bajas de que alguien lo apunte e intente específicamente 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.
No lo entiendo ... ¿por qué el cifrado no es bueno? Use una tecla grande y almacene la clave en el almacén de claves de la máquina (asumiendo Windows). Hecho y hecho.
Tras una mayor contemplación, creo que encontré la manera. Utilizaré 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 o mis credenciales secundarios.
Tendré que hacer que se autentiquen a través de un formulario similar a la API de Facebook durante el primer inicio de sesión.
Guárdelo en texto sin formato y avísele al usuario .
De esta forma, no hay conceptos erróneos sobre qué nivel de seguridad ha logrado. Si los usuarios comienzan a quejarse, considere la posibilidad de publicar una constante publicada en su sitio web. Si los usuarios siguen quejándose, "oculte" la constante en su código y dígales que es una mala seguridad.
Si los usuarios no pueden mantener a la gente mala de la caja, entonces, en efecto, todos los datos secretos que tienen son conocidos por el Dr. Evil. No importa si está encriptado o no. Y si pueden alejar a las personas malvadas, ¿por qué preocuparse de almacenar contraseñas en texto plano?
Podría estar hablando de mi trasero aquí, por supuesto. ¿Hay algún estudio que demuestre que el almacenamiento de contraseñas en texto plano da como resultado una peor seguridad que el almacenamiento de las mismas?
Si está haciendo un cliente de Twitter, entonces use su API
Twitter tiene muy buena documentación , por lo que le aconsejo que lo lea todo antes de hacer un cliente. La parte más importante en relación con esta pregunta es que no necesita almacenar las contraseñas, sino que almacena el token OAuth . Debes usar la etapa xAuth para obtener el token de OAuth y luego usar otras API de Twitter con este token de OAuth cuando sea necesario.
xAuth proporciona una forma para que las aplicaciones de escritorio y móviles intercambien un nombre de usuario y contraseña para un token de acceso OAuth. Una vez que se recupera el token de acceso, los desarrolladores habilitados xAuth deben disponer del nombre de usuario y la contraseña correspondientes al usuario.
Nunca almacena contraseñas si puede salirse con la suya
Al usar OAuth, lo peor que puede pasar es que un tercero (un hacker de sombrero negro) tenga acceso a esa cuenta de Twitter, pero no a la contraseña . Esto protegerá a los usuarios que ingenuamente usan la misma contraseña para múltiples servicios en línea.
Use un llavero de algún tipo
Finalmente, estoy de acuerdo en que las soluciones prefabricadas, como el llavero de OSX, deberían usarse para almacenar la información sensible 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 que inician sesión tienen sus llaveros vulnerables.
Otras limitaciones de daño
Puede haber cosas que me he perdido tomar un Google para "mejores prácticas de seguridad" y comenzar a leer lo que pueda ser relevante.
EDITAR (en respuesta a la solución de caso general deseada)
Desea, sin intervención del usuario, acceder a un servicio en línea. Esto significa que normalmente tiene, como máximo, control de acceso de nivel de usuario a las credenciales de autenticación a través de algo similar a Keychain.
Nunca he usado OSX Keychain, así que ahora hablaré de SELinux. En SELinux también puede asegurarse de que estas credenciales de autenticación solo se otorguen a su programa. Y si continuamos con las funciones de nivel de sistema operativo, también puede firmar todos los procesos desde el arranque hasta criptográficamente, asegúrese de que ningún otro programa pueda estar imitando 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 verse comprometido, o un administrador de sistemas compite lo suficiente. En este nivel, podríamos proteger esas credenciales.
Supongamos que no vamos tan lejos en la protección de esas credenciales, entonces podemos asumir que el sistema está comprometido. En este punto, las credenciales de autenticación se ponen en peligro, 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 el usuario no ingresó nada, su programa necesita iniciarse automáticamente para obtener esas credenciales. Si su programa puede hacerlo sin entrada, entonces también cualquiera que haya revertido diseñó su protocolo de ofuscación / cifrado / servidor.
En este punto, es la limitación de daños, no almacene la contraseña como credenciales de autenticación. Use OAuth, sesiones de cookies, hash salados, etc., todos son solo tokens que representan que en algún momento del pasado demostró que conocía la contraseña. En cualquier buen sistema, estos tokens se pueden revocar, expirar el tiempo y / o intercambiarse periódicamente por un nuevo token durante la sesión activa.
El token (cualquiera que sea su forma) también puede contener información adicional de autenticación de entrada que no sea del usuario, lo que restringe su capacidad para usarlos en otro lugar. Podría, por ejemplo, encapsular su nombre de host y / o dirección IP. Esto hace que sea difícil usar las credenciales en diferentes máquinas ya que imitar estas formas de credenciales requeriría acceso al nivel apropiado de infraestructura de red.
OSX: utiliza el llavero
Windows: use CryptProtectData y CryptUnprotectData
Linux: utilice el llavero de GNOME y KWallet de KDE