Mot de passe aléatoire par mail à chaque connexion

Programmation
#1

Bonjour à tous;

Mon fils me pose une question, à laquelle je ne peux complètement répondre:
je lui ai créé une machine sous Debian en testing. Il voulait Enlightement, je lui ai mis.
Jusque la, rien de grave. L’interface de connexion, j’aime bien Slim, c’est léger, et ça fait le job (sauf que pour le moment, il faut forcer à la main sur enlightement pour la connexion, mais la n’est pas le sujet).
Sa question:
Est il possible de faire en sorte que lorsqu’il met son identifiant, cela lui envoi un mot de passe aléatoire par mail (sous entendu sur son smartphone).
Sachant que le serveur mail est à la maison, je peux gérer un job sur le serveur.

De prime abord, j’ai pensé à un script sur sa machine et à une « interface » via pam qui gérerait l’envoi et la gestion du mot de passe.
Mais en seconde réflexion, je pense que la solution est plus subtile/complexe que ça.

Bon, on est d’accord, ce n’est qu’un exercice de style, c’est pas pour mettre en prod. mais juste pour la réflexion et le défit, est-ce réalisable, et comment?

Merci de vos avis.

Rémi.

1 J'aime
#2

Bonjour,

Tiens c’est bien la première fois que j’entends cette requête.
Perso, je ne sais pas ; j’aurais tendance à dire non, d’autant si ses données sont chiffrées. Générer un nouveau pass dans ce cas serait source d’ennui, à court terme.

Par contre, ce qu’il est possible/envisageable de faire est d’avoir une clé USB 2FA (de double authentification), qui combinée à PAM, ou utilisant - peut être - la norme FIDO2, permet d’empêcher l’authentification de session, sans.
Je pense qu’on doit pouvoir trouver facilement des tutoriels, dans ce sens :wink:

#3

En effet je pensais plus à de la double authentification.
Sinon pour la demande originelle, je ne voyais pas comment déclencher un changement + envoi de mdp juste après avoir saisi les identifiants (login). A mon avis il faut au moins une connexion échouée :

  1. saisie de l’identifiant + mdp erroné
  2. un service (démon) détecte l’échec de connexion locale au compte
  3. déclenchement du script de changement du mot de passe
  4. envoi par mail du nouveau mot de passe

A la limite, il n’y a pas forcément besoin d’interfacer quoi que ce soit avec pam. Pour le service à l’étape 2, il doit y avoir moyen de configurer un jail fail2ban pour ça, par exemple.

Et vu le besoin simpliste en termes de mail, pas besoin non plus de passer par une tierce machine ou un serveur mail sur le réseau local, un petit ssmtp ou autre outil pour utiliser un serveur SMTP externe d’une adresse existante ferait l’affaire.

#4

@PengouinPdt on est d’accord, ce n’est pas très sécurisé, je voyais plus ça comme un défi et un outil de démo pas à mettre en prod. La question d’utiliser une clef usb 2FA est certe beaucoup plus sécure. Perso, j’utilise tous les jours au boulot une carte professionnelle (même si les lecteurs sont à la ramasse) c’est le même principe.

@Sputnik93 Je n’avais pas pensé à l’échouage (ça ce dit?) du mot de passe qui déclanche la procédure.

J’ai un peu réfléchi cette nuit (oui je dors mal…) je pensais à un fork local de slim :

  • je rentre l’identifiant
  • slim déclenche la procédure sur un daemon d’authentification

Merci de vos avis à tous les deux.

#5

Ben ça se dit pour les baleines, pour les tentatives d’authentification j’aurais plutôt dit « échec » :grinning:
Slim c’est le gestionnaire de connexion d’Enlightenment ?

#6

Bonjour
Et si, au moment de la fermeture de sa session, un nouveau mot de passe pour son compte utilisateur était généré, inscrit dans /etc/shadow, puis et envoyé à son adresse mail …

#7

@MicP
Oui, j’avais pas pensé à /etc/shadow !
Je lui avais dit que ce n’était pas si évident que ça, mais que le défis était sûrement marrant.
La ça devient prise de tête pour les vacances !
« Pour s’echouer sur la plage » :crazy_face::crazy_face::crazy_face::crazy_face: @Sputnik93

#8

Créer un mot de passe, le chiffrer et le mettre dans /etc/shadow en remplacement de l’ancien mot de passe chiffré, c’est très facile à faire,
envoyer par mail le nouveau mot de passe correspondant, ça, ça dépends du serveur de mail qui va le recevoir, mais ce n’est pas non plus compliqué à faire,
et faire un service qui va lancer le script qui fera les deux opérations ci-dessus,
ce n’est pas non plus difficile.

En gros, ça ne fait que trois choses à faire faire, la première ne me pose aucun problème,
et les deux autres sont dépendantes de la boîte mail et de la configuration du système qui va lancer tout ça.

Ah j’oubliais, il faudra aussi un générateur de mots de passe, mais ça ne doit pas être difficile d’en trouver de tout faits bien faits.
Et puis il faudra voir le côté sécurité, je n’ai pas assez d’expérience, mais il y a sans doute sur ce forum des personnes qui pourront nous conseiller :grinning:

#9

Un mot de passe de 20 caractères :

pwgen -cnsy 20 1

Il y a plein d’autres solutions :wink:

1 J'aime
#10

en fait, c’est plein de petits détails, les uns derrières les autres, qu’il faut assembler.
Et de la meilleur façon possible!

Merci pour vos avis.

#11

Un tout petit détail de plus: ne jamais oublier qu’un courriel (non chiffré), c’est aussi sécurisé qu’une carte postale: n’importe quel postier (électronique) aura tout loisir de lire les contenus avec les précieux sésames.

Si c’est chiffré, le postier pourra gardera une copie de la missive, et utilisera un ordi quantique ou autre machin performant pour craquer ça un beau jour.

Du coup, pour contourner ce genre de choses, on pourrait imaginer un truc du genre:

  1. le fiston paranoïaque amusant se crée une liste bien longue de mots de passes bien tordus;
  2. quand il y a nécessité d’un nouveau mot de passe, un script va piocher un numéro aléatoirement, il définit sur le système le mot de passe correspondant à ce numéro;
  3. on envoie par courriel le numéro, et à l’utilisateur de savoir retrouver dans la liste le sésame adéquat.

Ils sont marrants, les défis de votre fiston.

#12

Pour créer le mot de passe chiffré à mettre dans /etc/shadow à partir d’un mot de passe en clair,
j’en avais parlé dans ce message

#13

Entièrement d’accord, le mail n’est aucunement sécurisé.
C’est pour cela que j’ai bien précisé que ce n’est pas pour mettre en prod.
Maintenant, pour limiter « au mieux » (ou au moins pire), il faudrait :
1/ générer le mdp,
2/ dès l’envoi, surveiller qu’il ne sera utiliser qu’une seule fois dans les 5 minutes ou moins
3/ envoyer une confirmation d’utilisation (si on a pas utilisé le mot de passe mais qu’on reçoit le mail de confirmation, ben c’est qu’on a été intercepté)
Ca n’empêche pas l’interception, mais ça peu prévenir…

Le coup du chiffre qui fait référence a une série de code sur une carte, le crédit mutuel le fait (mais faut pas perdre la carte, ou la ranger tellement bien, qu’on ne la retrouve plus)

Et oui, je confirme, j’ai un gamin tordu… Et j’en ai d’autres, imaginez la galère !

1 J'aime
#14

Juste une idée a l’instant, en voyant les messages du forum :
Et si on utilise gpg pour le mail!?
Moins de problème sur le mail déjà ?

1 J'aime
#15

Si le mot de passe doit être utilisé, c’est que la personne est proche de la machine.
alors, plutôt que d’utiliser les mails,
pourquoi ne pas utiliser le BlueTooth pour transmettre le mot de passe sur son smartphone,
ça permettrait d’identifier le smartphone qui aura déjà été appairé avec la machine qui va recevoir le mot de passe, et d’être sûr que le smartphone est bien à proximité de la machine.

Si le smartphone est à proximité du PC au moment de la fermeture de session,
(ce qui devrait être le cas puisque l’utilisateur concerné est en train de fermer sa session)
alors le nouveau mot de passe sera transmis par BlueTooth sur son smartphone,
Ou/et la transmission du mot de passe se fera au moment du démarrage de la machine
si le smartphone est à proximité de la machine.

#16

Parce que totalement pas sûr, le protocol est…
(c’est d’ailleurs la raison pour laquelle il n’est pas dans OpenBSD)

Pourquoi chercher des solutions bancales en termes de confidentialité/sécurité des données ?!

1 J'aime
#17

Si il est à moins de 5 mètres de la machine, protocole sécurisé ou pas, bancal ou pas,
je ne vois pas ce qui le retient d’aller booter la machine en mode rescue pour se connecter avec le compte root.
Et entre envoyer un mot de passe sur le web et ne le diffuser que dans un rayon de quelques mètres,
ça fait quand même beaucoup moins de monde qui pourrait y avoir accès.

#18

Bonjour, je vois bien un script de démarrage lancé avec systemd avec un script bash

randompw=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 8 | head -n 1)
echo NomDUtilisateur:$randompw | /usr/sbin/chpasswd

et finir l’implémentation avant la fin du script pour envoyer le mail automatiquement

#19 
randompw=$(pwgen -cns 8 1)
/usr/sbin/chpasswd nom_utilisateur:$randompw
#20

@Asteroide404
Merci de la suggestion.
Mais il faut d’abord savoir qui se connecte. Donc :
‹ intercepter › l’identifiant reçut (en console si nous sommes en tty, ou via le display manager), puis exécuter le script.
Reste à envoyer un mail de façon sécurisée. quelque soit le canal d’envoi.