Discussion :

[davok]

Bonjour,

Nous sommes en train de développer une application Android qui interagit avec un serveur pour avoir accès à des données situées dans une BDD.

Nous bloquons au niveau de la sécurité.

Lorsque l'utilisateur se connecte et qu'il rentre son mot de passe, comment pouvons-nous crypter celui-ci pour qu'il ne soit pas visible dans la reqûete ? Doit-il vraiment être crypter avant l'envoie du JSON et si oui comment le décrypter au niveau du serveur pour vérifier que celui-ci existe dans la base de données.

Nous avons aussi entendu parlé de token pour plus de sécurité mais nous n'avons pas totalement compris le principe, pour nous le token peut être simplement le login d'utilisateur...

Si vous avez un tuto, un principe de base, des informations sur toute la partie sécurité Android entre l'appli et le serveur, nous sommes preneurs car nous sommes perdus x(

Merci d'avance.

Cordialement,

des étudiants =)

[nicroman]

C'est assez simple en fait:

Pour l'authentification côté serveur:

Mot de passe solution #1: Facile personne ne le connait en clair, sauf l'utilisateur.... Quand l'utilisateur crée un compte, ou bien se login, le mot de passe est immédiatement "hashé" (MD5 généralement) avec du "sel" (salt en anglais) histoire de compliquer la tâche de reverse-hashing. C'est sous forme hachée qu'il est stocké sur le serveur, et encore hachée qu'il est passé sur le réseau. On estime que si les deux "hash" sont identique, le mot de passe entré était le bon.

Mot de passe solution #2: Il est passé en clair. Je n'aime pas cette solution, car si jamais la base de donnée est compromise côté serveur, tous les mots de passe des utilisateurs sont compromis, doivent être changé, et sachant qu'un utilisateur sur deux utilise le même mot de passe partout sur internet.....

Mot de passe solution #3: OAuth2. Cela consiste à passer par un SSO (Google, Facebook ou tout autre provider OAuth2 fonctionnera). Utiliser la connexion existante avec un autre service pour authentifier l'utilisateur. Cette solution est forcément la meilleure sur Android, car l'utilisateur possède quasi obligatoirement un compte google (ne serait-ce que pour accéder à play ).

Dans tous les cas, les communications avec le serveur sont en TLS (https) donc chiffrées et illisibles de l'exterieur.



Une fois que le serveur a authentifié l'utilisateur, il va alors créer un "token".
Ce token contient plusieurs information: une date limite de validité, l'identifiant de l'utilisateur (la valeur interne au serveur, pas le login), et des "limiteurs" d'utilisation (pour éviter que le même token ne puisse être utilisé par quelqu'un d'autre pendant la durée de validité). Le serveur est le seul à savoir comment est formé / chiffré le token. D'ailleurs on peut imaginer des clés de chiffrage multiples et tournantes. Il est donc le seul à pouvoir le lire, récupérer l'identifiant de la personne directement (sans avoir à repasser par un mdp ou du OAuth).

Dans les limiteurs d'utilisation j'aime bien le "session-id" (le client crée un identifiant de session, et passe cet identifiant lors du login, le login retournera un token limité à cette session). Il faudra toutefois que ce "session-id" soit passé au serveur en parallèle à toute requête (cookie, ou header http).
Mais il y a aussi l'adresse IP d'origine le token n'est alors valide que pour une seule adresse IP (pas forcément pratique sur mobile du fait du nombreux changement de réseaux possibles, mais permet de s'affranchir de la nécessité d'envoyer des données additionnelles).


Perso ce que j'utilise est un session-id token....
Quand l'application se lance, elle génère avec un session-id qui est du charabia avec une date, un truc aléatoire, et le nom de l'application... le tout encodé avec une clé publique.
Lors de toute communication avec le serveur elle passe ce session-id (dans les headers des requêtes http).
Lors du login, le serveur vérifie (avec la clé privée que lui seul possède) que la session est bien valide (bien formée et nom de l'application connue et répertoriée et suffisamment récente), le login et le password (sous forme hashée, pas de password en clair dans ma BDD) et renvoit un token pour cette session.
Lors des autres communications, outre le session-id on envoie le token. Le serveur ne fera que vérifier que les sessions-id sont identiques (on a déjà validé le session-id lors du login).
Le serveur répondant avec un token "refreshed" (validité plus grande).
etc...
Quand l'application quitte, elle envoie un "session-delete" au serveur. Le serveur invalide donc cette session, et toute utilisation de token basé sur ce session-id sera alors refusée.

[davok]

Merci beaucoup pour ces solutions détaillées, nous allons étudier ça demain.
On reviendra en cas de questions =)


Edit: Si une petite question tout de suite :p :
Le hashage du mot de passe doit se faire sur le mobile ou dès l'arrivé sur le serveur, le problème que nous nous sommes posés si on crypte le mot de passe directement sur le mobile est comment le serveur va pouvoir checker la correspondance du mot de passe si l'utilisateur créer un compte avec un mobile et se connecte avec un autre ? Les 2 mobiles vont créer une clef différentes pour se connecter.

Merci encore

[nicroman]

Hashage != Chiffrage

Mais on s'en fiche... le hachage est effectué coté client... Le serveur ne recoit que les valeur de hash, stocke les valeurs de hash, et compare les valeurs de hash.
Coté client le hashage s'effectue bien avec une clé... mais clé + algorithme de hash, c'est décidé par l'application, et que l'utilisateur change de téléphone ou non, peu importe.

[fr1man]

Un petit lien intéressant sur le sujet.
https://crackstation.net/hashing-security.htm

Jusqu'à présent, de mon côté, j'envoie les identifiant et mot de passe tels quels (mais avec HTTPS), et c'est le serveur qui les hashe.
D'ailleurs MD5 est à priori fortement déconseillé même avec un sel.

[grunk]

Jusqu'à présent, de mon côté, j'envoie les identifiant et mot de passe tels quels (mais avec HTTPS), et c'est le serveur qui les hashe.
D'ailleurs MD5 est à priori fortement déconseillé même avec un sel.

Que le mot de passe soit envoyé en clair ou hashé ca ne change au final pas grand chose puisque si intercepté , il suffit de le rejouer tel quel pour avoir accès à la ressource protégée.

Pour réellement le protéger il faudra le chiffrer avec une composante temporelle afin que le serveur puisse le déchiffrer via sa clé privé et que si il est rejouer plus tard suite à une interception , la composante temporelle soit invalide.

Mais très clairement une solution encapsulée dans du TLS (https par exemple) de bout en bout assure déjà un niveau de sécurité conséquent puisque (en théorie) on ne peut pas analyser le contenu qui transite.

[fr1man]

@grunk
Je n'ai pas dit le contraire.
J'ai simplement été surpris de cette façon de procéder à savoir que le client hache le mot de passe.
Si j'ai une application web, une application mobile, et un serveur, je préfère déléguer cette tâche au serveur.

[davok]

Merci pour vos réponses.

En ce qui concerne le rafraichissement du token, nous voyons le principe comme ceci :
- Le client mobile s'inscrit ou se connecte.
- Il reçoit en retour un token généré par le serveur.
- Pour chaque requêtes faites au serveur, le token est présent dans le header de celles-ci que le serveur vérifiera ensuite.

Lorsque le token est expiré, il faut donc en généré un nouveau :
- Le client mobile envoie au serveur une demande de rafraichissement de token avec l'ancien token dans le header pour que le serveur puisse vérifier qu'il s'agit bien du client.
- Le serveur renvoie en retour un nouveau token valide..

Et ainsi de suite..

Est-ce correcte ?

Merci

[MasterMbg]

Salut,

Pour réellement le protéger il faudra le chiffrer avec une composante temporelle afin que le serveur puisse le déchiffrer via sa clé privé et que si il est rejouer plus tard suite à une interception , la composante temporelle soit invalide.

@grunk pourrais tu nous en dire un peu plus en partant d'un exemple si possible? Je suis vraiment intéressé par ta façon de faire

Merci d'avance

Christian,

[fr1man]

@davok
Ça me semble pas mal, mais avec ton système, il suffit d'avoir un token pour être perpétuellement authentifié, car il suffit d'un rafraîchissement ?
Tu ne veux pas forcer l'utilisateur à se reauthentifier ?

[grunk]

Salut,

@grunk pourrais tu nous en dire un peu plus en partant d'un exemple si possible? Je suis vraiment intéressé par ta façon de faire

Merci d'avance

Christian,

J'ai pas d'exemple sous la main mais on peut imaginer qu'on ajoute la date en cours à la donnée à chiffrer. Quand le serveur reçoit le message , il le déchiffre et compare la date contenu dans la données avec par exemple la date passée dans l'entête de la trame réseau.

Ça n’empêche techniquement pas une attaque men in the middle si elle est rapide , mais une requête ne pourra pas être rejouer plus tard puisqu'elle deviendra invalide.

Une enveloppe TLS , un chiffrage et une durée de validité pour les requêtes permet quand même d'être relativement sure dans l'échange de données.