Gestion centralisée de mots de passe

[Booster2ooo]

Bonjour les n-pers,

Une question me taraude depuis quelques temps, question qui vous sera peut-être familière.

En effet, au travail, on rencontre souvent la problématique des mots de passes. "C'est quoi déjà le mot de passe pour tel service?" est une question récurrente. S'en suit des échanges par oral, IM ou email. Ces deux derniers cas (les plus fréquents, je dois l'avouer) me semblent être une très mauvaise pratique vu le peu de sécurité qu'ils prodiguent.

J'ai donc en tête de développer un outil qui permettrait d'éviter de perdre du temps à rechercher un mot de passe et le sécuriser en évitant de le communiquer des des canaux faibles. J'aimerais centraliser les mots de passes, chiffrés, sur un(des?) serveur(s) qui ne seraient accessible que par certains utilisateurs selon leurs droits/groupes. Par contre, le concept me semble quand même risqué. Si quelqu'un pénètre le serveur, bingo, harvest time, il a accès à tous nos serveurs/services, scénario catastrophe.

Quelle serait, selon vous, la meilleure méthodologie à mettre en place et sécurisé un tel service ? Quels seraient vos conseils ? Ou de manière général, quelle serait votre solution face à ce problème de mots de passes ?

Merci d'avance pour votre aide ou votre point de vue.

PS: j'ai ouvert un topic sur irclogs pour ceux qui veulent suivre ce qui s'est dit sur IRC

[Commodor]

Je répondrai plus en détails en rentrant du boulot car j'ai bossé sur ce genre de service En attendant tu peux regarder du coté de l'échange de secret de shamir et/ou les séquestres

[Booster2ooo]

Merci Commodor, j'attends ton insight avec impatience. Je me suis vaguement penché sur GPG cette après-midi mais je n'ai pas encore une idée claire sur l'archi que je pourrais monter avec.

[Commodor]

Par contre, le concept me semble quand même risqué. Si quelqu'un pénètre le serveur, bingo, harvest time, il a accès à tous nos serveurs/services, scénario catastrophe.

Bingo comme tu dis le problème de cette solution, c'est que cela crée un "single point of failure".

Je pense qu'il faut voir le problème plus en amont. Chaque service à son mot de passe (bdd, root, etc). Partant de là, la sécurité est déjà faible. Un employé licencié aura toujours le mot de passe de différents services. Un administrateur menacé avec une arme divulguera le mot de passe (bon on est dans des cas extrêmes, mais sur certains serveurs (dns, banque) ce paramètre est à prendre en compte). Bon j'imagine que dans votre cas, il n'y pas de menaces externes ou internes (confiance en tes collègues).

Pour revenir plus sur "l'outil", faudrait avant tout essayer d'éclaircir au maximum les contraintes. Au final les mots de passes pourraient tout simplement être contenues dans un fichier chiffré (la clé étant protégée par une passphrase) Si en plus c'est du ssh derrière ça peut faire l'affaire. Si tu es sur Linux tu peux jouer avec PAM et remplacer l'authentification du service ou du serveur par un compte LDAP par exemple quand c'est possible

[Booster2ooo]

Linux, c'est quoi ça ? :')

Plus sérieusement, on est sous environnement Windows mais je ne sais pas encore si le serveur qui aura la lourde tâche de garder nos pw sera Win ou Linux.

Merci pour avoir partagé ton expérience, je reviendrai pas ici quand j'aurai une vue un peu plus complète de l'articulation du projet.

[otherflow]

Bonjour Booster2ooo,

La gestion des mots de passe est une source de réflexions qui n'as pas encore débouché, à ma connaissance, sur une solution 100% fiable dévoilé publiquement.

Je me permet de te répondre en faisant la synthèse des éléments qui ont été exposés sur IRC.

1. Les conteneurs de mots de passes

01/10/2015 10:47:44 | Aniem > il me semble que keepass permet de s'échanger des mots de passes

Comme la évoqué Aniem sur IRC, les solutions de conteneurs de mots de passes telle que keepass, un outils multi-plateforme, sont les solutions communément utilisées pour la gestion des mots de passe.

1.2. Les Inconvénients

01/10/2015 10:48:57 | Booster2ooo > Aniem > keepass je l'ai utilisé 1x, j'ai perdu mon fichier master key, db à la poubelle :'D

Par contre, le concept me semble quand même risqué. Si quelqu'un pénètre le serveur, bingo, harvest time, il a accès à tous nos serveurs/services, scénario catastrophe.

Bingo comme tu dis Tongue le problème de cette solution, c'est que cela crée un "single point of failure".

Mais comme tu l'as évoqué sur IRC et dans ta réponse à Commodor, un conteneur de mots de passe est soumis à la contrainte du mot de passe et/ou de la clé permettant de protéger les mots de passes stocké dans ce dernier. La perte, de ce ou ces derniers, rend l'ensemble des mots de passes inaccessibilités et la déduction ou le vole, de ce ou ces derniers, rends l'ensemble des mots de passes accessibles. Les éléments que sont la clé et le mots de passe sont de voûte de cette solution de gestion de mots de passe.

2. La stratégie d'expiration de mots de passes

1.2. L'automatisation du changements des mots de passes lors de l'expiration

01/10/2015 10:53:16  |   Aniem  > keepass sait gerer \o/
01/10/2015 10:53:15  |   GreenBlood  > 
01/10/2015 10:53:15  |   GreenBlood  > Booster2ooo: crontab => passwd => $RANDOM
01/10/2015 10:52:48  |   Booster2ooo  > le top du top, ce serait même que le système change les mots de passes tous les X temps

Comme il a été indirectement évoquée sur IRC par le trio Le trio Booster2ooo, GreenBlood et Aniem, une stratégie de gestion de mots de passe avancée se doit de prendre en considération l'expiration des mots de passes. Une solution rotation automatique des mots de passes est-elle envisageable ?

Comme l'a dis Aniem, le système de génération de mots de passe proposé par certain compteur de mots de passe, telle que keepass peut être un élément de départ.

3. La gestions de l'accès multi-utilisateurs

Dans un contexte multi-utilisateurs : entreprises, associations, groupes de travail, etc.... La question du partage d'accès au système de stockage de mot de passe entre plusieurs utilisateurs est une contrainte à prendre en considération. En effet durant leurs tache informatique, ces utilisateurs peuvent partager la même ressources et donc avoir besoin du même lots de mots de passe.

3.1. Le chiffrement asymétrique

01/10/2015 10:57:02 | GreenBlood > (et qui plus est de sécuriser le stockage des pw)
01/10/2015 10:56:46 | GreenBlood > ça permettrait de limiter qui accède à quoi
01/10/2015 10:56:39 | GreenBlood > Et que les mots de passe étaient chiffrés par les clés privées de chacune de ses clés
01/10/2015 10:56:21 | GreenBlood > Et sinon pour ta problématique, ça serait peut être un peu lourd mais si chaque personne avait une paire de clé

Dans un contexte multi-utilisateurs : entreprises, associations, groupes de travail, etc.... La question du partage d'accès au système de stockage de mot de passe entre plusieurs utilisateurs est une contrainte à prendre en considération. En effet durant leurs tache informatique, ces utilisateurs peuvent partager la même ressources et donc avoir besoin du même lots de mots de passe. GreenBlood, a évoqué la possibilité de sécurisation des échange des mots de passe par chiffrement à clé publique.

01/10/2015 10:57:32 | GreenBlood > Bah LastPass permet ça

GreenBlood a aussi évoqué la solution LastPast et la possibilité que ce projet offre en permettant ce type d'échange sécurisé.

01/10/2015 10:58:38 | Booster2ooo > j'ai pas trop confiance en les third parties alors encore moins quand il s'agit de données aussi sensibles ^^

Mais Booster2ooo a mis en avant le fait que ce type de solution induit une toute confiance pour les tiers auxquels les utilisateurs confient leurs mots de passes. En effet, ces solutions imposent de fournir à une entité extérieur des données de sécurité sensible.

3.2. Combinaison de chiffrement asymétrique et de chiffrement symétrique

01/10/2015 11:00:40 | Booster2ooo > mais de l'asym quand ils sont request qqch comme ca
01/10/2015 11:00:25 | Booster2ooo > je pensais à du symétrique pour la sérialisation des mdp, quand ils sont sauvés en dur

Puis Booster2ooo a fait l'ébauche d'une solution utilisant le chiffrement symétrique pour le stockage des mots de passe et le chiffrement asymétrique afin de permettre la mise à disposition des mots de passe lors d'une demande d'un utilisateur.

01/10/2015 11:04:17 | GreenBlood > Dans ma tête j'avais une archi à la GPG dans la tête tu vois
01/10/2015 11:02:23 | GreenBlood > tu peux l'ajouter à la "base"
01/10/2015 11:02:18 | GreenBlood > T'as sa clé publique à l'autre pignouf
01/10/2015 11:02:09 | GreenBlood > Pour lui partager

GreenBlood a complété l'idées de gestion sécurité du multi-accés par une solution de gestion de mots passe par chiffrement symétrique, en proposant une architecture liée une base de données contenant les clés publiques des utilisateurs, ces clés publiques permettant de sécurisé les échanges entre la zone de stockage sécurisée et les utilisateurs.

3.3 Etude critique des méthodes chiffrements évoquées

Le chiffrement asymétrique :

01/10/2015 11:13:10 | Booster2ooo > un mot de passe c'est très petit
01/10/2015 11:13:01 | Booster2ooo > la taille des données à chiffrer ici est vraiment irrelevent
01/10/2015 11:12:40 | GreenBlood > pas en sym/flux
01/10/2015 11:12:34 | GreenBlood > TsT: de toute façon, l'asymétrique on est limité dans la taille de données à chiffrer

Dans son étude critique du chiffrement asymétrique, GreenBlood à mis en avant la limitation quant à la taille des données chiffrées. Ce qui a permis à Booster2ooo de déterminer que la contrainte de taille d'un mot de passe n'était pas bloquante car ces derniers étant de petite taille.

Le chiffrement hybride basé sur PGP/GPG :

01/10/2015 11:15:17 | GreenBlood > et les utilisateurs ils ont qu'a utiliseur une passphrase (pour la clé privé) et pouf trotinette
01/10/2015 11:14:59 | TsT > tout comme le *ssl*
01/10/2015 11:14:46 | TsT > pgp/gpg ca repond a pas mal de problematique
01/10/2015 11:14:29 | GreenBlood > donc une archi pgp c'est plutôt adapté à sa problématique non ?

Le duo GreenBlood et TsT confirme qu'une architecture de basé sur PGP/GPG peut-être une solution intéressante pour une stratégie de gestion de mots de passe des utilisateurs.

Voici la synthèse de la conversation IRC du 10 Octobre 2015.

otherflow.

[GreenBlood]

T'es un grand malade @otherflow mais c'est propre merci de cette synthèse

[Booster2ooo]

Merci beaucoup pour la synthèse otherflow.

Le problème auquel je fais face avec GPG, c'est pour la "bidirectionnalité" des échanges. En effet, SERVER possède X clés publiques et tous les X USERS possèdent une clé privée + passphrase. Ainsi, SERVER peut chiffrer un mot de passe avec la clé publique de l'USER_Alice et USER_Alice peut le déchiffrer avec sa private key + passphrase. Par contre, j'ai cru comprendre que ça devenait plus problématique si USER_Alice venait à devoir envoyer un mot de passe à SERVER de manière chiffrée avec la même pair de clés. D'après ce que j'ai cru comprendre, c'est possible mais déconseillé. Il faudrait donc prévoir une autre paire...

02/10/2015 12:06:55  |   Booster2ooo > 11:39:10| <Windows> Dites, j'suis une douille mais est-ce que j'ai bien compris. Si A possède une clé publique, et B une clé privée. A peu chiffré un message que B déchiffre avec sa clé privée et sa passphrase, right ?
02/10/2015 12:06:55  |   Booster2ooo > 11:39:55| <Windows> et B peut "signer" avec sa clé privée (donc chiffrer aussi ?) un message que A peut dechiffrer avec la clé public ?
02/10/2015 12:07:51  |   MacYavel  > alors, oui, sur le principe
02/10/2015 12:08:03  |   MacYavel  > après tous les algorithmes ne sont pas adaptés aux deux
02/10/2015 12:08:44  |   MacYavel  > par exemple, RSA est une bijection entre le cleartext et le ciphertext
02/10/2015 12:09:04  |   MacYavel  > donc il est utilisable pour les deux, mais il faut jamais se servir de la même clef a la fois pour signer et pour chiffrer
02/10/2015 12:09:35  |   MacYavel  > sinon tu peux avoir certains scénarios genre tu prends un message sensé être confidentiel et tu convainc l'user de le signer et ça le révèle
02/10/2015 12:09:43  |   Booster2ooo > donc ca marche mais il faut pas le faire
02/10/2015 12:10:13  |   MacYavel  > ou, tu prends un message que tu veux signer, tu convainc l'user que c'est un message chiffré, il se plaint que le cleartext est incompréhensible en te joignant une copie et paf, tu as une signature valide
02/10/2015 12:10:28  |   MacYavel  > tu peux le faire mais avec une paire séparée par role
02/10/2015 12:11:06  |   Booster2ooo > ouai mais si t'as besoin d'une deuxieme pair de clé, autant donné la public quoi, non?
02/10/2015 12:11:31  |   MacYavel  > non mais c'est pas la question
02/10/2015 12:11:36  |   Booster2ooo > A[pub1] --> B[priv1] et B[pub2] --> A[priv2]
02/10/2015 12:11:38  |   Booster2ooo > ah?
02/10/2015 12:12:05  |   Booster2ooo > Pour moi, le but était d'utiliser une pair de clé dans les deux sens quoi
02/10/2015 12:12:20  |   MacYavel  > oui ben donc non il faut pas
02/10/2015 12:12:36  |   MacYavel  > d'ailleurs pgp fait comme ça
02/10/2015 12:12:42  |   MacYavel  > la clef principale elle sert qu'a signer
02/10/2015 12:12:42  |   Booster2ooo > en gros, pour communiquer avec un serveur, que le serveur envoie les données chiffrées avec la clé pub du client et que le client envoie avec des messages signés ....
02/10/2015 12:13:06  |   MacYavel  > et y'a une subkey, signée par la principale, qui sert a chiffrer
02/10/2015 12:14:17  |   MacYavel  > si tu voulais confidentialité et authentication dans les 2 sens, faut 4 paires de clefs en tout
02/10/2015 12:14:27  |   MacYavel  > c'est pour ça qu'en pratique personne fait ça
02/10/2015 12:15:52  |   MacYavel  > on fait pas de chiffrement, on fait que faire un echange diffie-hellman signé dans les deux sens, et puis on utilise la clef dérivée avec un chiffrement symétrique
02/10/2015 12:15:52  |   Booster2ooo > Ok :/
02/10/2015 12:15:58  |   MacYavel  > et donc pour finir mon raisonnement
02/10/2015 12:16:15  |   MacYavel  > Elgamal par exemple, n'est pas une bijection
02/10/2015 12:16:17  |   Booster2ooo > bon, je comprends tjs rien :'D
02/10/2015 12:16:35  |   MacYavel  > donc tu peux pas l'utiliser pour une signature, seulement pour un chiffrement
02/10/2015 12:16:41  |   Booster2ooo > je vais devoir relire le manuel GPG :')
02/10/2015 12:17:21  |   MacYavel  > et DSA n'est pas une bijection non plus, y'a une fonction de hachage dedans, donc c'est seulement utilisable pour la signature mais pas pour le chiffrement
02/10/2015 12:24:43  |   Booster2ooo > Bon, je suis pas avancé quoi :/
02/10/2015 12:25:18  |   Booster2ooo > MacYavel > si, par exemple, je voulais faire un chat chriffré, GPG serait pas une bonne idée donc?
02/10/2015 12:25:29  |   Booster2ooo > chat multipoint, comme un channel ici
02/10/2015 12:28:54  |   MacYavel  > ça serait horriblement lourd
02/10/2015 12:29:09  |   MacYavel  > et puis ça dépend de ce que tu veux garantir comme sécurité
02/10/2015 12:29:18  |   MacYavel  > typiquement la signature c'est pas forcément une bonne chose
02/10/2015 12:29:24  |   MacYavel  > des fois t'as envie de pouvoir nier que t'as dit qqch
02/10/2015 12:33:54  |   Booster2ooo > c'est en relation avec ce projet: http://n-pn.fr/forum/showthread.php?tid=3854

[gruik]

LDAP (...) quand c'est possible

+1

[Booster2ooo]

Je déterre le sujet (j'ai malheureusement pas eu (pris) le temps de continuer mes recherches dans le domaine), je suis tombé ce matins sur un article présentant un outils qui me semble correspondre à la problématique soulevée: http://www.sflvault.org/

SFLvault is a Networked credentials store and authentication manager developed and maintained by Savoir-faire Linux.

It has a client/vault (server) architecture allowing encrypted storage and organization of a multitude passwords for different machines and services.

This website contains all the documentation for SFLvault. To keep track of its development please follow us on:

http://projects.savoirfairelinux.com/projects/sflvault
http://github.com/savoirfairelinux/sflvault

[otherflow]

Salut,

Merci Booster2ooo, cette solution a l'air intéressante.

A tester j'aurais envie de dire...

otherflow

[sakiir]

Bonjour tout le monde !

Ayant discuté récemment sur IRC du sujet avec Booster, je me suis permis de remonter le sujet avec une possible solution (bien qu'elle ne soit pas particulièrement safe, ca reste une solution).

Du coup, sans savoir qu'en 2015, Boost c'était lui aussi posé la question, j'ai eu l'idée de developper un tel projet.

J'ai été un peu plus vite, sans beaucoup réfléchir au sujet, parceque je savais ce que je voulais des le depart: Un gestionnaire de mot de passe sans synchro, avec des clients web, mobile, CLI && anyway.

Effectivement, pour un tel outils des problématiques de sécurité se posent !

J'ai commencé à dev, et j'ai une version beta qui fonctionne avec un example de client en python CLI.

Je serai très content si vous jetiez un coup d'oeil cela permettra peu etre de relancer le sujet sérieusement !


Voici les depot Github de la CLI et de l'API:

https://github.com/SakiiR/keehost
https://github.com/SakiiR/keehost-cli