S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

[Linux] sudo-rs affiche maintenant des * par défaut quand on tape son mot de passe

Le 02 mars à 15h12

Jusque-là, la fonction « magique » pour passer en mode super-utilisateur sur de nombreuses distributions Linux (sudo) n’affichait rien quand on tapait son mot de passe. L’utilisateur n’avait donc aucun retour sur le fait que la saisie d’une touche avait été prise en compte ou pas.

Mais les contributeurs qui maintiennent le code de sudo-rs (implémentation reprenant les fonctionnalités sudo et su écrites en Rust et visant à être plus fiable) ont décidé de changer le comportement par défaut de leur outil. Ainsi, depuis la dernière version de sudo-rs (0.2.12), l’option pwfeedback est maintenant activée par défaut et des astérisques s’affichent à chaque fois que l’utilisateur tape un caractère de son mot de passe.

« Cela résout un problème majeur d’UX pour les nouveaux utilisateurs. La sécurité est théoriquement moins bonne, car la longueur des mots de passe est visible par les personnes qui regardent votre écran, mais cet inconvénient est infinitésimal et largement compensé par l’amélioration de l’UX. En dehors de sudo/login, aucune autre interface de saisie de mot de passe n’omet les astérisques (y compris les autres sur Linux) », est-il expliqué dans le commit du changement.

Comme l’a repéré Phoronix, ce changement vient d’une demande d’un utilisateur faite en octobre dernier qui argumentait longuement dans ce sens.

Tous les utilisateurs ne sont pas contents de ce changement et ainsi l’un d’entre eux l’a signalé comme un bug, signalement dont le statut a été classé en « ne sera pas corrigé ».

Le 02 mars à 15h12

Commentaires (60)

votre avatar
It's not a bug it's a feature
votre avatar
Ne rien voir quand on tape un MdP dans ce cas ne m'a jamais dérangé, mais bon ...
votre avatar
Ca me dérangera de voir des étoiles, mais c'est l'habitude d'années de pratique...
J'ai simplement pesté de cette fonction quand je faisais des debug au clavier sans fil pourri, qui me bouffait des appuies ou m'en doublés d'autres.

En tout cas, nul doute que tout ceux qui découvrent sont perturbé.
C'est une des premiers commandes utilisés et bam ! ils se mangent déjà une baffe d'ignorance...
Ca ne les mets pas dans un états d'esprit positif pour continuer la découverte !!!

Si j'ai compris c'est une option, donc on pourra renvoyer les étoiles d'où elles viennent
votre avatar
Enfin !

C'est aussi un truc d'accessibilité qui me paraît basique et qui était ultra relou.
votre avatar
vieux débat sécurité vs accessibilité.
avant, on avait une option pour afficher les z'étoiles, maintenant, on en aura une pour les masquer à la place...
votre avatar
Oui enfin sécurité si la sécurité est importante a priori ton mot de passe est long donc le craquer sera bien trop long
votre avatar
Disons que jusque là, il n'y avait pas non plus d'indication du nb de caractères d'un mot de passe pour qqun regardant par dessus son épaule.
Cela peut certes paraître léger comme indication, mais avoir déjà le nb de caractères de l'inconnue affichée en plus de l'utilisateur à cibler classiquement dans le prompt, c'est appréciable!
Bref, on améliore potentiellement la robustesse/sécurité de sudo... pour l'altérer (tout aussi potentiellement) en pratique!
J'espère qu'ils ont prévu une option à l'appel pour revenir au comportement de la version non rust, pour que les paranos règlent cela d'un alias. L'idéal, comme souvent, aurait été que ce soit le nouveau comportement qui soit optionnel!
votre avatar
Si la longueur de votre mot de passe est une indication pertinente pour le trouver, c'est qu'il est trop court !

Pour citer un contributeur sur la PR :
For example brute forcing an 8-character 26-symbol password takes 26^8 = 208 × 10^9 guesses. Brute forcing all shorter passwords takes 8 × 10^9 guesses, so by knowing a password is 8 characters you have saved 4% of your cracking time.
votre avatar
Connaître le nombre de caractères, même si ça n'est pas critique, n'est jamais bon. Parce qu'on pense souvent à la force brute, mais qu'on oublie les autres modalités (caméra vers l'écran et/ou le clavier, et j'en passe).
SAP (que je ne porte pas dans mon cœur) permet d'afficher un nombre d'astérisques >1 pour chaque frappe dans les champs de mot de passe. C'est déjà un premier pas vers la confusion...
votre avatar
Tu sais entendre le bruit des touches quand la personne tape son mot de passe.

Et la solution de contournement est dans l'article
votre avatar
Oui. Mais tu entends aussi les backspace et touches corrigées.

Oui. Mais on ne devrait pas avoir à contourner, l'option par défaut n'aurait pas dû être changée.
votre avatar
C'est un paramètre. Ici, l'équipe de sudo-rs a changer le comportement par défaut. Mais rien n'empêche de mettre le comportement précédent via le fichier sudoers.
votre avatar
Sinon lire l’article qui dit tout ce que tu dis et répond même à ta question ?
votre avatar
L'idéal serait de pouvoir modifier le mode, surtout pour les lieux securisés

Perso, je préfère voir le nombre de caractères. Le nombre de fois que je me suis planté car j'ai tapé 2 fois une touche au lieu d'une.
Résultat: mot de passe incorrect et obligé de le retaper à nouveau.
votre avatar
C'est le cas, c'est juste la configuration par défaut qui change, il est toujours possible de repasser à l'affichage masqué :)
votre avatar
Comme souvent dans ce genre de cas, on va avoir une minorité très bruyante face à une majorité dont la plupart s'en fiche totalement :D

Le nombre de caractère n'est pas vraiment une aide. Eventuellement, il pourra donner une indication sur la robustesse du mot de passe mais c'est bien tout. Un mot de passe robuste ne craint rien. Un mot de passe faible aurait été craqué, avec ou sans les astérisques.

Et si une personne peut voir le nombre d'astérisques par dessus l'épaule de celle qui tape, il y a de grande chance qu'elle puisse également voir les caractères qui sont tapés, et ça, c'est beaucoup plus dangereux pour le coup :non:
votre avatar
Et si le mot de passe c'est 16 astérisques ?
votre avatar
Question pas vraiment dans l'idée de la news: on peut configurer pour avoir un MDP différent pour SUDO que pour son login?
Je trouve cela un peu limite que ce soit le même MDP.
votre avatar
Je ne vois pas ce qu'il y a de limite : sudo demande le mot de passe de l'utilisateur, pas le mot de passe root. Il n'existe pas de notion de "mot de passe sudo".
Si tu connais le mot de passe root, alors autant utiliser directement su.
votre avatar
En effet si tu veux un autre MDP alors mettre un MDP sur root et utiliser su est une solution - mais ça force à ouvrir une session root et la différence est subtile.

su veut dire switch user (changer d'utilisateur) et sudo switch user do (changer d'utilisateur faire). Tu peux faire pointer sudo vers n'importe quel utilisateur. Par défaut c'est root mais -u te permet d'être quelqu'un d'autre :prof:. Être dans les sudoers veut simplement dire qu'on a assez de pouvoir pour faire une commande en tant qu'un autre utilisateur (je ne me rappelle plus s'il y a un moyen d'être sudoer sans avoir accès à root, je vais me prendre un :rtfm:).
votre avatar
Bien sûr que tu peux être autorisé à faire sudo pour un autre utilisateur que root sans être autorisé pour root.

Ce que je voulais dire, c'est qu'il n'y a rien d'étonnant à ce que sudo demande le mot de passe de l'utilisateur et pas un autre mot de passe, puisque su authentifie l'utilisateur pour ensuite changer d'utilisateur selon ce qui a été configuré pour lui. sudo ne demande pas le mot de passe de l'utilisateur de destination, ça n'est pas fait pour ça ; ceux qui pensent que sudo devrait demander le mot de passe de l'utilisateur de destination confondent avec la sémantique de su.
votre avatar
Sudo permet un contrôle très fin de ce qui est autorisé ou non, et n'ouvre pas forcément un shell (à la su).
L'idée de sudo, c'est de donner la possibilité à un utilisateur "normal" d'utiliser des commandes qui nécessitent normalement des droits "administrateurs". Et à ce titre, que se soit le même mot de passe, c'est normal, car on continue d'exécuter une commande (simplement, on a une élévation des droits pour l'exécution de la commande).

On peut très bien autoriser l'accès à une commande spécifique tout en interdisant la possibilité d'avoir un shell.

Et quand je parle de commande, je ne parle pas simplement de l'accès à un exécutable en particulier, mais aussi les paramètres qui lui sont passés en ligne de commande.
votre avatar
sudo -s c'est le même resultat que su root
votre avatar
oui. Et ? Cela ne contredit absolument ce que je dis, à savoir que les deux outils répondent à deux besoins différents, et qu'il n'est donc pas illogique qu'ils aient 2 manières de fonctionner totalement différentes, notamment au niveau de la gestion des mots de passe.
votre avatar
et n'ouvre pas forcément un shell (à la su).
Effectivement, ça me permet de mieux comprendre. J'ai un peu l'usage à la Windows (je ne suis pas admin de mon poste, j'ai un login admin séparé), et je trouvais que le sudo par défaut était beaucoup trop permissif.

Mon but est de séparer la partie "OS" de ma partie "dev" - mais j'ai besoin d'injecter les résultats du dev sur l'OS.

Du coup, je regarde comment créer mon administrateur "intermédiaire", non root, qui permettra de gérer la partie "dev".

Ceci dit, je me suis aperçu entre-temps que j'aurais aussi pu faire un chroot et travailler dans le second environnement.
votre avatar
Sudo "invoque" un utilisateur, pas nécessairement root.
votre avatar
C'est très spécifique car durant le démarrage d'une machine mais par exemple, le déchiffrement de base d'un disque (sda5_crypt) avant le démarrage d'un Debian est aussi sans indication de longueur
votre avatar
Pas toujours, dépends de la méthode de déverrouillage !
La plupart des déverrouillage graphique avec Plymouth ont une indication, pas forcément le cas en déverrouillage console.
votre avatar
Si tu parles de déchiffrement dm-crypt lors de la création du initramfs, chez moi (debian 13) les étoiles se voient bien, que ce soit sur le tty "graphique" ou en port série.
votre avatar
Leur justification est un peu en carton : 100% des commandes en mode texte n'affichaient jusque là rien lors de la saisie d'un mot de passe (login, su, sudo, ssh, ssh-add), à une seule exception à ma connaissance (LUKS).
votre avatar
This goes against DECADES of NOT ECHOING ...
Le seul argument en défaveur de ce changement, c'est que... ça change les habitudes ?

J'en déduis donc que c'est une bonne évolution.
votre avatar
ça va casser des scripts et des outils d'automatisation qui ne s'attendent pas à se faire crible de shurikens. C'est pas juste une question d'habitude, c'est une question que cela crée un nouveau cas de figure qui va nécessiter d'adapter des kilomètres de code.

Ce n'est plus un remplacement de sudo si fonctionnellement, par défaut, cela produit des résultats différents.
votre avatar
qui va nécessiter d'adapter des kilomètres de code.
= Une ligne a ajouter dans le fichier config de sudo

Et surtout si t'as un script qui utilise sudo, normalement tu l'as ajouté a ton sudoers pour éviter qu'il te demande le mot de passe pour ce script spécifique
votre avatar
Le concept de 'normalement' s'applique peu au milieu de l'entreprise.
votre avatar
Les dev Rust et la sécurité, épisode 532.
votre avatar
Moui enfin c'est plus un sentiment de sécurité qu'autre chose, connaître la longueur d'un mot de passe permet pas grand chose en réalité. Sur un brute-force ça peut l'accélérer de quelques pourcents à peine (4%) et si un attaquant peut lire au dessus de ton épaule quand tu tapes ton mot de passe, tu as un plus gros soucis qu'avoir juste révélé la longueur de celui-ci.

C'est comme mettre un scotch noir sur sa serrure parce que "comme ça un attaquant peut pas savoir le type de clé utilisé sans abimer le scotch"... c'est juste chiant à l'usage pour un intérêt ridicule.
votre avatar
Dans la cas d'un pin avec donc 10 symboles, certes stupide (coucou Microsoft et les banques!) qd on a un clavier complet sous la main, on arrive au delà de 10% de gain...
Un remplaçant doit rien changer par défaut et quand on prétends en prime le faire par sécurité hypothétique liée a un changement de language on est cohérent pour ne rien degrader en pratique. Ne serait-ce que d'un %.
Question de cohérence et de crédibilité.
votre avatar
Absolument pas, bien au contraire !
Plus il y a de caractères sur le clavier, moins il y a de gain à connaître la longueur pour tenter un brute-force. J'ai du temps à perdre donc j'ai fait un tableur parce que ça m'intéressait d'avoir les bons pourcentages plutôt que le seul exemple de la PR : Voir ici pour le tableur

Pour un clavier de 76 charactères (26 lettres majuscules et minuscules + 10 chiffres + 14 charactères spéciaux courants) on a 1.32% de gain de vitesse sur un brute-force en en connaissant la longueur. La vitesse de brute-force d'un mot de passe étant exponentielle, brute-force tous les mots de passe de 12 caractères prends bien plus de temps que de brute-force tous ceux de 1, puis de 2, puis de 3,... jusqu'à 11, donc épargner à l'attaquant de calculer ces étapes ne lui sauve qu'un petit pourcent du temps de calcul.

Et, de toute manière, si un attaquant connaît la longueur de ton mot de passe parce qu'il a pu voir les astérisques de sudo, tu as de plus gros soucis et devrait de toute manière changer ton mot de passe asap.
Réduire l'UX pour gagner un sentiment de sécurité illusoire, je trouve ça idiot.
votre avatar
Pas besoin d'utiliser un tableur, son cerveau c'est toujours mieux car le ratio de la suite algébrique de la somme des combinatoires de taille inférieure (N symboles, tailles de 1 à M-1 : N+N^2+...+N^[M-1]) et taille exacte (N^M) se simplifie de manière approximative qq soit la taille du mot de passe, en ~N/(N-1) si N est ne nb de symboles...

Ce qui permet de se rendre compte immédiatement que plus on limite le nb de symboles plus l'écart sera grand.

Et pour 10 symboles d'un pine-d'huitre-code, on est sensiblement à 10/9 soit un facteur 1.11 et les 11% dont je parlais.

Avec tes 76 caractères, 76/75 on a un facteur 1.013 et tes 1.3%, au final on sera sans doute qqpart entre ces 2 chiffres pour la majorité des utilisateurs.

Note également que c'est une estimation pour un crack purement combinatoire. Dans le cadre de méthodes basées dictionnaire (avec les substitutions classiques O/Zéro ou s/$...) connaître le total limite beaucoup le nb de possibilités, en mots seuls ou combinés. Bref, comme toujours, une info utile le sera encore plus avec un usage malin plutôt que bête.

Et je maintiens que, sur le fond, quand on se gausse de hausser la sécurité de sudo en passant du "vil C" au "vertueux Rust", la baisser en pratique ne serait-ce que de qq % n'est vraiment pas terrible niveau cohérence. AMHA, c'est même carrément guignol!
votre avatar
Tu conviendras donc que ton premier "qd on a un clavier complet sous la main, on arrive au delà de 10% de gain..." est faux.
Et je maintiens que, sur le fond, quand on se gausse de hausser la sécurité de sudo en passant du "vil C" au "vertueux Rust", la baisser en pratique ne serait-ce que de qq % n'est vraiment pas terrible niveau cohérence.
Là, on est pas uniquement sur une question de sécurité pure, on est également sur une question d'UX. Il me semble cohérent de vouloir trouver un compromis entre facilité d'usage et sécurité. Afficher le mot de passe en clair est bien mieux en terme d'usage, horrible en termes de sécurité. Ne pas afficher le mot de passe du tout est le mieux en termes de sécurité mais pas terrible d'un point de vue utilisateur (difficile à comprendre la première fois, difficile de voir si on a une touche qui a tapé deux fois, etc.).

Afficher des astérisques est un bon compromis, ça dégrade la sécurité de manière très acceptable (connaître la longueur du mot de passe est une information très mineure pour le trouver) tout en étant bien plus user-friendly, et c'est toujours désactivable sur les environnements le nécessitant.

Pas besoin d'avoir une sécurité de silo nucléaire sur les 99% de PC ne le nécessitant pas, surtout si ça impacte l'expérience utilisateur. Tant que l'option reste disponible à l'activation pour les exploitants de silos nucléaires, je trouve que c'est un bon choix.

Ne pas oublier qu'une réécriture est l'occasion de réfléchir à nouveau à tous les comportements du logiciel qu'on n'aurait jamais pu changer dans l'original !
votre avatar
La citation complète c'est:
"Dans le cas d'un pin avec donc 10 symboles, certes stupide (coucou Microsoft et les banques!) qd on a un clavier complet sous la main, on arrive au delà de 10% de gain..."

Si on retire ce qui est en apposition et a visiblement nuit a la compréhension on a: "Dans le cas d'un pin avec donc 10 symboles on arrive au delà de 10% de gain...".

Le reste, c'est question de point de vue et je maintiens le mien car chez moi la cohérence n'est pas en option.
votre avatar
C'est le "qd on a un clavier complet sous la main" qui m'a perdu.

Au delà, je ne trouve pas que ça soit incohérent : réécrire un code dans un language memory-safe n'exclus pas d'avoir une réflexion plus poussée sur la manière de réécrire. D'autant que dans ce cas, la réécriture ne vise pas qu'à rendre le code memory-safe mais aussi le rendre plus simple et remettre à plat les décisions historiques qui n'auraient jamais pu être revues sur l'ancienne base de code.
votre avatar
Je propose qu'on supprime le mot de passe, ça pourrait résoudre un problème majeur d’UX pour les nouveaux utilisateurs.
votre avatar
Smartcard power !
votre avatar
@Neliger,
Sans ce cas, je propose de renommer ce sudo nouveau de "sudo-rs" à "sodo"!
Et gare au gorille...
votre avatar
Enfin ! On pourra savoir si le copier coller a fonctionné. Surtout quand on guide en partage d'écran.
votre avatar
C'est effectivement une bonne idée car avec un clavier on est jamais sûr que la frappe soit validée et validée une seule fois.
votre avatar
Merci seigneur. Combien de milliers de fois j'ai tapé 2 touches sans en être sûr à 100% ce qui est assez irritant car il y a un délai significatif (de tentative de calcul ou un timer, je ne sais pas exactement).
votre avatar
Mais, mais, mais... Où sera le plaisir de taper 3 caractères, penser se tromper, et appuyer 20 fois retour arrière ?

D'ailleurs, vous aussi quand vous faites une faute de frappe sur un mot de passe, ça sonne comme une mauvaise note sur le clavier ? :D
votre avatar
C'est vraiment con comme truc.

  • ça pose un problème évident de sécurité

  • ça produit des sorties qui risquent de perturber les outils de configuration ou d'automatisation.

  • ça va aussi casser des scripts...



L'option devrait être désactivée par défaut au lieu d'être activée par défaut, car cela disqualifie sudo-rs comme remplacent 1:1 de sudo sur le plan fonctionnel.
votre avatar
ça produit des sorties qui risquent de perturber les outils de configuration ou d'automatisation.
Tu veux dire que des scripts "tapent" le mot de passe sudo ? Comment sont fournis ces mots de passe au script ? C'est plutôt ça le pb de sécurité à mes yeux. Parce que normalement, le sudo devrait être transparent via un NOPASSWD pour les commandes voulues.
votre avatar
Bin ils sont en clair dans le script sur lequel on a fait chmod -r
Expect c'est pas pour les chiens bouffeurs de "ragoutoutou le ragou de mon toutou j'en suis fou".
:mdr2:
votre avatar
D'expérience, toutes les entreprises n'acceptent pas le NOPASSWD... J'ai souvent vu des playbooks ansible qui utilisaient le mdp pour faire le sudo.
votre avatar
Je suis d'accord, c'est vraiment con comme truc.

  • ça perd tous les nouveaux utilisateurs qui ne connaissent pas encore l'outil

  • ça gène la frappe et le copier-coller pour les utilisateurs plus expérimentés

  • ça n'augmente pas la sécurité de façon significative



Ah, je parle du non-affichage du mot de passe.

Sur la sécurité, ça n'améliore rien du tout : si un attaquant peut voir la sortie de ton sudo, tu as de plus gros soucis que le fait que le fait qu'il sache la longueur de ton mot de passe (et tu devrais changer de mot de passe). Et, même dans le cas où un attaquant aurait la longueur de ton mot de passe, s'il est capable de le trouver, c'est que le mot de passe était pas assez long en premier lieu.
votre avatar
Donc maintenant ils n'ont plus qu'à convaincre les devs de login, su et de ssh de faire la même chose par souci de cohérence.
Parce que le manque de cohérence, pour un nouvel utilisateur, c'est un problème majeur d'UX.

Je suis sûr que ls devs de sudo-rs vont convaincre tout le monde de changer parce qu'ils ont raison et que les autres ont tort.
votre avatar
Un nouvel utilisateur se verra-t-il contraint de passer par la CLI ? Les distribs Linux n'en ont quasi plus besoin pour un usage desktop ordinaire.
votre avatar
Euh... à quoi sert sudo-rs à ton avis ?
Ce n'est pas un outil du terminal peut-être ?

Navré si tu fais partie de la team rust ou de la team sudo-rs et que mon post heurte tes sentiments, mais oui, les gars ne sont pas cohérents avec leur propre discours, et oui il prétendent indirectement changer le monde avec leurs petits bras parce qu'ils pensent avoir raison envers et contre tous.
votre avatar
Pas besoin d'être aussi agressif mon poussin.

Tu parlais d'UX et de nouvel utilisateur, raison pour laquelle j'évoque qu'un nouvel arrivant Linux aura peu de chances de se retrouver trop vite confronté à de la CLI, l'environnement graphique étant suffisant de nos jours pour appréhender le système.
votre avatar
Les nouveaux arrivants ne sont pas forcément des utilisateurs lambda, mais potentiellement des étudiants en dev/admin sys
votre avatar
Si ce changement les perd, vaut mieux qu'ils s'orientent de suite sur une autre voie sinon ils vont pleurer dans leur carrière vu toute la sorcellerie de l'IT :D

[Linux] sudo-rs affiche maintenant des * par défaut quand on tape son mot de passe