Je suis en train de développer une application où l'utilisateur doit se connecter pour effectuer des opérations ... mais surtout sur Android combiné ppl utiliser "me garder connecté" ... et dans ce cas, j'aurai pour maintenir la valeur du nom d'utilisateur et du mot de passe dans mon application .. devrais-je utiliser les préférences, ou SQLite Db ou y a-t-il autre chose et comment puis-je le sécuriser? Aide Plz ... Merci d'avance ..
Oui, c'est délicat sur Android. Vous ne voulez pas stocker le mot de passe en texte brut dans les préférences, car toute personne possédant un appareil enraciné affichera essentiellement son mot de passe dans le monde. D'un autre côté, vous ne pouvez pas utiliser un mot de passe crypté, car vous devrez stocker votre clé de cryptage/décryptage quelque part sur l'appareil, là encore sensible à l'attaque racine.
Une solution que j'ai utilisée il y a quelque temps est que le serveur génère un "ticket" qu'il renvoie à l'appareil, ce qui est bon pendant un certain temps. Ce ticket est utilisé par l'appareil pour toutes les communications, en utilisant bien sûr SSL afin que les gens ne puissent pas voler votre ticket. De cette façon, l'utilisateur authentifie une fois son mot de passe sur le serveur, le serveur renvoie un ticket expirant et le mot de passe n'est jamais stocké nulle part sur l'appareil.
Plusieurs mécanismes d'authentification à trois pattes, comme OpenID, Facebook, et même les API Google, utilisent ce mécanisme. Les inconvénients sont que de temps en temps, lorsque le ticket expire, l'utilisateur doit se reconnecter.
En fin de compte, cela dépend de la sécurité de votre application. Si c'est simplement pour distinguer les utilisateurs et qu'aucune information super secrète n'est stockée comme les comptes bancaires ou les groupes sanguins, alors peut-être que sauvegarder le pwd en texte brut sur l'appareil est très bien :)
Bonne chance, quelle que soit la méthode que vous décidez, elle est la mieux adaptée à votre situation particulière!
Edit: je dois noter que cette technique transfère la responsabilité de la sécurité au serveur - vous voudrez utiliser des hachages salés pour la comparaison des mots de passe sur le serveur, une idée que vous verrez dans certains des autres commentaires de cette question. Cela empêche le mot de passe en clair d'apparaître n'importe où, sauf la vue EditText sur l'appareil, la communication SSL avec le serveur et le serveur RAM pendant qu'il salit et hache le mot de passe. Il n'est jamais stocké sur le disque, ce qui est une bonne chose (tm).
Comme d'autres l'ont dit, il n'y a pas de moyen sûr de stocker un mot de passe dans Android qui protège complètement les données. Le hachage/chiffrement du mot de passe est une excellente idée mais tout ce qu'il fera est de ralentir le "cracker" ".
Cela dit, voici ce que j'ai fait:
1) J'ai utilisé ceci simplecryto.Java
class qui prend une graine et un texte et les chiffre. 2) J'ai utilisé SharedPreferences
en mode privé qui protège le fichier enregistré sur les appareils non rootés. 3) La graine que j'ai utilisée pour simplecryto est un tableau d'octets qui est un peu plus difficile à trouver par les décompilateurs qu'une chaîne.
Ma candidature a été récemment examinée par un groupe de sécurité "chapeau blanc" embauché par mon entreprise. Ils ont signalé ce problème et indiqué que je devrais utiliser OAUTH mais ils l'ont également répertorié comme un problème à faible risque, ce qui signifie qu'il n'est pas génial, mais pas assez mauvais pour empêcher la publication.
N'oubliez pas que le "cracker" devrait avoir un accès physique à l'appareil ET l'enraciner ET se soucier suffisamment pour trouver la graine.
Si vous vous souciez vraiment de la sécurité, ne disposez pas d'une option "me garder connecté".
À tout le moins, stockez-le dans SharedPreferences
(mode privé) et n'oubliez pas de hachage le mot de passe. Bien que cela ne fasse pas vraiment de différence avec un utilisateur malveillant (ou un appareil rooté), c'est quelque chose.
Le moyen le plus sûr de le faire sans compromettre la sécurité consiste à utiliser les préférences partagées pour stocker UNIQUEMENT le nom d'utilisateur de la dernière personne à se connecter.
De plus, dans votre tableau d'utilisateurs, introduisez une colonne qui contient un booléen numérique (1 ou 0) pour indiquer si la personne a coché la personne cochée ou non.
Lors du lancement de votre application, obtenez le nom d'utilisateur à l'aide de la fonction getSharedPreferences()
et utilisez-le pour interroger votre base de données hébergée pour voir si la colonne signée est soit 1 ou 0, où 1 indique que la personne a coché la case "se souvenir de moi".
//encode password
pass_Word_et = (EditText) v.findViewById(R.id.password_et);
String pwd = pass_Word_et.getText().toString();
byte[] data = new byte[0];
try {
data = pwd.getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
String base64 = Base64.encodeToString(data, Base64.DEFAULT);
hbha_pref_helper.saveStringValue("pass_Word", base64);
//decode password
String base64=hbha_pref_helper.getStringValue("pass_Word");
byte[] data = Base64.decode(base64, Base64.DEFAULT);
String decrypt_pwd="";
try {
decrypt_pwd = new String(data, "UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
L'utilisation de NDK pour le chiffrement et le déchiffrement ainsi que la définition de la variable de clé de chaîne là-bas au lieu de l'enregistrer dans les préférences partagées ou de la définir dans la chaîne xml aiderait à empêcher le vol de clé secrète contre la plupart des script kiddies. Le texte chiffré résultant serait ensuite stocké dans les préférences partagées. Ce lien peut aider à propos de l'exemple de code