WinAdminPassword : Déployer des mots de passe uniques sur les systèmes GNU Linux / Microsoft Windows

Posté par . Modéré par baud123. Licence CC by-sa
21
14
août
2011
Sécurité

L'outil WinAdminPassword permet de générer des mots de passe en fonction d'une clef secrète et du numéro de série de l'ordinateur sur lequel il est lancé.

Son objectif principal est de déployer des mots de passe différents pour les comptes d'administration, et cela sur tous les systèmes de son parc informatique (Microsoft Windows, Linux, BSD, POSIX...).

Les mots de passe générés contiennent quatre types de caractères (majuscules, minuscules, chiffres et caractères spéciaux) et ne sont pas sauvegardés dans une base de données (Les seules informations à enregistrer dans votre gestionnaire ou base de mots de passe sont les clefs secrètes de génération des mots de passe).

Licence : GPLv3
Version courante : 1.5
Systèmes testés : Debian 6, Ubuntu 11.04, CentOS 5, RHEL 5, Fedora 15, OpenSuze 11.4, Mandriva Linux 2010.2, Microsoft Windows XP and Microsoft Windows 7 (x86 and x64)

Liste des fonctionnalités :

  • génération de mots de passe basés sur une clef secrète et le numéro de série de l'ordinateur sur lequel l'outil s'exécute ;
  • possibilité d'ajouter une seconde clef secrète lors de la génération des mots de passe ;
  • possibilité de générer des mots de passe basés sur la date et l'heure du système ;
  • possibilité de création d'une tâche planifiée (crontab et planificateur de tâches) lancée toutes les heures ;
  • changement du mot de passe de n'importe quel compte ;
  • possibilité de retrouver n'importe quel mot de passe ;
  • possibilité d'affichage, des mots de passe générés, au format HTML (Webmin, Page web...) ;
  • paquetage NSIS pour les installations sous Microsoft Windows ;
  • paquet DEB ;
  • paquet RPM ;
  • plugin GLPI.

Exemple concret d'utilisation :

(Voir le README et le WIKI du projet pour plus d'informations).

Dans cet exemple, nous souhaitons déployer des mots de passe différents sur tous nos serveurs Linux (CentOS) et postes clients Microsoft Windows 7.

Le compte administrateur sur les Windows est "Administrateur" et "root" sur les CentOS.
La taille de nos mots de passe sera de 12 caractères et notre clef secrète sera "My Very SecretKey".

Voici les étapes à suivre :

1 Déployez l'outil WinAdminPassword sur tous les systèmes (Utilisez le RPM sur les CentOS et le paquetage NSIS sur les Microsoft Windows).

2 Lancez la commande suivante sur les systèmes Microsoft Windows (Utilisez un compte administrateur) :

winadminpassword --changepassword --user Administrateur --key "My Very SecretKey" --length 12

3 Lancez la commande suivante sur les systèmes CentOS (Utilisez le compte root) :

winadminpassword --changepassword --user root --key "My Very SecretKey" --length 12

4 Pour afficher les mots de passe, installez l'outil WinAdminPassword sur votre système et lancez la commande suivante, en renseignant le numéro de série de l'ordinateur, ou utilisez simplement le plugin GLPI :

winadminpassword --printpassword --key "My Very SecretKey" --length 12 --serial "SerialNumber"

À noter qu'il est possible de lancer ces commandes lors de l'installation de vos machines (Sysprep pour Windows + Anaconda pour CentOS) et de changer régulièrement la clef secrète (GPO, SSH, WPKG, OCSinventory NG, FusionInventory, Uranos...).

Pour aller plus loin...

Concernant les autres fonctionnalités, il est possible de générer le mot de passe en fonction de l'heure système, d'ajouter une commande dans une tâche planifiée et lancée toutes les heures (crontab et planificateur de tâches), d'afficher le résultat de la commande --printpassword en HTML etc.

Voici quelques exemples :

1 L'exemple suivant permet de générer un mot de passe de 12 caractères, en fonction du numéro de série, de deux clefs secrètes et de la date du système. Cette commande sera placée dans la crontab (Unix) ou dans le planificateur de tâche (Microsoft Windows) de l'utilisateur exécutant la commande. Le mot de passe sera ainsi changé toutes les heures, et dépendra de la date et l'heure d'exécution de la commande :

winadminpassword --changepassword --user Administrateur --key "My Very SecretKey" --secondkey "SimpleKey" --length 12 --time --cron

2 L'exemple suivant permet d'afficher le résultat en HTML :
--time pour l'heure courante
--date "18.2012.Jan.02" pour le 2 Janvier 2012 à 18H

winadminpassword --printpassword --key "My Very SecretKey" --secondkey "SimpleKey" --length 12 --time --html --size 24 --color red    
winadminpassword --printpassword --key "My Very SecretKey" --secondkey "SimpleKey" --length 12 --html --size 24 --color red --date "18.2011.Aug.02"

3 L'exemple suivant permet d'appliquer toutes les heures un mot de passe prédéfini et d'afficher le mot de passe :

winadminpassword --changepassword --user Administrateur --password "MonMotdePasseUnique" --cron --verbose

4 L'exemple suivant permet d'afficher le numéro de série de l'ordinateur :

winadminpassword --printserial

5 L'exemple suivant permet d'afficher la date et l'heure du système sous le format utilisé par WinAdminPassword :

winadminpassword --printdate
  • # A essayer !

    Posté par . Évalué à 2.

    Intéressent ! :) Je vais tester sur Mageia et sur PCBSD
    Merci

    Webmastering - UNIX - GNU Linux - BSD,, à internet - A étudié Kernel crew à UNIVERSITY OF LINUX - Parle Perl, Java, C/C, Bash Shell, UNIX (Programming), LINUX, français et anglais

    • [^] # Re: A essayer !

      Posté par . Évalué à 2.

      N'hésites pas à m'envoyer tes retours :)

      A bientôt.

  • # Sécurité de la ligne de commande

    Posté par . Évalué à 10.

    Très bon projet, je me permet néanmoins une remarque d'un point de vue de la sécurité : il est très dangereux de passer des arguments tels que des mots de passe (ou, dans le cas présent, une clef secrète) via la ligne de commande.
    En effet, deux scénarios d'attaques sont alors facilement envisageables :
    -quelqu'un qui a accès à l'historique (bash_history étant la manière la plus simple) connaitra alors toutes les clefs
    -si c'est un script ou un cron qui l'exécute, il suffit d'avoir accès au script en question ou au crontab de l'utilisateur (assez facile)
    -autre scénario, presque encore plus facile : réaliser un petit programme qui se charge de scruter la liste des process actifs, en permanence (équivalent de "ps aux" mais exécuté en continu, très rapidement). Dès qu'il trouve "winadminpassword" dans la liste, bingo, la clef est derrière!

    Ainsi, la plupart des logiciels qui demandent un mot de passe ou une clef en entrée optent pour deux possibilités (pas forcément contradictoires) :
    -lecture depuis un fichier : c'est la solution privilégiée pour l'exécution depuis un cron ou un script : le crontab est accessible potentiellement par tout le monde, mais pas le fichier "secret" qui ne contient que le mot de passe.
    -lecture depuis l'entrée standard : cela impose certes un mode interactif, mais c'est la solution privilégiée lorsque l'on exécute le script manuellement.

    Et pour le reste, "keep up the good work"!

    • [^] # Re: Sécurité de la ligne de commande

      Posté par . Évalué à 7.

      Merci pour ce commentaire. Tu as effectivement bien résumé les éventuels moyens d'attaque. Mais il est important de rappeler que WinAdminPassword est un outil d'aide à l'administration et au déploiement des mots de passe. L'administrateur reste responsable de sa mise en oeuvre et de la protection de ses systèmes.

      Chacun choisira sa mise en oeuvre en fonction de ses besoins et notamment en terme de sécurité. En effet, comme tu l'indiques l'option --cron (Tâche plannifiée) n'est pas à déployer sur des systèmes sujets à des attaques. Ces derniers préféreront l'utilisation basique de WinAdminPassword, à savoir la génération et le déploiement des mots de passe lors de leurs installations, ce qui permettra de ne pas diffuser la clef secrète.

      Je vais donc ajouter ces conseils dans ma todo list :)

      • Possibilité de suppression de l'historique de la commande.
      • Possibilité de lecture des clefs secrètes depuis un fichier.
      • Possibilité de demander les clefs secrètes depuis l'entrée standard.

      Encore merci pour ces conseils :)

      A bientôt.

      Nico

      • [^] # Re: Sécurité de la ligne de commande

        Posté par . Évalué à 6.

        Ajoute à ta TODO liste:
        - enregistrer la clef dans un fichier accessible uniquement par root. Permet une utilisation sécurisée de WinAdminPassword par cron. (Ceci doit être optionnel, activable par une option sur la ligne de commande et/ou automatiquement lors de l'utilisation de "--cron")
        - à chaque utilisation, WinAdminPassword pourrait essayer de regarder dans ce fichier, sauf si un autre moyen est spécifié sur la ligne de commande.

        Quand à la "Possibilité de suppression de l'historique de la commande.", c'est quelque chose de difficile, qui est en plus très dépendant du shell utilisé. En plus ça n'empêchera pas les attaques de type "ps aux". Personnellement je pense que ça te fera perdre du temps pour une fausse impression de sécurité.

        Sinon, je trouve que WinAdminPassword est une idée intéressante :) Bonne continuation.

        • [^] # Re: Sécurité de la ligne de commande

          Posté par . Évalué à 1.

          Ou alors il faudrait que pour chaque utilisateur, la clef secrète soit enregistrée dans un fichier lisible uniquement par l'utilisateur en question. Ainsi lui seul peut changer le mot de passe (à l'aide de cron ou autre), et cela laisse la possibilité qu'il y ait plusieurs utilisateurs de WinAdminPassword en même temps.

        • [^] # Re: Sécurité de la ligne de commande

          Posté par (page perso) . Évalué à 2.

          En environnement linux durçi, il est tout à fait possible que seuls les processus appartenant à un utilisateur soient visibles.

          Système - Réseau - Sécurité Open Source

      • [^] # Re: Sécurité de la ligne de commande

        Posté par . Évalué à 2.

        Tout d'abord, félicitations pour ce projet intéressant.

        J'ai juste une remarque: Peut être serait il bon de ne pas promouvoir des exemples exposant a des attaques. La doc ou la page de man (ou le site web) pourraient par exemple signaler les limites de sécurité des commandes soulignées par kartnico?

        Quelque chose de plus pour la TODO list?

    • [^] # Re: Sécurité de la ligne de commande

      Posté par (page perso) . Évalué à -2.

      Comme ça ?

      winadminpassword --changepassword --user Administrateur --key "$(cat /root/firstkey)" --secondkey "$(cat /root/secondkey)" --length 12 --time --cron

  • # ...

    Posté par . Évalué à 10.

    J'ai du mal a voir l’intérêt du truc. C'est a utiliser dans quel cas d'usage. Server, machine d'utilisateur, ... ?

    Parce que c'est bien beau de mettre des mots de passe sur chaque machine, encore faut il que l'admin puisse s'y loguer. Et a moins de le faire a distance il faudra qu'il note le mdp quelque part.

    De plus si ça tourne sur un poste utilisateur, dès que l'on sait que ce soft est utilisé, on perd tout l'interet du truc. L'algo est connu et ca revient a mettre le mdp directement.

    De plus pourquoi ne pas utiliser les clefs rsa/dsa de ssh si les machines sont destiné à être administrée a distance (server) ?

    • [^] # Re: ...

      Posté par . Évalué à 7.

      Bonjour Matthieu,

      Je comprends ton retour et il prouve qu'il m'est important de bien documenter cet outil.

      Je vais répondre à tes questions dans l'ordre :

      J'ai du mal a voir l’intérêt du truc. C'est a utiliser dans quel cas d'usage. Server, machine d'utilisateur, ... ?

      Tu peux l'utiliser sur tous les systèmes que tu dois administrer, à distance ou non (Serveurs, Postes clients etc.).

      Parce que c'est bien beau de mettre des mots de passe sur chaque machine, encore faut il que l'admin puisse s'y loguer. Et a moins de le faire a distance il faudra qu'il note le mdp quelque part.

      Dans le cas d'une intervention physique, rien n'empêche à l'administrateur de soit imprimer le mot de passe (Sans faire référence à quoi que ce soit, puis de jeter le papier), soit de s'équiper d'un smartphone avec un accès sur son GLPI ou Interface sur laquelle se trouve WinAdminPassword.

      De plus si ça tourne sur un poste utilisateur, dès que l'on sait que ce soft est utilisé, on perd tout l'interet du truc. L'algo est connu et ca revient a mettre le mdp directement.

      Cela dépend de ta mise en œuvre. Si tu utilises cet outil avec l'option --cron (Tâche planifiée), effectivement l'algorithme utilisé et la clef sont stockés sur le système. En revanche si tu génères et déploies le mot de passe à l'installation de tes systèmes, il sera impossible de savoir quel algorithme et quelle clef secrète tu auras utilisé, si tu désinstalles l'outil après la génération des mots de passe. A noter qu'il existe un paramètre (--algo) te permettant de choisir ton algorithme.

      De plus pourquoi ne pas utiliser les clefs rsa/dsa de ssh si les machines sont destiné à être administrée a distance (server) ?

      De manière générale, dans l'administration des systèmes, c'est ce qu'il est conseillé de faire. Mais sur la plupart des systèmes, les comptes d'administration requiers quand même un mot de passe (Microsoft Windows, Fedora, OS400 etc.).

      En tous cas merci pour tes remarques, cela va me faire travailler sur la documentation de l'outil.

      A bientôt.

      • [^] # Re: ...

        Posté par . Évalué à 2.

        J'ai oublié de rappeler une chose

        De plus si ça tourne sur un poste utilisateur, dès que l'on sait que ce soft est utilisé, on perd tout l'interet du truc. L'algo est connu et ca revient a mettre le mdp directement.

        Si tu fixes le mot de passe, tu seras obligé de le sauvegarder quelque part. Donc pour X systèmes, tu auras X enregistrements dans ta base de données. Cela devient compliqué à administrer si tu as plus de 100 machines dans ton parc. C'est d'ailleurs pour cela que les grandes entreprises déploient le même mot de passe sur tous les comptes d'administration de leurs systèmes (Troll :p)

        L'avantage de l'outil WinAdminPassword, est qu'à partir d'une ou plusieurs clefs secrètes et d'un identifiant de la machine (Pour cette version il s'agit du numéro de série, mais dans une future version on pourra le choisir : nom d'hôte, adresse mac...), tu peux retrouver très facilement les X mots de passe.

        L'administration du changement des mots de passe de tout un parc est aussi simplifiée :

        Si un jour tu souhaites changer tous tes mots de passe (Clef secrète corrompue ou autre), tu n'auras pas besoin de récupérer ces derniers dans une base, de les changer, puis à nouveau de les noter dans ta base, mais simplement de créer un petit script se connectant sur tous tes systèmes, à partir de l'ancienne clef secrète, puis de les changer, via la nouvelle clef.

        • [^] # Re: ...

          Posté par . Évalué à 8.

          Si tu fixes le mot de passe, tu seras obligé de le sauvegarder quelque part. Donc pour X systèmes, tu auras X enregistrements dans ta base de données. Cela devient compliqué à administrer si tu as plus de 100 machines dans ton parc. C'est d'ailleurs pour cela que les grandes entreprises déploient le même mot de passe sur tous les comptes d'administration de leurs systèmes (Troll :p)

          les admins intelligents ne dpeloient pas le meme mot de passe sur les 100 machines d eleurs parcs,

          ils font en sorte que les machines se connecte à un annuaire, et c'est cet annuaire qui centralise le mot de passe.

          ce qui permet :
          1°) de la changer à volonté sans avoir à le redeployer
          2°) de fermer un compte quand un utilisateur quitte l'entreprise
          3°) de passer un utilisateur lambda admin d'un poste ou d'un groupe

          • [^] # Re: ...

            Posté par . Évalué à 7.

            Pour les comptes utilisateurs c'est exactement ce que je fais. Pour les comptes d'administration je ne vois pas comment tu fais si ton annuaire n'est plus accessible.

            • [^] # Re: ...

              Posté par . Évalué à 2.

              si je me souviens bien, pour windows, le log/pass d'un utilisateur qui s'est connecté une fois est mis en cache sur la machine

              sinon comment ferait-on avec les ordis portables des employés.

              et pour les linux et tous les OS qui acceptent SSH :
              1 mot de passe bien compliqué pour le compte root ou administrateur en local
              mais une clef SSH pour se connecter à distance

              ensuite si c'est pour se connecter en local, bah un liveCD permet de passer outre tout ca, donc comme d'hab quand on a accés à la machine, meme le meilleur des mots de passe ne sert à rien.

              • [^] # Re: ...

                Posté par . Évalué à 2.

                si je me souviens bien, pour windows, le log/pass d'un utilisateur qui s'est connecté une fois est mis en cache sur la machine

                Tu parles des comptes d'un domaine. L'objectif principal de WinAdminPassword est de s'attarder sur les comptes locaux d'administration (Administrateur, Administrator, root, *SECOFR...).

                1 mot de passe bien compliqué pour le compte root ou administrateur en local
                mais une clef SSH pour se connecter à distance

                Tu as tout à fait raison, et j'espère que tout le monde fait cela. Mais l'outil WinAdminPassword va t'aider à déployer des mots de passe uniques et les retrouver sans avoir à les noter.

                ensuite si c'est pour se connecter en local, bah un liveCD permet de passer outre tout ca, donc comme d'hab quand on a accés à la machine, meme le meilleur des mots de passe ne sert à rien.

                Encore faut-il en avoir un sous la main, et savoir l'utiliser. Mais je comprends ta remarque.

                Par ailleurs, un de mes objectifs est d'interfacer WinAdminPassword avec des outils de déploiement de configuration des BIOS (DELL, HP...), et ainsi déployer des mots de passe BIOS différents sur tout un parc.

        • [^] # Re: ...

          Posté par (page perso) . Évalué à 7.

          Si tu fixes le mot de passe, tu seras obligé de le sauvegarder quelque part. Donc pour X systèmes, tu auras X enregistrements dans ta base de données. Cela devient compliqué à administrer si tu as plus de 100 machines dans ton parc. C'est d'ailleurs pour cela que les grandes entreprises déploient le même mot de passe sur tous les comptes d'administration de leurs systèmes

          Si le mot de passe déployé à l'identique sur toutes les machines est trop simple, il est cassable. Ça ok. WinAdminPassword apporte une bonne complexité, mais bien d'autres méthodes plus simples existent.

          Si le mot de passe est complexe, il n'est pas cassable. Qu'il soit identique sur toutes les machines ou pas. Et si on prétend qu'il est cassable, alors la clef secrète de WinAdminPassord l'est également. De ce côté WinAdminPassword n'apporte rien.

          Si le mot de passe est identique sur toutes les machines, et qu'une personne en prend connaissance, elle a accès à toutes les machines. De ce côté WinAdminPassword apporte une bonne parade.

          Reste que pour se connecter localement, c'est galère, mais ça devrait rester bien rare (sauf si on n'utilise pas Active Directory, ou un bon client ssh, etc).

          Reste également que le mot de passe des administrateurs Active Directory sont utilisables depuis tous les postes. Ces mots de passe sont souvent bien plus faibles que ceux générés par WinAdminPassword car il faut se les palucher plusieurs fois par jour. Pour contrer cela, rien de mieux que l'authentification forte.
          De ce côté WinAdminPassword n'apporte rien.

          La bonne méthode reste encore et toujours la surveillance (automatisée) des tentatives de connexion. Ça te préviens lorsqu'un gugus tente de pénétrer la protection.
          Pas besoin d'un logiciel qui génère des mots de passe différents partout (retrouvables, jusqu'au jour où ça ne marche plus pour une raison non prévue).
          On accompagne ça du nécessaire pour changer régulièrement les mots de passe sur toutes les machines. A utiliser régulièrement contre les "erreurs humaines", mais lorsque le vers est dans le fruit, ça ne sert plus vraiment.

          • [^] # Re: ...

            Posté par . Évalué à 2.

            Ton commentaire est cohérent et il montre bien que WinAdminPassword n'est qu'un outil d'aide à l'administration, la gestion et le déploiement de ses propres mot de passe. Concernant tes méthodes plus simples qui existent, peux tu nous les citer ?

            A bientôt.

            • [^] # Re: ...

              Posté par (page perso) . Évalué à 2.

              Concernant tes méthodes plus simples qui existent, peux tu nous les citer ?

              Difficile de citer toutes les méthodes pour générer des mots de passe. Il y en a plein les dépôts. Ou du fait-main comme ça:

              TAILLE=25; for c in $(echo "obase=94; ibase=16; $(head -c $TAILLE /dev/urandom 2> /dev/null | xxd -p -u -c $TAILLE)" | \
              env BC_LINE_LENGTH=999 bc); do printf "%b" $(printf '\x%x ' $(expr $c + 33));done | cut --bytes=-$TAILLE
              
              • [^] # Re: ...

                Posté par . Évalué à 1.

                Je pensais que tu parlais d'autre chose.

                Oui effectivement des milliers de méthodes existent, mais avec celle présentée, cela ne t’empêchera pas de stocker les mots de passe générés dans une base, si tu dois un jour t'en resservir.

          • [^] # Re: ...

            Posté par (page perso) . Évalué à 1.

            Reste que pour se connecter localement, c'est galère, mais ça devrait rester bien rare (sauf si on n'utilise pas Active Directory, ou un bon client ssh, etc).

            Pour se connecter localement, est-ce que c'est possible d'opter pour un système à la PAM qui permet d'avoir une méthode d'identification plus légère (seulement pour l'identification locale).

            • [^] # Re: ...

              Posté par (page perso) . Évalué à 3.

              C'est possible. Dans ce cas le mot de passe est plus facilement trouvable, comme d'hab. D'autant plus facilement qu'il suffit de dupliquer le disque local pour rechercher les mots de passe bien au chaud chez soi.
              C'est donc contraire au but de ce logiciel.

          • [^] # Re: ...

            Posté par (page perso) . Évalué à 1.

            Si le mot de passe est complexe, il n'est pas cassable. Qu'il soit identique sur toutes les machines ou pas.

            Il me semble que sur Windows XP les mots de passe sont saucissonnés en morceaux de 7 caractères, et c'est chaque morceau qui est ensuite indépendemment chiffré par une clef enregistrée sur la machine afin de stocker la signature du mot de passe de chaque utilisateur, Administrateur local inclus. Il en résulte que la complexité des mots de passe de plus de 7 caractères est largement diminuée.

            Pour preuve certains outils sont capables de casser les mots de passe locaux de Windows XP en moins de 2 minutes grâce à des tables pré-calculées de quelques centaines de Mo (« rainbow tables »). Je ne sais pas si les versions suivantes de Windows ont bénéficié d'un algorithme mieux pensé :p.

  • # Adaptation

    Posté par . Évalué à 1.

    Ça pourrait être intéressant de faire une adaptation du logiciel pour en faire un générateur de mot de passe pour service Web. Genre au lieu de stocker tous ses mots de passe dans un machin chiffré, on pourrait les regénérer très facilement en ayant simplement l'URL du service et une clé de génération.

    • [^] # Re: Adaptation

      Posté par . Évalué à 2.

      Salut jlpipo,

      Il est effectivement aussi possible de jouer avec les paramètres. Voici un exemple qui permet de générer/retrouver ses mots de passe pour les services web que l'on utilise, sans avoir à les stocker dans un trousseau de clefs :

      winadminpassword --printpassword --serial "linuxfr.org" --key "My Very Secret Key!" --length 8
      winadminpassword --printpassword --serial "ovh.com" --key "My Very Secret Key!" --length 8
      

      -> Cette commande affichera mes mots de passe, d'une taille de 8 caractères, pour les sites "linuxfr.org" et "ovh.com". Ainsi, à partir d'une clef secrète unique, et d'identifiants simples à mémoriser, il me sera possible de générer des mots de passe différents et de les retrouver, pour tous les services web que j'utilise.
      ! Il est simplement important de se souvenir de sa clef secrète et des noms entrés dans le paramètre --serial.

      WinAdminPassword fonctionne avec de multiples variables et paramètres, qui permettent ainsi de choisir sa mise en oeuvre. Il est donc tout à fait possible de créer une interface Web, de récupérer des variables de type GET et de les envoyer en tant que paramètres à WinAdminPassword.

      C'est aussi pour cela que WinAdminPassword est open source. Car pour ceux qui auront l'occasion de lire le code, l'idée ne tient que sur 4 lignes, elle est donc très facilement portable.

    • [^] # Re: Adaptation

      Posté par (page perso) . Évalué à 2.

      Ça pourrait être intéressant de faire une adaptation du logiciel pour en faire un générateur de mot de passe pour service Web

      Ça existe déjà. Un article ou journal est passé à ce sujet sur ce site.

  • # algorithme

    Posté par (page perso) . Évalué à 2.

    Petite question : quel est l'algorithme qui permet de passer d'un n° de serie + une clé a un mot de passe complexe et unique ?
    Autre petite question : l'auteur a t il prevu d'integrer son projet d'une facon ou d'une autre (direct ou via plugin) a Keepass par exemple ?
    L'integration dans GLPI est deja tres interessante

    Petite reflexion : je vois bien ce genre d'outil tres utile pour le compte admin local des PCs d'un parc windows. Je m'explique : quand on deploie des PCs windows, on doit mettre un mot de passe au compte admin local et c'est toujours gonflant de decider si on met un mot de passe generique (avec le risque qu'il soit connu un jour et d'avoir le parc entier corrompu) ou mettre un mot de passe par machine mais entrainer la creation d'une base de mot de passe gigantesque et extremement casse-pieds a maintenir. Pour la gestion de ce compte admin local, on est aussi partagé entre l'envie de le desactiver et l'envie de le garder actif en cas de besoin. Bref, ce compte est vraiment une plaie a gerer.
    Par contre, je vois difficilement l'interet de ce genre de solution pour les comptes utilisateurs ou les "comptes de domaine" (AD, LDAP, NIS, etc), me trompte je ?

    • [^] # Re: algorithme

      Posté par . Évalué à 4.

      Petite question : quel est l'algorithme qui permet de passer d'un n° de serie + une clé a un mot de passe complexe et unique ?

      En gros :

      $HASH="$KEY$SERIAL";
      $PASSWORD=SHA1BASE64($HASH);
      

      A noter qu'il est possible de choisir la méthode de génération du hash via le paramètre --algo (ou en modifiant le code source).

      Autre petite question : l'auteur a t il prevu d'integrer son projet d'une facon ou d'une autre (direct ou via plugin) a Keepass par exemple ?
      L'integration dans GLPI est deja tres interessante

      Je n'ai pas prévu d'intégrer cela dans un quelconque outil. Mais en fonction des besoins/pertinences des demandes, je peux m'y aventurer :)

      Petite reflexion : je vois bien ce genre d'outil tres utile pour le compte admin local des PCs d'un parc windows. Je m'explique : quand on deploie des PCs windows, on doit mettre un mot de passe au compte admin local et c'est toujours gonflant de decider si on met un mot de passe generique (avec le risque qu'il soit connu un jour et d'avoir le parc entier corrompu) ou mettre un mot de passe par machine mais entrainer la creation d'une base de mot de passe gigantesque et extremement casse-pieds a maintenir. Pour la gestion de ce compte admin local, on est aussi partagé entre l'envie de le desactiver et l'envie de le garder actif en cas de besoin. Bref, ce compte est vraiment une plaie a gerer.
      Par contre, je vois difficilement l'interet de ce genre de solution pour les comptes utilisateurs ou les "comptes de domaine" (AD, LDAP, NIS, etc), me trompte je ?

      Non non, tu as tout à fait raison ! J'ai créé cet outil dans un but de générer/changer les mots de passe pour les comptes locaux d'administration. Mais il est quand même possible d'utiliser WinAdminPassword comme un simple générateur de mot de passe. Voici un exemple :

      winadminpassword --printpassword --serial "login" --key "My Very Secret Key!" --length 7
      

      Nous allons ainsi générer un mot de passe différents pour tous nos comptes. C'est très pratique dans le cas où ta mise en oeuvre impose à l'utilisateur de changer son mot de passe à la première ouverture de sa session. Ainsi, si l'utilisateur perd son mot de passe avant sa première connexion, l'administrateur pourra le retrouver et lui envoyer très facilement.

      Concernant la mise en oeuvre sur ton parc Microsoft Windows, voici un exemple qui pourra t'aider :

      1 - Installation des machines (Avec WinAdminPassword).
      2 - Lancement de Sysprep (Configurer le fichier de réponses de sorte à lancer WinAdminPassword au premier démarrage) .
      3 - Clonage des machines.
      4 - Ainsi, au premier démarrage des machines, les comptes d'administration se verront attribuer un mot de passe unique, que tu pourras retrouver sans avoir à les sauvegarder dans une base.

    • [^] # Re: algorithme

      Posté par . Évalué à 1.

      J'ai oublié d'ajouter la commande à lancer par ton Sysprep :

      winadminpassword --changepassword --length 18 --user "local.admin" --key "Your Very Secret Key!"
      

      Cela va générer un mot de passe unique, de 18 caractères, pour chacun de tes comptes locaux d'administration nommés "local.admin".

      Pour répondre à ta remarque suivante :

      Pour la gestion de ce compte admin local, on est aussi partagé entre l'envie de le desactiver et l'envie de le garder actif en cas de besoin. Bref, ce compte est vraiment une plaie a gerer.

      Rien n'empêche de lui appliquer un mot de passe, même s'il est désactivé. Par contre s'il est désactivé, et que tu n'as pas d'autre compte local d'administration, je ne sais pas comment cela fonctionne en cas de démarrage en mode "secours" (recovery mode).

      A bientôt.

      Nico

  • # À propos de mots de passe sûrs…

    Posté par (page perso) . Évalué à 8.

    • [^] # Re: À propos de mots de passe sûrs…

      Posté par . Évalué à 1.

      Très intéressant. Mais il faut avoir une très bonne mémoire quand on a beaucoup de mots de passe :)

      Par contre il peut être envisageable de créer une option permettant de générer des phrases secrètes, certes incompréhensibles, mais qui pourra augmenter la complexité des mots de passe générés.

    • [^] # Re: À propos de mots de passe sûrs…

      Posté par (page perso) . Évalué à 5.

      Ce n'est pas tout à fait vrai dans le cas d'attaque par dictionnaire.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: À propos de mots de passe sûrs…

        Posté par (page perso) . Évalué à 3.

        Relis la planche : il considère justement des attaques par dictionnaire, lorsqu'il compte le nombre de mots possibles.

        • [^] # Re: À propos de mots de passe sûrs…

          Posté par (page perso) . Évalué à 3.

          Les attaques par dictionnaire, c'est un peu plus évolué que de lire le dictionnaire, c'est de se basé sur les mots couramment utilisés dans les mots de passe, notamment grâce à des attaques comme celles qu'à vécu Sony.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: À propos de mots de passe sûrs…

            Posté par . Évalué à 1.

            Tu peux rajouter un mot d'argot professionnel ou que tu utilises avec des amis, mais qui n'existe pas dans la majorité des dictionnaires. Difficulté pour l'ordinateur +++.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.