Nunca contraseñas de código rígido o claves criptográficas en su programa.
La regla general es: las únicas credenciales que debe almacenar en la máquina de un usuario son las credenciales asociadas con ese usuario , por ejemplo, las credenciales que permiten al usuario iniciar sesión en su cuenta.
No debe almacenar sus credenciales de desarrollador en la máquina del usuario . Eso no es seguro.
Debe asumir que cualquier cosa almacenada en la máquina del usuario es conocida por el usuario, o puede ser aprendida fácilmente por el usuario. (Esta es la suposición correcta: no es difícil hacer ingeniería inversa de un binario de aplicación para aprender cualquier clave o secreto que pueda estar incrustado en él).
Una vez que entiendas este principio general, todo se vuelve fácil. Básicamente, necesita diseñar el resto de su sistema y su protocolo de autenticación para que el software del cliente pueda autenticarse usando solo aquellas credenciales que sean seguras de almacenar en el cliente.
Ejemplo 1. Supongamos que tiene una ID y clave de la aplicación de Facebook, asociadas con su aplicación (es decir, asociadas con su cuenta de desarrollador). ¿Incorpora el ID de la aplicación y la clave en el software de escritorio que envía a los usuarios? ¡No! Absolutamente no. Definitivamente no lo hace, porque eso permitiría a cualquiera de sus usuarios conocer su ID y clave de aplicación y enviar sus propias solicitudes, posiblemente dañando su reputación.
En cambio, encuentras otra manera. Por ejemplo, tal vez configure su propio servidor que tenga el ID y la clave de la aplicación y sea responsable de realizar las solicitudes a la plataforma de Facebook (sujeto a las limitaciones apropiadas y la limitación de velocidad). Entonces, su cliente se conecta a su servidor. Tal vez usted autentique a cada cliente haciendo que cada usuario configure su propia cuenta de usuario en su servidor, que almacene las credenciales de la cuenta en el cliente y que el cliente se autentique usando estas credenciales.
Puede hacer esto totalmente invisible para el usuario, haciendo que la aplicación cliente genere una nueva cuenta de usuario en la primera ejecución (generando sus propias credenciales de inicio de sesión, almacenándolas localmente y enviándolas al servidor). La aplicación cliente puede usar estas credenciales almacenadas para conectarse en el futuro (por ejemplo, sobre SSL) e iniciar sesión automáticamente cada vez que se ejecute la aplicación.
Observe que lo único que se almacena en la máquina de un usuario son las credenciales que permiten iniciar sesión en la cuenta de ese usuario, pero nada que permita iniciar sesión en las cuentas de otras personas, y nada que exponga las claves de la aplicación del desarrollador.
Ejemplo 2. Suponga que escribe una aplicación que necesita acceder a los datos del usuario en su cuenta de Google. ¿Les pide su nombre de usuario y contraseña de Google y los almacena en el almacenamiento local de la aplicación? Podría: eso estaría bien, porque las credenciales del usuario se almacenan en la máquina del usuario. El usuario no tiene incentivos para intentar piratear su propia máquina, porque ya conocen sus propias credenciales.
Aún mejor: use OAuth para autorizar su aplicación. De esta manera, su aplicación almacena un token OAuth en su almacenamiento local de aplicaciones, lo que le permite a su aplicación acceder a la cuenta de Google del usuario. También evita la necesidad de almacenar la contraseña de Google del usuario (que es particularmente sensible) en el almacenamiento local de la aplicación, por lo que reduce el riesgo de compromiso.
Ejemplo 3. Suponga que está escribiendo una aplicación que tiene una base de datos MySQL que se comparte entre todos los usuarios. ¿Toma la base de datos MySQL y la integra en el binario de la aplicación? ¡No! Cualquiera de sus usuarios podría extraer la contraseña y luego obtener acceso directo a su base de datos MySQL.
En su lugar, configura un servicio que proporciona la funcionalidad necesaria. La aplicación cliente se conecta al servicio, se autentica y envía la solicitud al servicio. El servicio puede ejecutar esta solicitud en la base de datos MySQL. La contraseña de MySQL permanece almacenada de forma segura en la máquina del servidor y nunca es accesible en la máquina de ningún usuario. El servidor puede imponer cualquier restricción o control de acceso que desee.
Esto requiere que su aplicación cliente pueda autenticarse en el servicio. Una forma de hacerlo es hacer que la aplicación cliente cree una nueva cuenta en el servicio en la primera ejecución, genere una credencial de autenticación aleatoria e inicie sesión automáticamente en el servicio cada vez que lo haga. Podría usar SSL con una contraseña aleatoria, o incluso mejor, usar algo como SSL con un certificado de cliente único para cada cliente.
La otra regla es: no se ingresan las credenciales de código en el programa. Si está almacenando credenciales en la máquina del usuario, guárdelas en alguna ubicación privada: tal vez un archivo de configuración o en un directorio, preferiblemente uno que solo sea legible por esta aplicación particular o este usuario particular (no un archivo legible en todo el mundo) / p>