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) :
bash
winadminpassword --changepassword --user Administrateur --key "My Very SecretKey" --length 12
3 Lancez la commande suivante sur les systèmes CentOS (Utilisez le compte root) :
bash
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 :
bash
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 :
bash
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
bash
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 :
bash
winadminpassword --changepassword --user Administrateur --password "MonMotdePasseUnique" --cron --verbose
4 L'exemple suivant permet d'afficher le numéro de série de l'ordinateur :
bash
winadminpassword --printserial
5 L'exemple suivant permet d'afficher la date et l'heure du système sous le format utilisé par WinAdminPassword :
bash
winadminpassword --printdate
Aller plus loin
- Site du projet (695 clics)
- Plugin GLPI (379 clics)
- Wiki (99 clics)
- Tracker (22 clics)
- Forum (74 clics)
- Sources (47 clics)
# A essayer !
Posté par frezi . É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 kartnico . Évalué à 2.
N'hésites pas à m'envoyer tes retours :)
A bientôt.
# Sécurité de la ligne de commande
Posté par goulou . É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 kartnico . É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 :)
Encore merci pour ces conseils :)
A bientôt.
Nico
[^] # Re: Sécurité de la ligne de commande
Posté par ziliss . É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 ziliss . É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 kartnico . Évalué à 1.
Ajouté dans la liste :)
Merci
Nico
[^] # Re: Sécurité de la ligne de commande
Posté par nono14 (site web personnel) . É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 djano . É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 kartnico . Évalué à 1.
Merci pour ta remarque. Je vais essayer d'en tenir compte sur la prochaine version et lors de la réalisation du site web.
Nico
[^] # Re: Sécurité de la ligne de commande
Posté par djano . Évalué à 2.
Oups je me suis trompé, je voulais dire les remarques de goulou :)
J’espère que c'est bien ce que tu avais compris.
[^] # Re: Sécurité de la ligne de commande
Posté par GEDsismik (site web personnel) . Évalué à -2.
Comme ça ?
[^] # Re: Sécurité de la ligne de commande
Posté par Michaël (site web personnel) . Évalué à 5.
Cela ne change rien au problème.
Les substitutions sont effectuées par le shell et apparaissent sur la ligne de commande. Ce qu'affiche
psest le vecteur des arguments du processus, pas la commande shell utilisée pour lancer le programme --- d'ailleurs un programme n'a aucune raison d'être lancé depuis un shell.[^] # Re: Sécurité de la ligne de commande
Posté par GEDsismik (site web personnel) . Évalué à 1.
Exact pour le ps. Mais déjà, tu résous les problèmes dans cron et dans bash_history.
[^] # Re: Sécurité de la ligne de commande
Posté par kartnico . Évalué à 3.
Plus comme ça :
[^] # Re: Sécurité de la ligne de commande
Posté par GEDsismik (site web personnel) . Évalué à 1.
Oui, j'avais compris. Mais avec les $() ou ``, on palie déjà au problème des .bash_history
[^] # Re: Sécurité de la ligne de commande
Posté par kartnico . Évalué à 1.
Effectivement. Si tu utilises la version 1.5. Merci pour ton exemple.
J'espère sortir rapidement la version 1.6.
A bientôt.
Nicolas
# ...
Posté par M . É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 kartnico . É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 :
Tu peux l'utiliser sur tous les systèmes que tu dois administrer, à distance ou non (Serveurs, Postes clients etc.).
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.
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 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 kartnico . Évalué à 2.
J'ai oublié de rappeler une chose
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 NeoX . Évalué à 8.
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 kartnico . É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 NeoX . É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 kartnico . Évalué à 2.
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...).
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.
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 Kerro . Évalué à 7.
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 kartnico . É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 Kerro . Évalué à 2.
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:
[^] # Re: ...
Posté par kartnico . É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 Michaël (site web personnel) . Évalué à 1.
Pour se connecter localement, est-ce que c'est possible d'opter pour un système à la
PAMqui permet d'avoir une méthode d'identification plus légère (seulement pour l'identification locale).[^] # Re: ...
Posté par Kerro . É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 Jean-Michel Philippe (site web personnel) . Évalué à 1.
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 jlpipo . É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 kartnico . É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 :
-> 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 Kerro . Évalué à 2.
Ça existe déjà. Un article ou journal est passé à ce sujet sur ce site.
[^] # Re: Adaptation
Posté par kartnico . Évalué à 2.
http://passwordmaker.org/
# algorithme
Posté par Nico C. . É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 kartnico . Évalué à 4.
En gros :
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).
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 :)
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 :
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 kartnico . Évalué à 1.
J'ai oublié d'ajouter la commande à lancer par ton Sysprep :
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 :
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
http://xkcd.org/936/
[^] # Re: À propos de mots de passe sûrs…
Posté par kartnico . É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 claudex . É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 🚲 Tanguy Ortolo (site web personnel) . É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 claudex . É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 oao . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.