[spip ↪ refactor_auth_spip41] 5 commits

spip/spip | 5 commits

Par Matthieu Marcillaud, le 24 février 2022 à 19h51min :

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)

Modifié
ecrire/action/inscrire_auteur.php

Détails : 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) · 257649aaa8 - spip - SPIP on GIT

==============================
Par Matthieu Marcillaud, le 24 février 2022 à 23h07min :

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

Modifié
ecrire/action/inscrire_auteur.php

Détails : 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) · b9326eec7b - spip - SPIP on GIT

==============================
Par Matthieu Marcillaud, le 25 février 2022 à 18h11min :

Sécurité des authentifications avec le secret du site (g0uZ) :

  • 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.

Modifié
ecrire/action/inscrire_auteur.php
ecrire/inc/securiser_action.php
ecrire/src/Chiffrer/Chiffrement.php
ecrire/src/Chiffrer/SpipCles.php

Détails : https://git.spip.net/spip/spip/commit/fadeb3ea8ec0f72cc5904cb64d30e5ccb4e917a1

==============================
Par Cerdic, le 28 février 2022 à 14h05min :

chaines de langue lors de l’install en cas d’erreur lors de l’initialisation du compte

Modifié
ecrire/install/etape_3b.php
ecrire/lang/ecrire_fr.php

Détails : https://git.spip.net/spip/spip/commit/bde35e45e20c47a0f01748c9648c0eac4d178231

==============================
Par Cerdic, le 28 février 2022 à 15h20min :

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

Modifié
ecrire/auth/spip.php

Détails : https://git.spip.net/spip/spip/commit/b8ecbb27ff1e6574fef069f08f6ccf5f7192b4ce