Principe d'authentification serveur

**darkman19320** · 09/02/2019, 11h46

Bonjour tout le monde,

Je suis en train de faire une application client/serveur. Chaque utilisateurs pourra avoir accès ou non à certaines fonctionnalités suivant leur droits.
L'authentification de l'utilisateur pourra soit durer jusqu'à la fermeture de l'application soit durer X jours/mois/années.
Jusque là, une application classique.

Seulement voila, je ne suis pas certain à 100% de bien comprendre comment le principe d'authentification fonctionne.

Je pense que séparer l'authentification du (des) serveur(s) d'application est une bonne idée.
Est-ce que je me trompe?

J'ai fait diverses recherches sur les modes d'authentifications et je pense utiliser les token comme base.

Voici la conclusion de mes recherches:

Le client contacte le serveur d'applications (APP)
APP demande au serveur d'authentification (AUTH) si le client à les droits
AUTH regarde dans sa base de données et répond que non et envoie un numéro sur Xbits généré aléatoirement
APP envoie au client un requête d'authentification en lui envoyant le numéro généré aléatoirement
Le client affiche une page d'authentification. L'utilisateur met ses identifiant et mot de passe. Le mot de passe est hashé avec un algo style SHA-256 (si je me trompe pas). Encodage du numéro aléatoire avec le mot de passe hashé
APP envoie à AUTH le numéro encodé
AUTH prend récupère de la base de données le mot de passe hashé de l'utilisateur, encode le numéro généré précédemment avec le mot de passe hashé et compare avec le numéro encodé reçu
Si la comparaison est vraie, AUTH génère un token, le sauvegarde dans la base de données et l'envoie à APP
APP envoie au client le token
Le client sauvegarde le token (cookie ou autre). A chaque requète du client, il donne le token à APP. APP demande à AUTH si le token est encore valide.

Est-ce que c'est suffisamment sécurisé?
Est-ce que je me prends pas un peu trop la tête?
Est-ce qu'ajouter l'ip du client pour générer le token est une bonne idée/utile? (j'imagine si le token se fait intercepter, il y aurait potentiellement une faille si on ne teste pas d'où on se connecte non?)

Voila toutes mes interrogations (pour le moment...).

Merci d'avance!

**fredoche** · 11/02/2019, 13h06

Bonjour
Une remarque sur le fait d'associer le token à une adresse ip. Par exemple à mon domicile j'utilise une connexion load-balancé entre 3 accès et par défaut toutes mes requêtes sortent indifféremment par l'une des 3 portes.
Avec ton système je ne pourrais jamais être authentifié.
C'est pas d'un usage très courant mais je ne vois pas pourquoi une adresse IP doit rendre compte d'une identité. Je ne serais pas surpris que tu aies d'autres cas qui présente le même problème.
A mon sens, si tu es sur un protocole chiffré type HTTPS, il n'y a aucune raison que le token soit divulgué, sauf à accéder à la machine du client mais ce n'est plus alors une interception

**darkman19320** · 11/02/2019, 18h23

Bonjour et merci pour ta réponse.

Effectivement je n'avais pas pensé à ce cas de figure. Si je prends l'adresse MAC est-ce que ca serait plus judicieux. L'application que je développe sera installée dans des hôpitaux. Du coup la sécurité demandée est assez élevée.

**fredoche** · 11/02/2019, 19h05

Je ne sais pas, en quoi une adresse physique est un élément de sécurité ?
Et de plus avec tout paquet IP ayant été routé tu perdras l'adresse MAC d'origine. Il en va de même pour certains bridges, des APs wifi.

Dans un hôpital, si tu fonctionne sur l'intranet, tes machines clientes auront probablement des IP affectées par DHCP. Selon la durée du bail, et la politique d'adressage, les adresses IP peuvent changer assez vite.

je ne sais pas quel type d'appli tu fais, mais sur le principe, tu tends une clef temporaire à quelqu'un de main à main. Clef qui si elle n'est pas interceptée, il est le seul à posséder. Après s'il se la fait voler c'est autre chose, mais ce n'est plus de ton ressort, et quelqu'un qui vole cette clef, peut aussi voler l'adresse puisqu'il aura compromis la machine.

Mais si tu es sur des applis web, il y a bien d'autres failles de sécurité à surveiller que ces adresses et clefs, tout ce qui concerne le XSS et le CSRF permettrait d'utiliser la clef et l'adresse de la machine et serait des failles de sécurité.

**darkman19320** · 12/02/2019, 00h08

Merci pour toutes ces précisions.

J'aurais les deux cas, une appli web et une appli sur l'intranet. Dans les deux cas, je comprends bien l'adresse quelque soit ne soit pas utile.
Mais du coup, comment faire pour éviter (au maximum) de se faire intercepter un paquet? Le HTTPS suffit-il? Si c'est le cas, ça me va très bien!

**fredoche** · 12/02/2019, 01h44

Oui cela doit suffire si les librairies sont bien à jour selon l'environnement système utilisé.
Après il y a bien des systèmes de proxy "menteur" et transparent qui peuvent substituer leurs certificats au tien dans une entreprise, et donc intercepter toutes communications, mais ça tu n'y peux pas grand chose, cela concerne les employés de ces entreprises.

Il y a aussi le port mirroring qui permet de répliquer tout ce qui passe sur un élément type switch. J'imagine que par ce biais tu peux décoder à posteriori les échanges https, dans la mesure où tu vois même les premiers échanges servant à la création de la connexion https, dont les échanges de clefs

**darkman19320** · 12/02/2019, 11h40

Merci beaucoup pour toutes ces informations.

Je pense que je vais partir sur le principe d'utiliser les token et HTTPS et que si ce n'est pas suffisant, j'améliorerai au fur et à mesure. Je pense également me faire conseiller par des organismes spécialisés dans les applications médicales.