Émission de mot de passe

L'émission d'un mot de passe est l'étape où un système génère un secret (mot de passe initial, temporaire ou code à usage unique) et le remet à l'utilisateur par un canal donné : courriel, SMS, lien de réinitialisation, remise en main propre. C'est le moment le plus exposé de la vie d'un mot de passe, parce que le secret circule en clair au moins une fois.

Ce que recouvre l’émission d’un mot de passe

Un mot de passe naît quelque part. Soit l'utilisateur le choisit à l'inscription, soit le système le fabrique et le lui remet. C'est ce second cas que l'on appelle émission de mot de passe : un administrateur crée un compte et communique un mot de passe provisoire, un formulaire « mot de passe oublié » envoie un lien, un serveur expédie un code à six chiffres pour valider une connexion, un hôtel imprime un identifiant Wi-Fi sur un ticket. Dans chacun de ces scénarios, quelqu'un d'autre que l'utilisateur connaît le secret pendant un instant, et ce secret doit voyager.

Le terme ne dit rien du stockage. Un mot de passe émis puis haché avec bcrypt ou Argon2 (RFC 9106) reste un mot de passe émis ; c'est le trajet qui compte ici, pas la base de données.

Trois familles reviennent en pratique. Le mot de passe initial, censé être remplacé à la première ouverture de session. Le mot de passe temporaire, valable quelques heures pour dépanner un utilisateur bloqué. Et le code à usage unique, ou OTP, décrit par la RFC 4226 (HOTP, basé sur un compteur) et la RFC 6238 (TOTP, basé sur l'horloge, avec un pas de 30 secondes par défaut). Ce dernier n'est pas vraiment un mot de passe, mais son émission soulève exactement les mêmes questions : par où passe-t-il, combien de temps vit-il, qui peut le lire en route.

Les canaux d’émission et ce qu’ils exposent

Le canal fait presque tout.

Un courriel part en SMTP : port 25 entre serveurs, 587 ou 465 en soumission depuis un client. La RFC 3207 permet de chiffrer le transport avec STARTTLS, mais rien n'oblige le serveur distant à l'accepter et l'expéditeur n'a aucune visibilité sur le dernier saut. Un mot de passe envoyé par courriel est donc lisible par tout relais mal configuré sur le chemin, puis il reste dans la boîte de réception, dans les sauvegardes, dans les archives de conformité. Une messagerie compromise en 2029 révélera un mot de passe émis en 2026 s'il n'a jamais été changé entre-temps.

Le SMS est pire sur un point précis : il ne dépend même pas de votre infrastructure. Un portage frauduleux de numéro (SIM swap) détourne tous les codes vers l'attaquant sans qu'aucun serveur ne soit touché. Le NIST classe d'ailleurs le SMS et l'appel vocal parmi les canaux « restreints » dans sa publication SP 800-63B, ce qui oblige le fournisseur à prévenir l'utilisateur du risque et à lui proposer un autre moyen d'authentification.

Canal	Qui peut lire le secret en route	Durée de validité courante
Courriel	Relais SMTP sans TLS, boîte de réception, sauvegardes	15 à 60 min pour un lien ; à proscrire pour un mot de passe permanent
SMS	Opérateur, SIM swap, application Android ayant la permission de lire les SMS	5 à 10 min
Lien HTTPS de réinitialisation	Historique du navigateur, journaux du serveur web, en-tête Referer	15 à 60 min, usage unique
Remise en main propre	Le porteur du document	Jusqu'à la première connexion, changement forcé
Application TOTP	Personne : seul le secret initial transite, une fois, via le QR code	30 s par code

Le lien de réinitialisation, cas d’école

Prenez un formulaire « mot de passe oublié ». Le serveur génère un jeton, l'enregistre avec une date d'expiration et l'identifiant du compte, puis envoie une URL du type https://exemple.fr/reset?token=… Tout repose sur ce jeton. S'il est prévisible, par exemple un horodatage, un identifiant incrémental ou un hachage MD5 de l'adresse mail, un attaquant le retrouve sans jamais lire le courriel. Il faut donc au moins 128 bits tirés d'un générateur cryptographique, soit 32 caractères hexadécimaux ou 22 caractères en base64 sans remplissage.

Une commande suffit pour produire ce genre de valeur : openssl rand -hex 16.

Reste une fuite moins connue. Si la page de réinitialisation charge une police, un script de mesure d'audience ou une image depuis un domaine tiers, le navigateur peut transmettre l'URL complète, jeton compris, dans l'en-tête Referer de chaque requête sortante. Les navigateurs récents appliquent strict-origin-when-cross-origin par défaut et tronquent le chemin vers les autres origines, mais compter sur un réglage par défaut est une mauvaise habitude ; l'en-tête de réponse Referrer-Policy: no-referrer règle la question. Le jeton doit ensuite être invalidé à la première utilisation, à l'expiration, et à toute nouvelle demande de réinitialisation pour le même compte.

Un dernier détail. La réponse du formulaire doit être la même que l'adresse existe ou non ; sinon vous venez de fabriquer un outil d'énumération de comptes.

Forcer le changement après l’émission

Un mot de passe émis par un tiers ne devrait jamais devenir le mot de passe définitif. Le mécanisme pour l'empêcher existe sur toutes les plateformes, il est simplement peu activé.

Sous Linux, passwd -e alice (ou chage -d 0 alice) remet à zéro la date de dernier changement dans /etc/shadow ; à la prochaine ouverture de session, PAM exige un nouveau mot de passe avant de rendre la main. Sous Windows et dans Active Directory, l'équivalent est la case « L'utilisateur doit changer le mot de passe à la prochaine ouverture de session », que l'on coche aussi en ligne de commande avec net user alice /logonpasswordchg:yes. Sous OpenLDAP avec l'overlay ppolicy, c'est l'attribut opérationnel pwdReset qui joue ce rôle. Dans une application web, on stocke un drapeau du type must_change_password et on le vérifie à chaque requête authentifiée.

Ce dernier point piège beaucoup de développeurs. Tester le drapeau uniquement au moment du login laisse passer les sessions déjà ouvertes et les jetons d'API générés avant l'émission.

• Linux : passwd -e utilisateur, ou chage -d 0 utilisateur
• Windows et Active Directory : net user utilisateur /logonpasswordchg:yes
• OpenLDAP (ppolicy) : pwdReset à TRUE sur l'entrée
• Application web : drapeau must_change_password testé sur chaque requête, pas seulement sur la page de connexion

Ce que le terme ne désigne pas

L'émission n'est pas l'attaque. Les attaques par mot de passe (force brute, bourrage d'identifiants, pulvérisation) visent un secret déjà en place ; l'émission est la phase amont, celle qui décide si ce secret vaut quelque chose. Un mot de passe de 20 caractères aléatoires envoyé par courriel non chiffré est plus fragile qu'un mot de passe de 12 caractères saisi par l'utilisateur sur une page HTTPS, parce que le premier a existé en clair hors de tout contrôle.

Elle ne se confond pas non plus avec l'authentification à deux facteurs. Un code TOTP est calculé localement par l'application, il ne transite pas ; seul le secret partagé au moment du QR code relève de l'émission au sens strict, et c'est lui qu'il faut protéger, pas les codes qui en découlent.

Hors du vocabulaire technique, la requête renvoie aussi au jeu télévisé « Mot de passe » diffusé sur France 2 et présenté par Patrick Sabatier. Aucun rapport avec cette fiche.

Testez vos connaissances

Questions fréquentes

Peut-on envoyer un mot de passe par courriel ?

Un mot de passe permanent, non : il resterait lisible dans la boîte de réception et les sauvegardes pendant des années. Un lien à usage unique qui expire en moins d'une heure, oui, à condition de forcer la saisie d'un nouveau mot de passe derrière. Si une procédure interne impose quand même l'envoi d'un mot de passe provisoire, séparez au moins l'identifiant et le secret sur deux canaux différents.

Combien de temps un mot de passe temporaire doit-il rester valable ?

Aucune norme ne fixe une valeur unique. En pratique, un lien de réinitialisation vit entre 15 et 60 minutes ; un mot de passe provisoire remis par un administrateur reste valable jusqu'à la première connexion, avec un délai butoir de quelques jours au-delà duquel le compte est désactivé plutôt que laissé ouvert avec un secret connu de deux personnes.

Un code reçu par SMS compte-t-il comme un mot de passe émis ?

Oui, du point de vue du trajet : il est généré côté serveur et transmis par un canal que vous ne contrôlez pas. Le NIST SP 800-63B le tolère comme canal restreint, à condition d'informer l'utilisateur et de lui offrir une alternative, une application TOTP ou une clé FIDO2 par exemple.

Que faire si un mot de passe a été émis en clair par erreur ?

Le considérer compromis, sans débat. Invalider le secret, forcer un renouvellement, puis chercher où la valeur a pu être copiée : journaux SMTP, ticket d'assistance, canal de discussion interne, capture d'écran. Les journaux applicatifs sont souvent oubliés alors qu'ils enregistrent volontiers le corps des requêtes POST.

Pourquoi le message « aucun compte associé à cette adresse » pose-t-il problème ?

Parce qu'il confirme à un inconnu quelles adresses ont un compte chez vous. Un attaquant peut ainsi trier une liste d'adresses volées ailleurs avant de lancer un bourrage d'identifiants. Le formulaire doit répondre la même chose dans les deux cas : si un compte existe, un courriel a été envoyé.

À lire aussi

attaques par mot de passe · authentification deux facteurs · chiffrement email · brute force