Issues #5059 #4927 #3824 et #2109 : on reforme la logique du login #5062

plus de hashage+sel cote client, car les algos js sont penibles a gerer, voire buggués, et https est maintenant un standard de securite
cote serveur on utilise les fonction modernes de PHP pour la gestion des mots de passe (sel, poivre, hashage et verification)

Directement inspiré du plugin chiffrer de g0uz https://git.spip.net/spip-contrib-extensions/chiffrer avec en plus:

utilisation de sodium qui est natif avec PHP depuis 7.2 https://php.watch/articles/modern-php-encryption-decryption-sodium
la gestion de plusieurs cles, dont aussi le secret_du_site qui n'est plus en meta
une passe de modernisation sur les cles d'action egalement

C'est a priori bon a tester (et on fera un merge plutot qu'un rebase amha)

J'ai ajouté la prise en charge des cles lors de l'installation pour notamment gérer le cas où on a perdu le fichier config/cle.php et permettre de le restaurer en demandant à un webmestre existant de faire la procedure d'install (avec son mot de passe).

A noter que j'ai également modifié spip-cli pour la commande de modif des mots de passe pour qu'elle puisse marcher avec toutes les versions de SPIP
2f86ad5c76

Enfin, je pense qu'il faut ajouter une commande spip-cli pour forcer un raz des authentifications, ce qui revient à

supprimer le fichier config/cles.php
vider le champ backup_cles sur tous les auteurs de spip_auteurs

C'est un cas extrême qui invalide tous les mots de passe en base, mais qui peut être utile si on a perdu les clé et que tous les webmestres ont perdu leur mot de passe...

Sur une install neuve, on a la creation des cles a l'etape 3B, lorsqu'on créé le premier webmestre, et il a automatiquement un backup des cles qui lui est assigné. On a donc immédiatement un webmestre avec une copie chiffrée des clés.

En prévision de #5056 je vais peut être déplacer ecrire/chiffrer/* dans ecrire/src/Chiffrer/ sous le namespace Spip\Chiffrer directement (au lieu de Spip\Core\Chiffrer)

J’pense qu’on est bon là dessus.

Afin de prévenir la compromission du SPIP (RCE) lors d'un accès non autorisé à la DB il est nécessaire de protéger certaines données, notamment le champ cooki_oubli (utilisé pour les "token utilisateurs") :

Proposition :

158feda047/ecrire/action/inscrire_auteur.php (L354)

sql_updateq('spip_auteurs', ['cookie_oubli' => chiffrer($jeton)], 'id_auteur=' . intval($id_auteur));

158feda047/ecrire/action/inscrire_auteur.php (L373)

$desc = sql_fetsel('*', 'spip_auteurs', 'cookie_oubli=' . sql_quote(chiffrer($jeton), '', 'string'));

L'attaque suivante n'est plus réalisable :

identifier une injection SQL en lecture
générer le token pour un webmestre via le formulaire de perte de mot de passe
lire le token en DB avec l'injection SQL
s'authentifier en tant que webmetre et installer un plugin pour exectuion de code PHP

J’ai réarrangé les commits et squashé / fixup certains pour en diminuer pas mal le nombre. La nouvelle PR est là #5064

Issues #5059 #4927 #3824 et #2109 : on reforme la logique du login #5062

Reviewers