# PTA V7.12 — Second facteur pour les comptes Service Enfance et DSI

## Le problème traité

La V7.11 a remplacé le sélecteur de rôle par un jeton personnel. C'était un progrès décisif, mais un
jeton reste **un secret qui circule** : il est produit par la DSI, transmis par courriel ou sur
papier, parfois recopié dans un carnet. Un jeton intercepté suffisait à valider les plannings de
toute la collectivité (Service Enfance), voire à distribuer de nouveaux accès (DSI).

Le risque n'est pas le même selon le compte. Un agent ne peut que lire son propre planning ; un
responsable ne touche qu'aux brouillons de son lieu. Ces deux rôles-là restent à un seul facteur —
alourdir leur connexion coûterait plus qu'il ne protégerait.

## Ce qui change

### 1. Deux facteurs, mais seulement là où c'est justifié

| Rôle | Jeton | Mot de passe |
| --- | --- | --- |
| Agent | oui | — |
| Responsable de structure | oui | — |
| **Service Enfance** | oui | **oui** |
| **DSI** | oui | **oui** |

La règle vit **en base**, dans la vue `v_acces_compte` (`mot_de_passe_requis`), comme le reste des
droits depuis la V7.8 : étendre le second facteur à un autre rôle est une modification SQL, pas un
redéploiement.

Les deux secrets sont volontairement de nature différente : le jeton est **remis** par la DSI, le
mot de passe est **choisi** par le titulaire et n'est jamais affiché nulle part.

### 2. Le mot de passe se choisit à la première connexion

La DSI ne pose aucun mot de passe initial, et ne peut donc en connaître aucun. Le parcours :

1. la DSI crée le compte et remet le jeton ;
2. à la première connexion, le jeton est reconnu et l'écran **impose de choisir un mot de passe** ;
3. aux connexions suivantes : jeton, puis mot de passe.

Entre les deux étapes, **rien n'est ouvert** : la session ne porte qu'une attente horodatée, périmée
au bout de cinq minutes. Un jeton validé sans mot de passe ne donne accès à aucune page — vérifié :
`dsi.php` renvoie alors vers l'écran de connexion.

Le compte est **relu en base entre les deux étapes** : si la DSI révoque le compte pendant que
l'utilisateur tape son mot de passe, la session ne s'ouvre pas.

### 3. Politique : la longueur, et rien d'autre

- **12 caractères minimum**, 72 maximum. Aucune règle de composition : exiger une majuscule et un
  chiffre produit `Motdepasse1`, pas un secret. Une phrase dont on se souvient vaut mieux.
- La borne haute n'est pas arbitraire : `password_hash()` utilise bcrypt, qui **ignore
  silencieusement** tout ce qui dépasse 72 octets. Mieux vaut refuser que laisser croire.
- Le jeton lui-même est refusé comme mot de passe : le recopier ramènerait les deux facteurs à un
  seul secret.
- Hachage par `password_hash()` (bcrypt), avec remise à niveau automatique si PHP change
  d'algorithme par défaut. C'est un secret choisi par un humain, donc attaquable par dictionnaire :
  contrairement au jeton, le hachage lent a ici tout son sens.

### 4. Changement et oubli

- **Changer son mot de passe** : bouton « Mot de passe » dans l'en-tête, visible des seuls comptes
  concernés. L'ancien mot de passe est exigé — sans quoi un poste laissé ouvert suffirait à
  confisquer un compte.
- **Oubli** : la DSI **efface** le mot de passe depuis sa page (bouton « Effacer le mot de passe »).
  Elle ne le remplace pas : le titulaire en choisit un nouveau à sa connexion suivante, avec son
  jeton inchangé. La DSI ne connaît donc jamais le mot de passe de personne, pas même à l'instant de
  la réinitialisation.
- La colonne « État » de la liste des comptes affiche « Mot de passe défini » ou « Mot de passe à
  définir ». Le second n'est pas une anomalie : c'est l'état normal d'un compte neuf.

### 5. Le frein anti-force-brute couvre les deux facteurs

Le compteur du journal (`JournalModel::echecsRecents()`) additionne désormais `JETON_REFUSE` et
`MOT_DE_PASSE_REFUSE` : essayer mille mots de passe derrière un jeton volé bute sur le même mur
qu'essayer mille jetons — 10 échecs en 15 minutes par adresse IP, puis plus rien n'est comparé.

### 6. Ce que le journal enregistre en plus

| Action | Catégorie | Quand |
| --- | --- | --- |
| `JETON_ACCEPTE_ATTENTE_MDP` | `CONNEXION` | Jeton reconnu, mot de passe attendu |
| `MOT_DE_PASSE_REFUSE` | `CONNEXION` | Mot de passe incorrect derrière un jeton valide |
| `MOT_DE_PASSE_DEFINI` | `ECRITURE` | Premier choix par le titulaire |
| `MOT_DE_PASSE_MODIFIE` | `ECRITURE` | Changement par le titulaire |
| `MOT_DE_PASSE_REINITIALISE` | `ADMINISTRATION` | Effacement par la DSI |

`CONNEXION_REUSSIE` porte en contexte les facteurs réellement présentés (`["jeton"]` ou
`["jeton","mot_de_passe"]`) : le journal distingue donc une connexion à un facteur d'une connexion à
deux.

## Mise en service

Rien à faire hors la migration `database/migration_v7_9f_mot_de_passe_admin.sql`, appliquée
automatiquement au démarrage. **Les comptes Service Enfance et DSI existants n'ont pas de mot de
passe** : leur prochaine connexion, jeton en main, leur en fera choisir un. Aucun jeton n'est
invalidé, aucun compte n'est bloqué.

Prévenez les titulaires concernés : ils verront un écran qu'ils n'attendent pas.

### Si le dernier accès DSI perd son mot de passe

Le cas ne se résout pas dans l'interface, puisqu'il faudrait être connecté pour le faire. En SQL :

```sql
UPDATE compte_acces SET mot_de_passe_hash = NULL, date_mot_de_passe = NULL WHERE id_compte = 1;
```

La connexion suivante, avec le jeton, redemandera d'en définir un. Si le jeton lui-même est perdu,
voir la procédure de `README_V7_11.md`.

## Fichiers

| Fichier | Rôle |
| --- | --- |
| `database/migration_v7_9f_mot_de_passe_admin.sql` | Colonnes `mot_de_passe_hash` / `date_mot_de_passe`, vue `v_acces_compte` enrichie de `mot_de_passe_requis` et `mot_de_passe_defini` |
| `app/Controllers/RoleController.php` | Connexion en deux étapes, définition, vérification, changement |
| `app/Models/CompteModel.php` | Politique, hachage, vérification, réinitialisation |
| `app/Models/JournalModel.php` | Frein étendu au second facteur |
| `app/Controllers/DsiController.php`, `api/dsi_compte_mot_de_passe.php` | Effacement par la DSI |
| `app/Views/pages/role.php` | Les quatre états de l'écran de connexion |
| `app/Views/layouts/header.php` | Lien « Mot de passe », pour les seuls comptes concernés |

## Ce que la V7.12 ne fait pas

- **Pas de verrouillage du compte** après N échecs : seul le frein par adresse IP s'applique. Un
  verrouillage par compte permettrait à quiconque connaît un jeton de bloquer volontairement un
  administrateur.
- **Pas d'expiration ni d'historique des mots de passe** : forcer un changement tous les trois mois
  produit `Motdepasse-Mars`, `Motdepasse-Juin`. Le mot de passe se change quand il y a une raison.
- **Pas de réinitialisation par courriel** : il n'y a pas d'envoi de courriel dans PTA, et la boîte
  aux lettres deviendrait le vrai facteur d'authentification.
- **Pas de TOTP** : le jeton joue déjà le rôle du « quelque chose que l'on détient ». Un
  authentificateur mobile serait le prolongement naturel si le besoin s'en faisait sentir.