Bonjour, Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
L'idéal étant un système client/serveur, pas de stockage en clair côté serveur et la possibilité de définir des droits par branche/dossier/forêt. Le tout sous Linux de préférence (client ET serveur). Avoir une double authentification basée sur un device (type clé USB) et un mot de passe serait un plus (mais je pense que je me contenterai d'un mot de passe).
J'avais une piste avec keepassx couplé à un owncloud (ça restait sur notre infra) mais il génère un lockfile qui nous empêche d'éditer depuis plusieurs postes simultanément.
J'ai aussi pleasant password manager mais c'est du full windows.
Pas grand chose de plus ...
Une idée ?
Merci, Julien
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Bon courage.
ClemClem
Le 10 mai 2013 à 14:59, "Julien Escario" escario@azylog.net a écrit :
Bonjour, Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
L'idéal étant un système client/serveur, pas de stockage en clair côté serveur et la possibilité de définir des droits par branche/dossier/forêt. Le tout sous Linux de préférence (client ET serveur). Avoir une double authentification basée sur un device (type clé USB) et un mot de passe serait un plus (mais je pense que je me contenterai d'un mot de passe).
J'avais une piste avec keepassx couplé à un owncloud (ça restait sur notre infra) mais il génère un lockfile qui nous empêche d'éditer depuis plusieurs postes simultanément.
J'ai aussi pleasant password manager mais c'est du full windows.
Pas grand chose de plus ...
Une idée ?
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/05/2013 15:06, Clem Clem a écrit :
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Ca sait faire du cryptage réversible ldap ? Parce que si on stocke en clair, bof et si on stocke crypter, il faut qu'il sache décrypter à partir du pass et/ou d'une clé bien planquée par un mécanisme X ou Y.
Non ?
Julien
Le 10 mai 2013 à 15:10, Julien Escario a écrit :
Le 10/05/2013 15:06, Clem Clem a écrit :
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Ca sait faire du cryptage réversible ldap ? Parce que si on stocke en clair, bof et si on stocke crypter, il faut qu'il sache décrypter à partir du pass et/ou d'une clé bien planquée par un mécanisme X ou Y.
Non ?
OpenLDAP c'est du SSHA en général, donc du hash salté. Le salt est encodé dans le contenu du pass stocké. En gros un mot de passe est stocké sous cette forme: salt . sha(salt . pass) Donc d'une part à aucun moment tu ne stockes le mot de passe en clair, tu ne peux pas non plus le reverser du fait de la construction, enfin c'est très chaud à brute-forcer puisque le salt est unique pour chaque mot de passe (pas d'attaque par dictionnaire possible). Le mot de passe ne passe en clair qu'entre le client et le serveur (une connexion TLS et c'est fini ! :) )
Sinon autre solution: authentification par clé SSH ou certificat (ce qui revient à peu près au même). Tu trouveras peu de choses aussi robuste !
Cordialement Emmanuel Thierry
Le 10/05/2013 15:53, Emmanuel Thierry a écrit :
Le 10 mai 2013 à 15:10, Julien Escario a écrit :
Le 10/05/2013 15:06, Clem Clem a écrit :
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Ca sait faire du cryptage réversible ldap ? Parce que si on stocke en clair, bof et si on stocke crypter, il faut qu'il sache décrypter à partir du pass et/ou d'une clé bien planquée par un mécanisme X ou Y.
Non ?
OpenLDAP c'est du SSHA en général, donc du hash salté. Le salt est encodé dans le contenu du pass stocké. En gros un mot de passe est stocké sous cette forme: salt . sha(salt . pass) Donc d'une part à aucun moment tu ne stockes le mot de passe en clair, tu ne peux pas non plus le reverser du fait de la construction, enfin c'est très chaud à brute-forcer puisque le salt est unique pour chaque mot de passe (pas d'attaque par dictionnaire possible). Le mot de passe ne passe en clair qu'entre le client et le serveur (une connexion TLS et c'est fini ! :) )
OK, merci pour l'explication. Je suis un peu light sur ldap. Par contre, d'après ce que tu dis, je peux authentifier avec LDAP mais pas stocker du password de manière sécurisée.
Sinon autre solution: authentification par clé SSH ou certificat (ce qui revient à peu près au même). Tu trouveras peu de choses aussi robuste !
On mets déjà de la clé et/ou certificat chaque fois qu'on peut mais sur de l'appli web, c'est quand même vite limité.
Finalement, je confirme : keepass 2 fait très bien le boulot pour nous. Double authentification (clé sur support USB + password), base stockée cryptée sur notre serveur owncloud, lui même hébergé sur notre infra, ça me paraît déjà plutôt solide. Il ne me reste plus qu'à faire une copie de sauvegarde d'une clé USB avec un fs lui même crypté et mettre ça au coffre. Après, ca va finir par être de la parano non ?
Julien
Le 10 mai 2013 à 16:13, Julien Escario escario@azylog.net a écrit :
Le 10/05/2013 15:53, Emmanuel Thierry a écrit :
OpenLDAP c'est du SSHA en général, donc du hash salté. Le salt est encodé dans le contenu du pass stocké. En gros un mot de passe est stocké sous cette forme: salt . sha(salt . pass) Donc d'une part à aucun moment tu ne stockes le mot de passe en clair, tu ne peux pas non plus le reverser du fait de la construction, enfin c'est très chaud à brute-forcer puisque le salt est unique pour chaque mot de passe (pas d'attaque par dictionnaire possible). Le mot de passe ne passe en clair qu'entre le client et le serveur (une connexion TLS et c'est fini ! :) )
OK, merci pour l'explication. Je suis un peu light sur ldap. Par contre, d'après ce que tu dis, je peux authentifier avec LDAP mais pas stocker du password de manière sécurisée.
Ah non, au contraire, c'est le plus sécurisé. c'est du hachage donc un alto non réversible. Lorsque tu vérifies le mot de passe, tu prends le mot de passe plaintext que l'utilisateur te donne, tu le hashes, et tu vérifies que le résultat est bien celui que t'as stocké. En gros tu n'as aucune méthode pour retrouver le mot de passe original à partir d'un SSHA, ça ne peut se faire que par brute-force (avec les clusters qui vont bien).
Sinon autre solution: authentification par clé SSH ou certificat (ce qui revient à peu près au même). Tu trouveras peu de choses aussi robuste !
On mets déjà de la clé et/ou certificat chaque fois qu'on peut mais sur de l'appli web, c'est quand même vite limité.
Finalement, je confirme : keepass 2 fait très bien le boulot pour nous. Double authentification (clé sur support USB + password), base stockée cryptée sur notre serveur owncloud, lui même hébergé sur notre infra, ça me paraît déjà plutôt solide. Il ne me reste plus qu'à faire une copie de sauvegarde d'une clé USB avec un fs lui même crypté et mettre ça au coffre. Après, ca va finir par être de la parano non ?
Bah le truc c'est que quelqu'un chope la clé et il a accès aux mots de passe. Le bon stockage de mot de passe ne doit idéalement pas être réversible. :)
Cordialement Emmanuel Thierry
Bonjour, je pense que vous n avez juste pas compris son besoin : centraliser les mots de passes (et non centraliser l auth), en ayant un mot de passe "maitre" permettant d acceder aux mots de passes stockes.
On 10/05/2013 16:25, Emmanuel Thierry wrote:
Le 10 mai 2013 à 16:13, Julien Escario escario@azylog.net a écrit :
Le 10/05/2013 15:53, Emmanuel Thierry a écrit :
OpenLDAP c'est du SSHA en général, donc du hash salté. Le salt est encodé dans le contenu du pass stocké. En gros un mot de passe est stocké sous cette forme: salt . sha(salt . pass) Donc d'une part à aucun moment tu ne stockes le mot de passe en clair, tu ne peux pas non plus le reverser du fait de la construction, enfin c'est très chaud à brute-forcer puisque le salt est unique pour chaque mot de passe (pas d'attaque par dictionnaire possible). Le mot de passe ne passe en clair qu'entre le client et le serveur (une connexion TLS et c'est fini ! :) )
OK, merci pour l'explication. Je suis un peu light sur ldap. Par contre, d'après ce que tu dis, je peux authentifier avec LDAP mais pas stocker du password de manière sécurisée.
Ah non, au contraire, c'est le plus sécurisé. c'est du hachage donc un alto non réversible. Lorsque tu vérifies le mot de passe, tu prends le mot de passe plaintext que l'utilisateur te donne, tu le hashes, et tu vérifies que le résultat est bien celui que t'as stocké. En gros tu n'as aucune méthode pour retrouver le mot de passe original à partir d'un SSHA, ça ne peut se faire que par brute-force (avec les clusters qui vont bien).
Sinon autre solution: authentification par clé SSH ou certificat (ce qui revient à peu près au même). Tu trouveras peu de choses aussi robuste !
On mets déjà de la clé et/ou certificat chaque fois qu'on peut mais sur de l'appli web, c'est quand même vite limité.
Finalement, je confirme : keepass 2 fait très bien le boulot pour nous. Double authentification (clé sur support USB + password), base stockée cryptée sur notre serveur owncloud, lui même hébergé sur notre infra, ça me paraît déjà plutôt solide. Il ne me reste plus qu'à faire une copie de sauvegarde d'une clé USB avec un fs lui même crypté et mettre ça au coffre. Après, ca va finir par être de la parano non ?
Bah le truc c'est que quelqu'un chope la clé et il a accès aux mots de passe. Le bon stockage de mot de passe ne doit idéalement pas être réversible. :)
Cordialement Emmanuel Thierry
Liste de diffusion du FRsAG http://www.frsag.org/
ClemClem
Le 10 mai 2013 à 16:13, "Julien Escario" escario@azylog.net a écrit :
Le 10/05/2013 15:53, Emmanuel Thierry a écrit :
Le 10 mai 2013 à 15:10, Julien Escario a écrit :
Le 10/05/2013 15:06, Clem Clem a écrit :
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Ca sait faire du cryptage réversible ldap ? Parce que si on stocke en clair, bof et si on stocke crypter, il faut qu'il sache décrypter à partir du pass et/ou d'une clé bien planquée par un mécanisme X ou Y.
Non ?
OpenLDAP c'est du SSHA en général, donc du hash salté. Le salt est encodé dans le contenu du pass stocké. En gros un mot de passe est stocké sous cette forme: salt . sha(salt . pass) Donc d'une part à aucun moment tu ne stockes le mot de passe en clair, tu ne peux pas non plus le reverser du fait de la construction, enfin c'est très chaud à brute-forcer puisque le salt est unique pour chaque mot de passe (pas d'attaque par dictionnaire possible). Le mot de passe ne passe en clair qu'entre le client et le serveur (une connexion TLS et c'est fini ! :) )
OK, merci pour l'explication. Je suis un peu light sur ldap. Par contre, d'après ce que tu dis, je peux authentifier avec LDAP mais pas stocker du password de manière sécurisée.
Ldap est un des trucs les plus sécurisés et utilisé que je connaisse, mais par contre est ce que cela repond vraiment a ton probleme je ne sais pas, car on (j'ai l'impression) a un peu de msl a comprendre le pbm dans sa globalité.
Sinon autre solution: authentification par clé SSH ou certificat (ce qui revient à peu près au même). Tu trouveras peu de choses aussi robuste !
On mets déjà de la clé et/ou certificat chaque fois qu'on peut mais sur de l'appli web, c'est quand même vite limité.
Finalement, je confirme : keepass 2 fait très bien le boulot pour nous. Double authentification (clé sur support USB + password), base stockée cryptée sur notre serveur owncloud, lui même hébergé sur notre infra, ça me paraît déjà plutôt solide.
Tes logins mot de passes securisés cryptes sur clé usb etc, servent a quoi ? Acceder aux comptes admin du client pour lequel tu boss ? Par exemple? Ldap est souvent utilisé 1/ pour ouvrir des sessions 2/ gerer l'annuaire 3/ gerer des acces fichiers sur la base de ton annuaire. Si c'est pour gerer des multi reseaux qui sont pas interconnectés, ca marche pas. (Ou en tout cas il faut minimum une infra pyramidale, avec une gestion centralisée chez toi, et un client chez chaque client).
Il ne me reste plus qu'à faire une copie de sauvegarde d'une clé USB avec un fs lui même crypté et mettre ça au coffre. Après, ca va finir par être de la parano non ?
Un bon sysadmin est par definition parano, sinon c'est pas un bon sysadmin <troll>, sinon c'est un dev, ou un user ^^</troll>
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/05/2013 17:09, Clem Clem a écrit :
Finalement, je confirme : keepass 2 fait très bien le boulot pour nous. Double authentification (clé sur support USB + password), base stockée cryptée sur notre serveur owncloud, lui même hébergé sur notre infra, ça me paraît déjà plutôt solide.
Tes logins mot de passes securisés cryptes sur clé usb etc, servent a quoi ? Acceder aux comptes admin du client pour lequel tu boss ? Par exemple? Ldap est souvent utilisé 1/ pour ouvrir des sessions 2/ gerer l'annuaire 3/ gerer des acces fichiers sur la base de ton annuaire. Si c'est pour gerer des multi reseaux qui sont pas interconnectés, ca marche pas. (Ou en tout cas il faut minimum une infra pyramidale, avec une gestion centralisée chez toi, et un client chez chaque client).
Mon besoin s'est de stocker de manière propre des mots de passe, parfois assez sensibles, en provenance d'infras très diverses et variées : des accès root/admin, des boites mails, des accès FTP, des accès sur des CMS, etc ... (pas de ssh, on ne fait que de la clé pour ça).
Il ne me reste plus qu'à faire une copie de sauvegarde d'une clé USB avec un fs lui même crypté et mettre ça au coffre. Après, ca va finir par être de la parano non ?
Un bon sysadmin est par definition parano, sinon c'est pas un bon sysadmin <troll>, sinon c'est un dev, ou un user ^^</troll>
On est d'accord MAIS un bon sysadmin doit aussi avoir des outils qui lui permettent d'être efficace ET rentable. Un peu de pragmatisme fait aussi du bien de temps à autre hein ;-) Le tout étant de définir le curseur ...
Julien
Bonjour
À une époque j'ai utilisé TeamPass. http://www.teampass.net/
Je crois que ça réponds à ton cahier des charges. Par contre je ne sais pas si c'est toujours vivant comme projet.
C'était avec plaisir, Emmanuel.
Le vendredi 10 mai 2013 15:06:36 Clem Clem a écrit :
Bonjour Julien,
Un login et mot de passe par utilisateur, Une gestion de groupe d'users, Un open ldap.
Ou je n'ai pas compris la question ? Ou il manque de infos/précisions?
Bon courage.
ClemClem
Le 10 mai 2013 à 14:59, "Julien Escario" escario@azylog.net a écrit :
Bonjour, Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
L'idéal étant un système client/serveur, pas de stockage en clair côté serveur et la possibilité de définir des droits par branche/dossier/forêt. Le tout sous Linux de préférence (client ET serveur). Avoir une double authentification basée sur un device (type clé USB) et un mot de passe serait un plus (mais je pense que je me contenterai d'un mot de passe).
J'avais une piste avec keepassx couplé à un owncloud (ça restait sur notre infra) mais il génère un lockfile qui nous empêche d'éditer depuis plusieurs postes simultanément.
J'ai aussi pleasant password manager mais c'est du full windows.
Pas grand chose de plus ...
Une idée ?
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/05/2013 15:12, Emmanuel MEYRIEUX a écrit :
Bonjour
À une époque j'ai utilisé TeamPass. http://www.teampass.net/
Je crois que ça réponds à ton cahier des charges. Par contre je ne sais pas si c'est toujours vivant comme projet.
C'était avec plaisir, Emmanuel.
Ah, merci. Ca pourrait correspondre. Seul bémol : faut un accès au net pour accéder aux pass. L'idéal eu été que l'on puisse avoir un mode déconnecté (quand on casse tout l'infra d'un client - pour faire mieux hein ;-)
Mais on a tous un accès 3G dans la poche aujourd'hui donc pourquoi pas.
Je vais tester keepass 2 qui semble ne plus utiliser de lockfile (merci Bastien) avec une base commune + une base par utilisateur.
A voir, merci pour vos pistes.
Julien
De notre côté après avoir eu du KeepassX et pas le Keepass 2 (marche pas bien sous Linux et Mac en gros version très orientée windows), le souci de lock n'était pas trop un souci on passe plus de temps à lire qu'à écrire. On synchronisait le tout avec Unison et on pouvait du coup garder une archive sur nos tel pour pouvoir les lire quand en déplacement (mais aucun ne propose de synchroniser ou alors sur des dropbox ou autre trucs non souverain à la boite).
On est passé sur Teampass MAIS on garde la base KeepassX en // car on a eu des misères avec Teampass, genre lors d'une mise à jour récente nos mot de passe (ceux de nos comptes d'accès) ont été recodé et impossible d'accéder à la plateforme, or ton mot de passe dévérouille les password codés dans la base donc on a perdu toute notre base. Néanmoins le projet vit et des versions sont proposées régulièrement.
On avait pensé coder un petit truc vite fait à base de fichier chiffré gpg et un accès ssh pour aller les lire mais on a pas poussé le concept très loin.
Le 10/05/2013 16:38, Wallace a écrit :
De notre côté après avoir eu du KeepassX et pas le Keepass 2 (marche pas bien sous Linux et Mac en gros version très orientée windows), le souci de lock n'était pas trop un souci on passe plus de temps à lire qu'à écrire. On synchronisait le tout avec Unison et on pouvait du coup garder une archive sur nos tel pour pouvoir les lire quand en déplacement (mais aucun ne propose de synchroniser ou alors sur des dropbox ou autre trucs non souverain à la boite).
Owncloud power ;-) Mes essais avec keepass2 depuis 2 jours montrent que les petits bugs d'affichages sous Linux ne sont pas franchement gênants. Et encore, ça semble dépendre de la distrib (sans avoir cherché plus loin).
On est passé sur Teampass MAIS on garde la base KeepassX en // car on a eu des misères avec Teampass, genre lors d'une mise à jour récente nos mot de passe (ceux de nos comptes d'accès) ont été recodé et impossible d'accéder à la plateforme, or ton mot de passe dévérouille les password codés dans la base donc on a perdu toute notre base. Néanmoins le projet vit et des versions sont proposées régulièrement.
Ca me stresse les applis web en php/mysql. L'exposition est vraiment trop importante et les failles sont légion. Bon, ca n'a pas l'air d'être joomla non plus et tes pass sont stockés cryptés mais tu ne sais jamais si un mec ne va pas pouvoir piquer ta session ou une autre blague ...
On avait pensé coder un petit truc vite fait à base de fichier chiffré gpg et un accès ssh pour aller les lire mais on a pas poussé le concept très loin.
C'est aussi une solution mais bon, j'ai environ 3 mois de boulot qui est plus prioritaire ;-) On verra entre noël et le nouvel an si je m'ennuie.
Merci pour tout vos retours, Julien
Le 11/05/2013 10:38, Julien Escario a écrit :
Owncloud power ;-) Mes essais avec keepass2 depuis 2 jours montrent que les petits bugs d'affichages sous Linux ne sont pas franchement gênants. Et encore, ça semble dépendre de la distrib (sans avoir cherché plus loin).
Hormis le problème d'affichage qui est déjà un gros frein, j'ai l'impression d'avoir une appli windows en wine. Keepass2 sur autre chose que du Windows n'est pas stable, je dois le relancer plusieurs fois dans la journée. Au début je pensais que j'avais perdu mon Keepass préféré en pensant que la montée de version avait tué tout le bénéfice et c'est à ce moment là que j'ai vu la différence entre Keepass2 et KeepassX.
Ca me stresse les applis web en php/mysql. L'exposition est vraiment trop importante et les failles sont légion. Bon, ca n'a pas l'air d'être joomla non plus et tes pass sont stockés cryptés mais tu ne sais jamais si un mec ne va pas pouvoir piquer ta session ou une autre blague ...
Alors pour aller plus loin dans le résonnement, mettre le tout en ligne n'est pas plaisant. On voulait pas non plus le mettre derrière un vpn car contraignant quand tu dois vite récupérer un pass. Du coup on a opté pour un site ssl avec authentification des clients par certificats. Ce qui bloque tout client anonyme. Pour ce qui est du php l'avantage c'est que si on doit forker c'est plus facile qu'un client lourd, donc pour nous un point positif.
Avoir une double authentification basée sur un device (type clé USB) et un
pour ce qui est du 2fa ( 2 factor auth ) , je recommande fortement yubikey, ca marche vraiment bien et c est vraiment simple :
pour le reste pas sur d avoir tout compris
Plop,
à mon précédent job, on utilisait 1Password (Windows, Mac, Linux avec Wine). Pour centraliser on avait un petit développement interne qui poussait tout dans un subversion, le format de stockage de 1Password se prête très bien à ça. L'avantage du subversion c'est qu'en cas de conflit (2 personnes qui modifient le même mot de passe en même temps), c'est que le dernier à commiter gagne, mais comme c'est versionné on peut revenir en arrière si nécessaire. Et puis y a un log qui permet de savoir qui créé/modifie/supprime un mot de passe.
Donc c'est accessible offline, mais synchronisé lorsque la connexion le permet.
Le Vendredi 10 Mai 2013 14:59 CEST, Julien Escario escario@azylog.net a écrit:
Bonjour, Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
L'idéal étant un système client/serveur, pas de stockage en clair côté serveur et la possibilité de définir des droits par branche/dossier/forêt. Le tout sous Linux de préférence (client ET serveur). Avoir une double authentification basée sur un device (type clé USB) et un mot de passe serait un plus (mais je pense que je me contenterai d'un mot de passe).
J'avais une piste avec keepassx couplé à un owncloud (ça restait sur notre infra) mais il génère un lockfile qui nous empêche d'éditer depuis plusieurs postes simultanément.
J'ai aussi pleasant password manager mais c'est du full windows.
Pas grand chose de plus ...
Une idée ?
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Julien Escario:
Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
Si les gens ont des clés GnuPG, Keyringer fait ça très bien : https://keyringer.sarava.org/
Salut,
Le 11 mai 2013 22:22, Lunar lunar@anargeek.net a écrit :
Julien Escario:
Une petite question du vendredi : est-ce que quelqu'un a une solution pour gérer du mot de passe en environnement de SSII quand on doit y avoir accès à plusieurs.
Si les gens ont des clés GnuPG, Keyringer fait ça très bien : https://keyringer.sarava.org/
Dans mon ancien taff, on utilisait des champs textes chiffrés par GnuPG qu'on mettait dans un wiki. C'était facilement gérable avec firepgp, jusqu'à ce qu'il disparaisse... Ça permettait de ne chiffrer que pour certaines clés, d'avoir tous les mots de passe centralisé, et de pouvoir les copier chiffrés en local si nécessaire.
Ensuite on a mis en place teampass, centralisé avec gestion par utilisateur, mais c'était bien moins convivial.
Actuellement, on utilise keepassx, ça permets d'avoir un trousseau de mots de passe dans un fichier chiffré déchiffrable avec mot de passe général, qu'on veut assez simple et qu'on communique oralement.
C'est multiplateforme et ça nécessite un client lourd, le plus gros problème étant que selon les "groupes" ayant droit à certains mot de passe, on créé plusieurs keepassx. Résultat j'en ai 4 ou 5 différents. Keepassx permet d'utiliser des "fichiers clé" mais je n'ai pas testé.
Je suis donc aussi preneur de quelque chose de centralisé, convivial, multiplateformes et avec de la gestion de droits.
-- Krion
-
Clem Clem -
Emmanuel MEYRIEUX -
Emmanuel Thierry -
Guillaume Friloux -
Julien Escario -
Lunar -
neo futur -
Romain LE DISEZ -
seb astien -
Wallace