Co-authored-by: JamesRezo <james@rezo.net>
Reviewed-on: https://git.spip.net/spip/spip/pulls/5074


Co-authored-by: JamesRezo <jamesrezo@noreply.git.spip.net>
Co-committed-by: JamesRezo <jamesrezo@noreply.git.spip.net>

[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

Fix #5069 : quitter la fonction qui gère les variantes de critères de date parce qu'il n'y aurait pas de déclaration dans l'API objet ne doit se faire QUE quand il n'y a PAS de nom de champ directement donné dans le critère lui-même. S'il y a annee_nomprecis, mois_nomprecis, ça doit marcher même sans déclaration.

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

Robustesse des migrations : on ne genere pas le secret_des_auth tant qu'on n'est pas en mesure de faire un backup des cles dans la foulee :
- il faut avoir le champ backup_cles en base (donc avoir fait la migration de base)
- il faut etre sur le login d'un webmestre (donc sur son login *apres* migration de la base) => faut il invalider la session du webmestre qui upgrade pour le forcer a se reconnecter ?
Le but est d'eviter de generer une cle et de commencer a chiffrer les password des utilisateurs alors qu'aucun webmestre n'a encore de backup, ce qui reviendrait a perdre les pass de tous ces utilisateurs si on perd le fichier cles.php

- la clé secret_du_site est partagée entre le disque et la base de données. Il faut les 2 pour le calculer (la clé secret_du_site, et la meta secret_du_site).
- Si on demande à chiffrer avec autre chose qu’une clé de longueur adaptée (ie: générée par Chiffrement::keygen()), tel qu’un mot de passe, alors on passe dans sodium_crypto_pwhash(),
qui est la fonction adaptée à ce cas, mais le coût est très élevé dans ce cas (temps / mémoire, même au minimum possible)
- On s’arrange donc pour que le secret_du_site obtenu soit effectivement de la taille adaptée à la clé de chiffrement.

Suite de 23994e0b1 : Ne pas mettre de jeton d’url directement en bdd (cas de l’inscription d’auteur ou du changement de mot de passe)

On chiffre le jeton en base, mais on permet 2 choses

- Pouvoir retrouver le jeton actuellement utilisé sur un auteur (déchiffrage possible) (Rastapopoulos)
- On limite le nombre de déchiffrages à effectuer en ayant une partie publique du jeton en bdd, qui
sert à filtrer les auteurs dont on veut vérifier les jetons (a priori 1 seul auteur à vérifier)

Introduction d’une fonction auteur_lire_jeton($id_auteur, $autoInit = false), qui lit un jeton
sans écraser le précédent utilisé (ce que fait auteur_attribuer_jeton())

Notons que ces histoires de jeton mériteraient quelques améliorations

- permettre l’expiration des jetons
- permettre plusieurs jetons pour un même auteur directement

Ne pas mettre de jeton d’url directement en bdd (cas de l’inscription d’auteur ou du changement de mot de passe) : on le hash avant (g0uZ)

- Utiliser sodium_pad et sodium_unpad sur le message à chiffrer
- Hacher un password en sha256 dans le chiffrement s’il sert comme clé.
C’est un compromis suffisant.

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

- il faut creer une cle des auth si besoin
- on utilise la fonction auth_spip_modifier_pass() pour changer le pass du webmestre que l'on cree
- si on a perdu le fichier config/cle.php on demande a ce que l'installation se fasse par un webmestre qui a un backup des cles, avec son mot de passe actuel - et on restaure les cles a l'installation

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

Utiliser hash_hmac et hash_equals pour calculer et verifier les jetons d'action - c'est un compromis entre rapidite et securite car utiliser les fonction hasher() et verifier() de Spip\Core\Chiffrer apporterait plus de secu sur ces hash, mais avec un prix performance important (~200ms pour calculer un hash et on peut en avoir N dans une page qui contient N formulaires)
On rappelle que la securite des actions ne doit jamais reposer sur ces hash mais sur un appel a autoriser() pour verifier que l'auteur a bien le droit de faire l'action

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

Upgrade de base pour ajouter un champ `backup_cles` sur spip_auteurs qui
permet aux webmestres de conserver une copie des cles

Le secret_du_site est fourni via SpipCles et plus via spip_meta, il est
supprime de la base (on le reinit au passage, mais c'est pas tres grave)

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

Etre tres prudent sur la generation d'un nouveau secret_des_auth : cela ne peut avoir lieu que si on a plus aucun backup d'aucun webmestre
On ajoute une fonction auth_spip_initialiser_secret() en charge de ça qui fait toutes les verif, et on ajoute des logs circonstancies pour aider les webmestres perdus au cas ou

Inutile de sauver les cles, c'est fait automatiquement si une nouvelle cle est generee

les différentes fonctionnalités. C’est mieux structuré.

- Chiffrement gère chiffrer() / dechiffrer() / keygen() (génération d’une nouvelle clé)
en s’appuyant sur Sodium, toujours présent dans PHP depuis PHP 7.2.
On utilise une chifferement symétrique (comme avec openssl précédement),
mais le code est simplifié car libsodium gère l’authentification du message et son salage.

- Password gère verifier() et hacher() en utilisant password_hash donc,
mais en retirant l’option 'salt' qui n’est plus utilisé par PHP > 8,
et effectivement il vaut mieux ne pas le renseigner (PHP gère un salt tournant
tout seul comme un grand). On s’en sert pour régénerer notre password haché en bdd.

- Cles est un conteneur de clés (tableau nom => clé)

- SpipClés gère les clés SPIP et utilisant Cles. Des fonctions backup() et restore() permettent de lire un backup chiffré

J’ai mis l’attribut `#[\SensitiveParameter]` sur différents paramètres en passant,
il devrait être actif à partir de PHP 8.2 pour dire de ne pas afficher la valeur
dans les affichages de backtrace() par exemple, afin de ne pas divulguer
malencontreusement certaines infos en debug.

Également (Cerdic)

- Sodium exige une cle de chiffrement exactement de la bonne longueur : adapter la cle fournir si besoin (cas du chiffrement du backup des cles avec le pass du user)
- La regeneration des cles ne peut se faire que cle par cle : si on a perdu le fichier des cles, c'est OK de regenerer un secret_du_site a la volee pour pouvoir afficher un formulaire de login par exemple, mais on ne doit surtout pas regenerer un secret_des_auth qui invaliderait tous les mots de passe
- Permettre d'avoir plusieurs instances de SpipCles avec des fichiers de cle differents. Peut etre utile pout les tests unitaires, ou pour faire de l'auth multi-sites (on cherche l'auteur dans plusieurs bases SPIP, chacune associee a un fichier de cle different)

cerdic a rédigé 3 years ago et marcimat a validé 3 years ago

- plus de hashage+sel cote client, car les algos js sont penibles a gerer 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)
Encore une fois directement inspire du plugin chiffrer de g0uz https://git.spip.net/spip-contrib-extensions/chiffrer

La classe Spip\Core\Chiffrer se charge de la gestion des cles secrètes (initialiser, lire, ecrire, sauvegarder, restaurer, chiffrer, dechiffrer et verifier le mot de passe d'un auteur)
Directement insipiré du plugin Chiffrer de g0uZ https://git.spip.net/spip-contrib-extensions/chiffrer

c’est qu’on est dans la langue en cours.

Torsten Willmann a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ public] Mise a jour du bilan depuis https://trad.spip.net

Torsten Willmann a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

Torsten Willmann a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ spip] Mise a jour du bilan depuis https://trad.spip.net

Fix #5067 : ne pas se rabattre sur les urls pages si un type d'url a été demandé explicitement (appel depuis urls_transition_retrouver_anciennes_url_propres()) notamment

[Salvatore] [source:ecrire/lang/ ecrire] Mise a jour du bilan depuis https://trad.spip.net

Cela indique une icone alternative à utiliser si jamais on ne retrouve pas
l'image.

De même `http_style_background()` peut recevoir un dernier argument
`$alternative`.

On se sert de ces alternatives dans `icone_base()` et dans `debut_cadre()`.
`icone_horizontale`).

Icone par @erational

Fix spip-contrib-extensions/champs_extras_interface#5

On utilise `include list` et `exclude list` en anglais,
et `liste d’inclusion` et `liste d’exclusion` en français.

Ricardo Porto a rédigé 3 years ago et salvatore a validé 3 years ago

[Salvatore] [source:ecrire/lang/ spip] Mise a jour du bilan depuis https://trad.spip.net