Mot de passe aléatoire par mail à chaque connexion

Programmation
#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.

#21

Juste vite fait, personne ne pense à OpenOTP? plus simple, rien à fabriquer,.
le seul imperatif utiliser un service compatible.

On peut fabriquer le sien à partir d’une solution disponible mais très complexe à mettre en oeuvre.

#22

@Zargos
encore eut-il fallut connaître OpenOTP :slight_smile:
Personne n’y avait pensé.

#23

Je m’y étais intéressé pour faire mon propre serveur OTP en fait, avec RCS. Mais la version community est difficile à installer. La doc plus ou moins à jour par rapport aux sources/packages.
Mais j’y reviendrais car c’est quand même interessant, car ça permet de faire une double authentification, une authentification à la demande, en utlisant HTTPs, LDAP, Raius, Active Directory, et SMS aussi. en fonction de ce chacun veut en quelque sorte mais aussi en lien avec les fonctionnalité. Car le produit complet fait pas mal de choses diferentes mais est basé sur des « modules ».