Carnet Wiki

AuthentificationDansSpip

Version 19 — il y a 1 mois — bfrit

Authentification et protection de l’interface privée (ecrire/)

Il y a plusieurs méthodes de protection exploitées dans Spip :

  • Une prise en charge directement par Spip
  • Une méthode gérée par Apache
  • Depuis SPIP 2.0, la possibilité de fournir d’autres méthodes d’authentification (LDAP, OpenID, etc.) par le biais de plugins. (l’authentification LDAP existe depuis au moins la 1.6, les plugins ne font que la faciliter)...

Authentification SPIP

Pour vérifier l’identité de l’utilisateur, SPIP utilise un mécanisme en 2 étapes :

  1. Vérification du login. On vérifie que celui-ci existe dans la table des utilisateurs. Si c’est le cas, on passe à la seconde étape.
  2. Validation du mot de passe : Celui-ci n’est pas stocké en clair dans la base MySQL. Seule une version cryptée, que nous appellerons empreinte numérique, est sauvegardée. Il est donc impossible de retrouver directement le mot de passe de quelqu’un, car l’algorithme de cryptage utilisé (hash MD5) ne possède actuellement pas de méthode de décryptage.
  • Lorsque Javascript est désactivé, le mot de passe est envoyé en clair puis crypté sur le serveur afin d’être comparé à l’empreinte numérique de l’utilisateur.
  • Si Javascript est disponible, le navigateur va encrypter directement le login, afin de n’envoyer que la version codée qui sera directement comparée à l’empreinte numérique. On est dans une coepté par un tiers. C’est ce que nous allons voir plus en détail par la suite.

Remarque technique :
Comment s’assure-t-on qu’un tiers, interceptant une version cryptée du mot de passe avec le login en clair ne puisse pas s’authentifier directement ensuite en réenvoyant les même infos ?

-  en fait, le mot de passe n’est pas encrypté tout seul. 2 variables supplémentaires interviennent afin de fiabiliser le mécanisme d’authentification : alea_actuel et alea_futur. Ces variables font parties des informations d’un utilisateur stockées dans la table spip_auteurs. L’empreinte numérique est initialement égale à MD5(alea_actuel+password).

-  le formulaire d’authentification envoie le login, une version encryptée MD5(alea_actuel+password) (variable A), ainsi qu’une version encryptée MD5(alea_futur+password) (variable B) ou Sha256(alea_actuel+password) si version >= 2.1 .

-  Ensuite A est comparé à l’empreinte numérique de login, stockée dans le champ « password » de la table spip_auteurs.
— Si cela ne correspond pas, le mot de passe n’est pas bon.
— Dans le cas contraire, l’empreinte numérique de l’utilisateur est remplacée par B ; Dans la table spip_auteurs, la valeur du champ alea_actuel est effacé, pour être remplacé par celle du champ alea_futur, qui lui-même est remplacé par une nouvelle chaîne créée aléatoirement.

-  Grâce à ce mécanisme, le mot de passe n’est jamais envoyé en clair sur le réseau, seul circulent ses empreintes numériques actuelles et futures.

Authentification Apache

Ici nous parlons de deux variables du fichiers mes_options.php3 (à ne pas confondre avec le fichier mes_fonctions.php3) :
-  $ignore_remote_user
-  $ignore_auth_http

Nous avons d’abord travailler sur la variable $ignore_remote_user

-  $ignore_remote_user = true ;
La méthode gérée par Apache contrôle l’accès aux répertoires. C’est la méthode des fameux fichiers .htaccess. On place un fichier .htaccess avec les bonnes instructions (cf : http://httpd.apache.org/docs/howto/htaccess.html) dans le répertoire dont on veut contrôler l’accès, par exemple :

«  »

[->AuthType] Basic
[->AuthName] "Le message à afficher dans le titre de la boite de dialogue"
[->AuthUserFile] .htpasswd
require valid-user

« »

ddddd

La requête d’un fichier contenu dans ce répertoire ou dans n’importe lequel de ses sous répertoires est alors soumis à la présentation d’un couple login/password valide que doit fournir le navigateur client.
La première fois que votre navigateur demande un tel fichier, Apache répond par un message 401. Le navigateur ouvre alors une boite de dialogue vous demandant de fournir et nom et mot de passe. Puis il renvoie la requête au serveur avec cette fois le couple login/password que vous avez fourni. Apache vérifie que le nom et le mot de passe existe bien dans le fichier .htpasswd. Si c’est le cas il renvoie le fichier demandé.
Lorsque le navigateur demandera à nouveau un fichier depuis ce répertoire, il enverra le couple login/password automatiquement. Si vous fermez le navigateur, ce couple login/password sera perdu.

Spip sait travailler avec cette méthode et même il va vous aider.
Quand vous vous êtes identifié en voulant accéder à un fichier d’un répertoire protégé, Spip récupère le couple login/password par des variables PHP. Il peut alors vérifier les droits Spip qui sont les vôtres (administrateurs, rédacteurs, visiteurs) et donc appliquer ces droits dans les fichiers de l’interface privée.
En prime, Spip est capable de produire automatiquement le fichier .htpasswd. Pour ce faire, il faut activer la fonction dans l’interface d’administration : « SPIP doit-il créer les fichiers spéciaux .htpasswd et .htpasswd-admin dans le répertoire ecrire/data/ ? » (dernier paragraphe dans la page fonctions avancées de la configuration du site). En activant cette fonction, Spip crée deux fichiers : .htpasswd qui contient les couples login/password de tous les administrateurs et rédacteurs du site, .htpasswd-admin qui ne contient que ceux des administrateurs.

Conclusion
Cette méthode a l’inconvénient de présenter la fenêtre de dialogue du navigateur comme méthode d’authentification. C’est plus ou moins élégant selon les navigateurs, mais surtout non personnalisable à la charte graphique du site : en bref ça fait moins « pro »...
Par contre ça présente le gros avantage de pouvoir contrôler l’accès à tous les répertoires du site que l’on veut à partir d’une seule authentification.

-  $ignore_remote_user = false ;
La méthode gérée par Spip contrôle l’accès aux fichiers. Aux fichiers php évidemment. Quand vous chargez un fichier du répertoire ecrire/, Spip vous demande la première fois de vous identifier (couple login/password). Spip vous envoie alors un cookie de session qui évitera de vous poser la question à chaque fois.

Remarques
Spip utilisera la méthode Apache ci-dessus si vous refusez le cookie.
Par ailleurs, vous pouvez à la fois utiliser la méthode standard de Spip tout en demandant à Spip [1]de fabriquer les fichiers .htpasswd et .htpasswd-admin pour gérer l’accès à des répertoires non contrôlés par Spip : statistiques, fichiers à accès restreints, etc. Cependant vous devrez fournir le couple login/password même si vous vous êtes déjà identifié par la méthode Spip : en effet celle-ci n’est pas extensible à la méthode Apache.


Méthodes alternatives d’authentification

Depuis SPIP 2., les plugins peuvent fournir des méthodes d’authentification à eux, sur lesquelles SPIP va se brancher pour les différentes actions qui ont trait à l’authentification. Pour une méthode nommée xxx, ces différentes actions correspondent aux fonctions suivantes :

  • auth_xxx_dist($login, $pass, $serveur) définie dans auth/xxx.php : Il s’agit de la fonction principale d’authentification.
  • auth_xxx_formulaire_login($flux) : Pipeline pour insérer du contenu dans le formulaire de login.
  • auth_xxx_retrouver_login($login, $serveur) : Retrouver le login interne lié à une info de login saisie.
  • auth_xxx_informer_login($infos, $row, $serveur)
  • auth_xxx_terminer_identifier_login($login, $serveur)
  • auth_xxx_autoriser_modifier_login($serveur) : Tester le droit à modifier le login d’authentification.
  • auth_xxx_autoriser_modifier_pass($serveur) : Tester le droit à modifier le mot de passe.
  • auth_xxx_verifier_login($new_login, $id_auteur, $serveur) : Vérifier la validité d’un nouveau login candidat à la modification
  • auth_xxx_verifier_pass($login, $new_pass, $id_auteur, $serveur) : Vérifier la validité d’un mot de passe candidat à la modification.
  • auth_xxx_modifier_login($new_login, $id_auteur, $serveur) : Modifier le login d’un auteur.
  • auth_xxx_modifier_pass($login, $new_pass , $new_Stan33 @, $id_auteur, $serveur) : Modifier le mot de passe d’un auteur.
  • auth_xxx_synchroniser_distant($id_auteur, $champs, $options, $serveur) : Synchroniser un compte sur une base distante lorsque des modifications sont faites dans la base auteurs.
  • auth_xxx_url_retour_login($login, $redirect, $serveur) : Fournir une URL de retour après login par un SSO pour finir l’authentification.

Par ailleurs, le plugin doit enregistrer sa méthode d’authentification au travers du fichier d’options de la façon suivante :
$GLOBALS['liste_des_authentifications']['xxx'] = 'xxx';

Conclusion
Si le site est du pur Spip, les méthodes Spip (y compris alternatives) sont la façon la plus propre : authentification dans une page php aux couleurs du site. Si par contre il y a d’autres répertoires à protéger au-delà du répertoire d’administration ecrire/, l’avantage de la méthode Apache réside dans le fait que le visiteur n’aura pas à s’identifier deux fois, une fois dans Spip et une fois dans la fenêtre du navigateur...

Remarque complémentaire : la méthode Apache fait transiter le mot de passe en « clair » sur le réseau, ce qui introduit un risque de se le faire intercepter. Pour essayer d’améliorer la sécurité de la connexion, la méthode SPIP passe une empreinte cryptographique du mot de passe : il est très difficile de « cracker » le mot de passe original à partir de cette empreinte.