Désolé de ne pas avoir répondu plus tôt.

Envoyé par
earhater
La connexion SSH implique un échange ssl entre les deux partis, donc le risque attaque main in the middle est quasi nul (mais pas inexistant, je pense notamment à une falsification des certificats en local, par exemple via un phishing et une élévation de privilèges préalable). La commande passwd n'expose pas directement le mot de passe utilisateur, ni même la longueur du mot de passe : quand on l'écrit dans le terminal on ne voit rien s'afficher à l'écran. la seule viable manière pour un attaquant de récupéré un mot de passe utilisateur via un terminal ssh est un keylogger, qui ne requière pour sa part aucune élévation de privilèges. Un bon antivirus à jour permet toutefois de s'en protéger en partie en cas de phishing.
Sur ce point, nous sommes d'accord. D'ailleurs, il n'y a pas trop à débattre car tu énonces pour la quasi totalité des faits (oui, ssh implique un échange de certificat ssl, passwd ne montre pas son input, etc etc). Il n'y a que le keylogger géré via anti-virus sur lequel je ne me prononcerais pas.

Envoyé par
earhater
L'update automatique dans un script d'un mot de passe utilisateur ne doit pas être faite de cette manière. Si jamais on devait le faire je pense que je sauvegarderai le fichier de mot de passe en local, avec un système de hashage symétrique avec une clef sauvegardé à distance, avec une authentification par clef publique et privée. Mais je taperai très fort sur les doigts des gens qui me demanderaient de développer cet outil incensé. Le script prend le fichier sauvegardé sur le local : demande la clef de déchiffrage sur un serveur distant (à usage unique) qu'il récupère via un échange de clef publique / privée pour décoder l'entrée fichier, mettre à jour le mot de passe utilisateur et supprimer le fichier de mot de passe local
Ok, c'est mieux que ma méthode car en cas de log, le mdp n’apparaît (et cela répond donc à ma question). Mais hormis le fait que tu caches le mdp dans un fichier, cela ne change pas le fait que tu doives à un moment ou un autre envoyer le "mdp" en clair.
Dans ton exemple, le "mdp" en clair, c'est l'acquisition de la clef de déchiffrage sur serveur distant. Car au final, même si ton vrai mdp est chiffré, il n'empêche que tu dois acquérir la clef de déchiffrement qui elle, sera en clair ...

Envoyé par
earhater
A chaque utilisation du script, le responsable technique s'occupe de générer une nouvelle clef de chiffrage / déchiffrage qu'il stocke sur ce serveur distant et renvoie les mot de passes chiffrés au client
L'étape "action responsable technique" est en trop si la volumétrie est énorme. C'est pour cela que la chaîne de maj du mdp devait être entièrement automatique.

Envoyé par
earhater
De la même manière, tous les frameworks qui se respectent proposent une entrée input sécurisée (
$this->secret pour laravel, je te fais pas la démo pour tous les outils) qui utilisent le secure input dont le comportement et les limites sont exposés juste au dessus. En bash pur, l'argument
-s à la commande
read permet de demander un secure input dont, encore une fois, le comportement et limites sont exposées si dessus.
Tout cela relève de la sécurité de base
EDIT: à aucun moment l'input utilisateur n'est remonté par la commande bash
history
La, tu part un peu en hors sujet par rapport à mon exemple initial :
Imagine que tu as une class "myssh2" avec la methode "execute($command)". la méthode execute se charge donc d'exécuter la commande "$command".
En cas d'erreur, on est bien content en général d'avoir la commande fautive (et le résultat de la commande par exemple), tout simplement parce que "Une commande envoyé en ssh ne s'est pas exécuté correctement", c'est mignon mais pas très utile, alors que "Echec de le commande 'ls /path/dossier/inexistant'" est plus parlant.
Il n'y a pas moyen de savoir que "$command" est quelque chose qu'il faut cacher (d'où ton hors sujet avec l'input sécurisé où là on sait clairement que l'on va rentrer des infos sensibles). D'où pourquoi je te dis que ce type d'erreur (mdp en clair dans les log) peut être vicieux.
Et je te parle de pdo et ssh2 uniquement parce que j'y ai déjà été confronté, mais clairement il doit y avoir d'autre exemple plus pertinents.
0 |
0 |