Bonsoir, j'ai implémenté (une fois de plus) pour un client un processus
d'authentification utilisation des sessions.
Indépendament des failles possibles ("vols" de sessions par un
malfaisant) et bien que je n'utilise que des sessions par cookies (pas de
PHPID) se pose le problème suivant :
Habituellement je passe d'abord par une authentification apache
(.htaccess) puis ensuite un écran de login de l'application (et c'est ici
que les sessions entrent en oeuvre).
Ce client trouvait assez casse-pieds de devoir s'authentifier deux fois
(un premier pass global pour tous les utilisateurs, puis une
authentification appli propre à chacun), j'ai donc supprimé
l'authentification de premier niveau (.htaccess). J'ai pris soin
d'intégrer quelques conseils judicieux donnés ici (vérifier à chaque
accès que l'IP n'a pas changé) mais bon...
Ca ne le satisfait toujours pas, il trouve encore casse pied de devoir
s'authentifier à chaque fois.
La solution la plus simple serait d'utiliser un cookie disant "cet
utilisateur a été authentifié, son accès est donc valide jusqu'à telle
date" mais je trouve ça franchement insécure.
Je voudrais donc savoir quelles autres solutions sont à ma disposition ?
Ne serait-il pas possible que chaque utilisateur dispose (sur son poste,
en fait sur son navigateur) d'un certificat me permettant de m'assurer
qu'il s'agit bien d'un utilisateur duement authentifié ? Un peu sur le
principe de ssh avec ses clés privées/publiques mais sans la "pass
phrase"...
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour
autant transformer l'appli en un véritable gruyère ?
Si vous avez un début de solution, ou des liens, ou je sais pas quoi, je
prends !!!
Dernière précision : les adresses IP des utilisateurs habilités à
utiliser l'appli ne sont pas connues (ip dynamiques ou ip gateway) je ne
peux donc pas compter la dessus pour identifier qui que ce soit.
Jean-Marc Molina said the following on 25/09/2003 10:32:
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle a été corrigée. Oui je sais c'est pas rassurant mais bon...
et quand le logiciel de paiement sécurisé en passant par une banque n'est pas capable d'envoyer des données par SSL lorsqu'il retourne les infos d'un paiement ?
Jean-Marc Molina said the following on 25/09/2003 10:32:
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit
hacker décide de s'en prendre à votre site ou votre application.
Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle
a été corrigée. Oui je sais c'est pas rassurant mais bon...
et quand le logiciel de paiement sécurisé en passant par une banque
n'est pas capable d'envoyer des données par SSL lorsqu'il retourne les
infos d'un paiement ?
Jean-Marc Molina said the following on 25/09/2003 10:32:
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle a été corrigée. Oui je sais c'est pas rassurant mais bon...
et quand le logiciel de paiement sécurisé en passant par une banque n'est pas capable d'envoyer des données par SSL lorsqu'il retourne les infos d'un paiement ?