IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement Discussion :

Principe d'authentification serveur


Sujet :

Développement

  1. #1
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Par défaut Principe d'authentification serveur
    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:
    1. Le client contacte le serveur d'applications (APP)
    2. APP demande au serveur d'authentification (AUTH) si le client à les droits
    3. 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
    4. APP envoie au client un requête d'authentification en lui envoyant le numéro généré aléatoirement
    5. 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é
    6. APP envoie à AUTH le numéro encodé
    7. 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
    8. Si la comparaison est vraie, AUTH génère un token, le sauvegarde dans la base de données et l'envoie à APP
    9. APP envoie au client le token
    10. 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!

  2. #2
    Membre Expert
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Par défaut
    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

  3. #3
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Par défaut
    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.

  4. #4
    Membre Expert
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Par défaut
    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é.

  5. #5
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Par défaut
    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!

  6. #6
    Membre Expert
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Par défaut
    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

  7. #7
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Principals pour authentification jaas
    Par franchouze dans le forum Glassfish et Payara
    Réponses: 4
    Dernier message: 03/11/2009, 20h10
  2. [VB.NET] : Envoi de mail + authentification serveur
    Par forsay1 dans le forum VB.NET
    Réponses: 9
    Dernier message: 09/05/2009, 15h10
  3. authentification serveur HTTP
    Par berok37 dans le forum Apache
    Réponses: 4
    Dernier message: 17/06/2008, 20h52
  4. authentification serveur lié pour un classeur Excel
    Par dmascara dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 20/04/2007, 14h23
  5. [Continuum] projet multi-modules +authentification serveur
    Par rseM2 dans le forum Intégration Continue
    Réponses: 13
    Dernier message: 15/02/2007, 17h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo