Bonjour Nal,
Depuis peu, j'utilise des gestionnaires de mots de passe qui utilisent un format de fichier commun, et qui me permettent donc de partager la même archive aussi bien à la maison qu'au travail. Maintenant, le problème, c'est que cette archive des mots de passe, je dois la partager. J'ai pour l'instant quelques solutions en tête, et j'aimerais savoir ce que vous, mes moules paranoïaques préférées, vous faites ou feriez…
Les solutions actuelles sont :
- Stocker l'archive de mots de passe sur un clef USB, et la brancher/débrancher de l'ordi que j'utilise dès que j'ai besoin de me logguer quelque part.
- Stocker l'archive de mots de passe dans le cloud (eg, dropbox), et faire confiance au chiffrement de l'archive. C'est une solution courante je crois, mais des méchants pourraient cibler dropbox pour voler ces fichiers et attendre qu'une faille dans la crypto soit publiée pour casser les archives. Ca me fait un peu peur de laisser tous mes mots de passes, même chiffrés, dans le cloud.
- La même chose, mais avec du rot13 (ou autre) en plus, juste pour cacher un peu plus l'identité de l'archive.
- Stocker l'archive de mots de passe sur une machine accessible du net, mais qui n'est pas un stockage dans cloud, et coder mon petit client pour la synchro (avec rot13 au cas où). Je pense par exemple à un hébergeur quelconque, ou à une machine à la maison (mais ça ne me botte pas trop de me mettre un serveur à la maison 24/7 de nouveau…).
Alors, quelle est votre opinion ?
# Parano?
Posté par arnaudus . Évalué à 4.
Mouais, alors je comprendrais que tu hésites à mettre tes mdp en clair sur une Dropbox (au cas où la protection de la Dropbox serait cassée, ou que tu ne fasses pas confiance à Microsoft (quelle drôle d'idée)). Je comprendrais aussi que ça te fairait flippper d'avoir tes md chiffrées en téléchargement libre (HTTP?), même si le chiffrage est de bonne qualité, tu n'es pas à l'abri d'une faille. Honnêtement, le trouve que l'idée de péter la protection de la Dropbox puis de casser l'algo de chiffrage, c'est quand même se donner un mal de chien pour pouvoir troller à ta place sur Linuxfr… S'ils veulent tes mots de passe, les méchants vont venir te péter les genoux ou accéder physiquement à ta machine, c'est beaucoup plus facile et ça laisse moins de traces.
Je trouve que la solution impliquant un serveur perso est plus dangereuse que le cloud grand public, parce que les ressources dont tu disposes pour sécuriser ce serveur sont des milliers de fois moins importantes que celles des services de cloud (certes, tu es aussi moins une cible, mais quand même).
[^] # Re: Parano?
Posté par David Marec (site web personnel) . Évalué à 4.
Ça dépend de la carrure des méchants;
parce que la bande à jean-kevin , ils ne sont pas près de venir me péter quoi que ce soit.
J'ai un chat de garde.
Bof.
Je ne vois pas pourquoi. Sur mon serveur, je peux fermer les ports que je veux, n'autoriser que certaines zones ou IP, verrouiller les options des logiciels que j'installe, entre autre.
[^] # Re: Parano?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Un bon parano sait que le filtrage IP peut être bogué ou mal configuré, que le firmware de la carte réseau peut avoir une faille, que le firmware du modem/de la box peut avoir une faille, que le serveur est connecté au réseau électrique, que les papillons peuvent reconfigurer des serveurs en battant des ailes et que la mécanique quantique peut convertir ta distribution GNU/Linux en un Windows 3.11 for Workgroups même si c'est peu probable statistiquement. Sans parler des attaques par EMP. L'informatique c'est mort. Autant avoir un pont-levis et une lourde barre d'acier en travers la porte.
[^] # Re: Parano?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Et encore…
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Parano?
Posté par David Marec (site web personnel) . Évalué à 5. Dernière modification le 26 janvier 2016 à 11:54.
Ouaip, la barre, mieux vaut l'avoir dans la main pour la foutre en travers de la gueule des meuchants.
Faites gaffe quand même, les monsieurs vêtus de kevlar noir qui défonce la dite porte en pleine nuit, c'est des gentils, en fait.
[^] # Re: Parano?
Posté par Sufflope (site web personnel) . Évalué à 3.
Plus sérieusement l'argument de "au moins je suis sûr de la sécu" est un peu léger pour l'autohébergement…
Dropbox et les autres sont ptêtre pas parfaits, mais je leur fais confiance pour avoir une équipe payée pour ça, alors que le barbu qui veut me faire croire qu'il suit les CVE avec alertes en temps réel et procédure de mise à jour fiable, un Snort et pas juste un script qui ping…
[^] # Re: Parano?
Posté par arnaudus . Évalué à 2.
OK, c'est vachement plus crédible que la bande à Jean-Kévin vienne te péter ton chiffrement.
À mon avis, la bande à Jean-Kévin, si elle arrive à casser un chiffrement considéré comme sûr, c'est elle qui se fera péter les genoux par la NSA avant de pouvoir poster des photos de teub avec ton compte Twitter.
Après, tu peux ajouter des contraintes, style autohébergement. Ça peut se justifier pour plein de raisons, y compris pour ne pas être tributaire d'un service externe, avoir le contrôle de tes données, ou simplement pour jouer à l'Anonymous et à se fair peur tout seul. Mais il faut reformuler ta question, parce qu'elle avait l'air de demander une solution pragmatique.
# Solution 1
Posté par faureaxe (site web personnel) . Évalué à 10.
Bonjour !
Personnellement j'ai opté pour la solution 1 doublée d'un cryptage LUKS de toute la partition du disque dur externe.
Ça oblige à transporter le support sur soi régulièrement ceci dit, sur tous mes PC j'ai également une partition cryptée dans laquelle je copie l'archive de temps en temps pour essayer d'avoir tout à disposition même sans le disque. C'est très gérable.
# SyncThings ?
Posté par Flyounet (site web personnel) . Évalué à 6.
Je prends mon exemple :
- J'ai un keepass file que j'utilise pour ballader quelques comptes.
- SyncThings sur différentes machines dont certaines natées.
- SyncThings sur le téléphone (android).
Voilà, quand je change un compte dans le keepass file, ça le change partout.
Si tu en as le courage tu peux aussi changer/installer ton propre relay.
Pour ce qui est un peu plus sécure, seul le fichier chiffré est partagé par mon propre relay.
[^] # Re: SyncThings ?
Posté par Zatalyz (site web personnel) . Évalué à 7.
J'utilise aussi Syncthing pour ça. Je ne sais pas si c'est vraiment "sécu" (mon serveur local est probablement moins bien défendu que Dropbox, mais ensuite le fichier qui stocke les mots de passe est aussi chiffré). Mais c'est pratique et je garde le contrôle d'où ça traîne.
La difficulté est de trouver le compromis entre sécurité et confort d'utilisation : si ça devient trop contraignant, la flemmardise naturelle fait qu'on zappe et on finit par revenir aux post-it sur le bureau…
Les quelques mots de passe vraiment importants sont dans ma tête ; au final, si un jour mon fichier est cracké, ça servira surtout à troller sur divers services. Mais vu ma mémoire, les mots de passes importants ne sont sans doute pas suffisamment forts, et probablement pas changés assez régulièrement. Je ne suis pas sûre qu'une solution parfaite existe…
[^] # Re: SyncThings ?
Posté par Psychofox (Mastodon) . Évalué à 2.
Même solution ici. Syncthing fait le boulot et bien. Pour l'instant c'est mon smartphone qui hébèrge la seule copie à peu près toujours en ligne et à jour quand je suis là physiquement (et que je pense à en activer le wifi) mais j'envisage d'installer la version arm sur mon NAS.
Étant donné que je ramène mon laptop pro au minimum 4-5 fois par mois à la maison je ne prends même pas la peine de brancher mon smartphone au wifi pro quand je suis au bureau.
# pass
Posté par lockidor . Évalué à 7.
Pour ma part, pass, qui est un wrapper léger à GPG (pour le chiffrement des mots de passe) + git (pour la synchro). Et il y a même une extension Firefox pour les MdP web.
[^] # Re: pass
Posté par Ambroise . Évalué à 3.
Et une application sur Android
[^] # Re: pass
Posté par Glandos . Évalué à 2.
Sur mon ordinateur personnel, j'utilise
pass git pushqui pousse sur un serveur accessible en SSH. Et qui a la clé GPG.Au boulot, ou ailleurs, je fais un SSH vers ce serveur, et je fais des copier/coller. J'ai pas trouvé comment dire à l'extension Firefox de demander au serveur distant via un SSH déjà ouvert de récupérer le mot de passe, parce que justement, je veux éviter d'avoir des fichiers, même chiffrés, sur mon disque de boulot.
Y aurait moyen je pense, mais vu mon utilisation, j'ai pas pris le temps de le faire :)
[^] # Re: pass
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 26 janvier 2016 à 11:38.
J'ai pas étudié ta solution, mais peut-être avec sshfs ? Comme ça ton extension firefox croit que les fichiers sont locaux et tu ne stockes rien.
[^] # Re: pass
Posté par Glandos . Évalué à 1.
C'est pas bête :) Et c'est plus simple que de transférer les autorisations de GPG par des sockets ;)
[^] # Re: pass
Posté par barmic . Évalué à 3.
Fait gaffe à vraiment être parano, il faut s'assurer que tu n'utilise pas un éditeur de texte, un explorateur ou un navigateur qui stocke tout ou parti de ce fichier sur une partition en clair.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# EnPass
Posté par xuo . Évalué à 1.
Bonsoir,
Personnellement, j'utilise EnPass sur mon serveur Owncloud auto-hébergé. Par contre, il faut l'application cliente sur chaque PC/tablette, … à partir duquel on ve se connecter à la base de données.
Xuo.
# autohebergement
Posté par Nico C. . Évalué à 3.
Pas besoin de réinventer la roue pour la synchro vers un serveur, des solutions comme seafile ou btsync sont excellentes.
Sinon, un NAS type Synology propose le stockage et le client de synchro (cloudstation)
# why not ?
Posté par tafibo . Évalué à 10.
Pour ma pars c'est une archive keepass synchronisé par webdav sur un owncloud.
pour déverrouiller l'archive j'utilise une clef de cryptage que je transporte uniquement sur clef USB…
Si mon site est compromis, mon archive reste difficilement accessible… car sans la clef, l'archive ne s'ouvre pas.
[^] # Re: why not ?
Posté par steph1978 . Évalué à 2.
Idem.
# fichier chiffré comme a la maison
Posté par David Marec (site web personnel) . Évalué à 5.
J'utilise pour ma part un fichier chiffré par mes soins.
J'avais décrit la procédure dans un article sur feu diablotins.org.Je l'ai exhumée ci.
Sans entrer dans les détails, j'associe dans un fichier de type «csv» les identifiants à une localisation;
puis je chiffre le tout.
Pour le déchiffrer, j'utilise des alias tcsh et/ou des scripts shell.
En général, j'accède au fichier ( et aux commandes) depuis un serveur distant.
Pour être sûr de ne pas le paumer, il se trouve aussi stocké dans un cloud.
L'avantage est qu'il n'y a rien à installer, les scripts fonctionne de base sous un Linux ou un BSD.
Et, comme j'utilise i3 en tant que gestionnaire de fenêtre, j'ai juste une petite fenêtre en bande horizontale sous Firefox qui ne me sert qu'à chercher un mot de passe.
[^] # Re: fichier chiffré comme a la maison
Posté par steph1978 . Évalué à 3.
penser à utiliser shred pour supprimer les fichiers non chiffrés et les créer sur un RAMFS.
# code 128
Posté par Anonyme . Évalué à 2.
Je les imprime en code 128 sur des post it, du coup ce n est pas lisible sans lecteur de code barre, et cela n eveil pas les soupcon. J hesite avec du data matrix qui largement plus répandu et plus difficile a généré
[^] # Re: code 128
Posté par fabricius . Évalué à 1.
pas mal, mais n'importe quel smartphone doit savoir lire du code 128, non?
[^] # Re: code 128
Posté par Anonyme . Évalué à 2.
oui toutafé, le but n'est pas de le chiffrer mais de me le rendre dispo pour moi facilement, c'est une petite cachette :). après je n'ai pas écrit :
mots de passe banque : ÑXLPÌTyjÍ1bÓ
[^] # Re: code 128
Posté par cévhé . Évalué à 1.
un peu de (re)lecture
http://www.ebooksgratuits.com/pdf/edgar_poe_la_lettre_volee.pdf
[^] # Re: code 128
Posté par kantien . Évalué à 1.
La nouvelle est amusante, mais la fin m'a surpris. Le ministre D… est assurément plus rusé que le préfet G…, mais il n'a pas été assez finaud : la lettre, il aurait du la détruire. Foi de logicien !
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: code 128
Posté par Maclag . Évalué à 4.
Je confirme: ça n'ouvre pas son compte en banque!
----->[ ]
# Dropbox
Posté par bunam . Évalué à 0.
Je fais du 1Password (Mac OS X, iOS, Windows®) et synchronisé via Dropbox et je sers les fesses.
Aussi je fais attention de ne pas ouvrir trop souvent l'app sur Windows® (1P à prévu la saisie dans un bureau sécurisé)
Je suis sidéré qu'il n'y ait pas un vrai champ mot du passe sur Windows®. J'ai un outil de remplissage de texte et ce con vois ce que je tape dans les champs mot de passe.
Sur Mac OS X, j'ai le même genre d'outils et ils n’ont aucun accès à ce type de champs.
"L'icône avec deux points noirs apparaît lorsque Typinator ne peut pas voir ce que vous saisissez parce que votre ordinateur travaille en "mode clavier sécurisé". Typinator utilise un "contrôle des événements" qui permet de surveiller votre saisie. Pour des raisons de sécurité, Mac OS X désactive ce contrôle lorsque vous saisissez du texte dans un champ de recherche. Cependant, il existe quelques programmes qui activent le mode "clavier sécurisé" et ne le désactivent pas lorsqu'il n'y a plus de risque concernant la sécurité. Dans cette situation particulière, le mode "clavier sécurisé" a été activé par Safari."
Je ne sais pas si ce mode existe sur Linux. Je ne vais sous Linux qu'en mode commande. ;)
[^] # Mode clavier sécurisé
Posté par Arthur Accroc . Évalué à 3.
Oui, typiquement les gestionnaires de connexion l’utilisent, et xterm permet de l’utiliser aussi (il est activable depuis le menu obtenu avec Ctrl-bouton gauche), notamment pour le cas où l’on aurait besoin de taper des mots de passe depuis le terminal.
Les autres terminaux et applications ne le proposent pas, en comptant sur la sécurité qui empêche d’accéder à la session X du voisin (de nos jours, elle tient la route, mais il y a longtemps, elle n’était pas aussi avancée ni même en place, d’où l’utilité sur xterm), ou sous prétexte que certains keyloggers sont capables de l’outrepasser (je suppose que c’est le cas uniquement s’ils tournent sous le même utilisateur, en root ou peut-être depuis un utilisateur autorisé à accéder à la session X, par exemple par ssh -X, mais je n’ai pas plus d’info à ce sujet).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Dropbox
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 26 janvier 2016 à 07:02.
Je crois bien que sous X11 tu es vraiment tout nu… :/
Après si t’es direct sur le tty, ça devrait le faire. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Dropbox
Posté par El Titi . Évalué à 2.
Ici on ne parle que de solutions basées sur des fichiers encryptés. Existe-il une appli libre comme 1Password que l'on puisse auto-héberger ?
[^] # Re: Dropbox
Posté par Moonz . Évalué à 4.
Rien de pleinement satisfaisant à mon goût.
En appli bureau, la référence c’est KeepassX. Mais il s’intègre très mal avec le reste du monde, en particulier le navigateur, et c’est un fichier sur le disque, donc pas accessible de partout à moins de mettre en place une synchro avec un serveur web (ou un dropbox) à la main.
En appli Web, la référence c’est plutôt Teampass. Son interface est vraiment pourrie, il ne s’intègre pas dans le navigateur, et il ne chiffre pas les mots de passe dans tous les cas (et c’est pas vraiment clairement affiché/documenté quand il chiffre ou pas).
En moins connu mais supérieur à Teampass (AMHA), tu as gPass et (attention, auto-promotion éhontée) WKR. Dans les deux cas c’est stocké côté serveur, chiffré, et avec intégration dans le navigateur possible (extension Chrome/FF pour gPass, Greasemonkey pour WKR). Par contre t’as pas d’appli desktop à la 1Password.
[^] # Re: Dropbox
Posté par paco81 . Évalué à 0.
Je dirais que la référence c'est plutôt keepass. Je parle là de la version 2 utilisant les fichiers kdbx (format xml), qui est plus flexible que la version 1 (fichiers kdb binaires). La version 2 de keepassx supportant les fichiers kdbx est très récente et pas aussi avancée que keepass 2.
Son seul inconvénient me semble être la dépendance à mono sous linux et osx. En contrepartie, le même exécutable fonctionne partout. Pratique, sur une clé usb.
Il a des fonctionnalités très utiles qui ne sont pas inclues dans keepassx :
- synchronisation de fichiers
- plugins ! Pour ma part j'utilise KeeCloud pour synchroniser sur dropbox sans utiliser de client dropbox et KeeAgent (agent d'authentification ssh).
- système de triggers, qui permet par exemple de synchroniser sur dropbox à chaque enregistrement.
En termes de sécurité, keepass est aussi plus avancé.
À noter aussi, le projet keeweb (web app pour les fichiers kdbx) très jeune mais qui semble prometteur. Les fichiers sont hébergés en local ou sur dropbox.
# Git + keepassx
Posté par Trollgouin . Évalué à 4. Dernière modification le 26 janvier 2016 à 09:32.
Ma solution: un git privé qui partage qq fichiers dont un fichier keepassx protégé par une masterkey.
Inconvénients:
- Bien sûr, les mécanismes de merge de git sont sans intérêt sur un fichier chiffré: penser à bien synchroniser avant et après chaque modif.
- Git se fout des droits (lecture pour tout le monde): bien penser à protéger les répertoires en amont en cas d'attaque locale
- Il me faut un serveur accessible 24/7
Intérêts:
- J'utilise déjà pas mal Git pour de la synchro/sauvegarde, du coup pas un outil de plus à maintenir
- J'ai relativement confiance en Git pour la sécurité. Au pire, si mon Git est compromis, il me reste la masterkey.
- Même si le diff n'a aucun sens sur ma base de mots de passes, je bénéficie quand même de la possibilité de remonter une ancienne version de mes mots de passe (y compris si mon dépot local si l'origin n'est pas accessible).
- Je ne pose pas mes données sensibles sur la machine de quelqu'un d'autre.
ps: Comme notifié plus haut, keepass, c'est pas un champion de l'intégration automatique dans toutes les applis. Mais en pratique, ça ne me gêne pas trop (surtout des pass web et des accès via SSH avec des authorized key (pas besoin du pass)).
[^] # Re: Git + keepassx
Posté par Trollgouin . Évalué à 1.
Pour l'interaction Web/Keepass, il existe Keefox, un module firefox pour s'interfacer avec Keepass. Je n'ai jamais essayé.
PS: Je me réponds parce que je ne peux plus modifier le post: j'ai un joli logo de Gandalf qui m'interdit de passer en me prenant pour un Balrog alors que le bouton "Modifier" est présent. On a une limite du nombre de modifs / unité de temps sous LinuxFr?
[^] # Re: Git + keepassx
Posté par zurvan . Évalué à 3.
limite de temps…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# pour moi
Posté par Philippe GRAILLE . Évalué à 2.
Perso, j'utilise Keepass et Dropbox.
Le coté Dropbox n'est pas le plus sécurisant philosophiquement mais c'est le plus pratique que j'ai trouvé.
Car j'ai la synchro sur plusieurs PCs et sur mon téléphone et ça marche très bien en faisant de la synchro dans tous les sens.
Je n'ai pas retesté depuis avec hubic mais à l'époque le client de synchro était pas top.
Je pense qu’aujourd’hui la maturité est bien meilleure.
Si l'on considère OVH comme plus sécuritaire car pas au US cela me parait une bonne alternative.
Peu importe le cloud qui héberge (même owncloud aurait pu faire l'affaire) le tout pour moi est la facilité et fiabilité d'utilisation.
La sécurité étant assurée principalement par le gestionnaire de mot de passe et mon mot de passe unique suffisamment fort.
# SuperGenPass
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 26 janvier 2016 à 11:18.
J'aime vraiment pas l'idée d'avoir des mots de passes tellement nombreux/complexes/variés qu'il faut les écrire quelque part.
Alors je me tente une migration vers SuperGenPass.
Pour ceux qui connaissent pas, l'idée est d'avoir un mot de passe (plusieurs si ça vous chante, c'est un détail) commun entre les sites. Mais un algo "sale" le mot de passe avec l'URL du site. Ainsi, chaque site a un mot de passe unique, et qui ne permet pas de rmeonter au mot de passe original.
Exemple : j'ai le mot de passe "jaimelatartiflette" commun à tous les sites. Appliqué au site "linuxfr.org", ça donne : x3PMxKe0AV
linuxfr.org ne verra donc comme mot de passe que x3PMxKe0AV. Si il a la mauvaise idée de le stocker en clair et qu'il se fait hacker, pas de pb, on n'ira pas avec ce mot de passe sur mon compte mail ni sur PayPal.
SGP existe principalement sous forme d'une applet java qu'on bookmarke (très pratique: elle remplit l'URL automatiquement, et une fois le mot de passe généré, elle sait remplir automatiquement le formulaire) qui garantit que tous les calculs sont fait en local, mais aussi application Android etc. De toutes façons l'algo est ouvert : https://github.com/chriszarate/supergenpass
Utilisez-vous ça ? Trouvez-vous des inconvénients ?
Je suis en train de migrer, je veux pas partir sur une solution bancal.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: SuperGenPass
Posté par ckiller . Évalué à 0.
C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.
Nous sommes là dans un cas de sécurité par l'obscurité.
Essayons d'évaluer qui pourrait être au courant de cette information.
- Ton FAI qui ont accès à ton historique, donc potentiellement l'ensemble des services de polices/espionnage…
- Utilise-tu un smartphone ? Si oui, quelques applications pourraient avoir accès à cette information.
- Les lecteurs de linuxfr. Ben oui, tu viens de nous le dire :-)
Ca commence à en faire du monde.
Mais c'est un peu mieux que de mettre le même mot de passe partout, mais pas beaucoup.
[^] # Re: SuperGenPass
Posté par Trollgouin . Évalué à 1.
| C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.
Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites) si j'ai bien compris les explications. Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 3.
C’est une condensation ré-itérée x fois (avec x = 10 par défaut) d’un mot de passe principal suivi du nom du site. Rien à voir avec un chiffrement.
C’est plus ou moins analogue à un HMAC, à ceci près que la clé est ici le mot de passe principal de l’utilisateur, qui à presque tous les coups ne fournit pas une sécurité suffisante (comparé par exemple à une clef aléatoire de 128 bits).
Le problème est que la « clé » n’est pas si difficile que ça à retrouver (sauf si le mot de passe est très complexe). Pas forcément à la portée du premier venu, mais rien de comparable avec la difficulté de craquer un chiffrement digne de ce nom.
[^] # Re: SuperGenPass
Posté par Trollgouin . Évalué à 3.
Merci pour les infos:
J'ai mal utilisé le terme chiffrement: je pensais à une injection de clé, avec en plus un "key streching" (désolé, pas d'idée de traduction) histoire d'augmenter l'entropie et de ralentir le hachage (pas besoin de vitesse en utilisation normale dans ce cas) pour limiter le bruteforce, le tout itéré avec une bonne fonction de hachage (Keccak?). C'est un peu ce que tu décris, sauf qu'il y a peu d'itérations (10 me semble bien faible mais c'est bien leur défaut, tu as raison!) et que, par défaut, ils se contentent d'un hash MD5 (voir leur code) alors qu'ils utilisent crypto-js qui supporte du sha3 (donc du Kekkac).
Dommage, je trouvais l'idée sympa. Enfin, ça reste toujours mieux que du mot de passe identique partout…
Sinon, qq'un a une idée de comment le navigateur assure qu'un "processus" (pas au sens système) javascript ne peut jamais accéder à la mémoire d'un autre "processus"? C'est threadé et laissé à l'OS? Je pensais au mot de passe maître qui réside en mémoire et ça ne m'inspire pas confiance (à tort?).
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 5.
Le problème avec les fonctions de hachage, même les bonnes comme Keccak, est qu’elles sont conçues (entre autres) pour être rapides, ce qui n’est pas idéal pour ce genre d’utilisation.
Ici, on a besoin au contraire d’une fonction « lente ». S’il fallait, par exemple, 100 ms pour hacher le mot de passe maître, ça n’aurait pas beaucoup d’impact pour l’utilisateur en conditions normales (100 ms, c’est suffisamment rapide pour que l’utilisateur perçoive à peine le délai), mais ça rendrait la recherche exhaustive beaucoup plus coûteuse pour l’attaquant.
Et mieux encore, il faudrait une fonction coûteuse en temps et en mémoire. Des fonctions comme scrypt ou Argon2, spécialement conçues pour le « hachage » de mot de passe.
Exécuter n fois une fonction de condensation sur un mot de passe est un « hack », qu’on devrait laisser de côté maintenant qu’on a des fonctions étudiées pour.
[^] # Re: SuperGenPass
Posté par fcartegnie . Évalué à 4.
hash("pass:domaine.tld")
Un hash ça reste un hash. Si tu connais la méthode de hash utilisée et que t'as le resultat, tu peux faire un brute force pour avoir la valeur d'entrée.
T'as juste a brute forcer uniquement sur la partie "pass", tu connais déjà la fin qui est le tld: Une fois pass trouvé, t'as les mots de passe pour tous les autres tls que tu veux.
On recommande un mot de passe différent par site, et ici c'est l'effet contraire.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 6.
« Attention, paranoïaque en approche à 11 heures ! Feu à volonté ! »
Ahem.
Un (rapide, certes) coup d’œil au code ne m’inspire pas beaucoup confiance. Deux petites choses me gènent particulièrement.
D’abord, même si l’auteur met en avant le fait qu’il s’agisse d’un bookmarklet qui s’exécute localement, je vois que le code télécharge une version de jQuery depuis les serveurs de Google. Donc, même si j’installe le bookmarklet une fois pour toute (après avoir vérifié qu’il fait bien ce qu’il est censé faire), a priori chaque fois que je l’exécute je récupère un bout de code arbitraire depuis l’Internet. Merci, sans façon.
Ensuite, j’ai de grosses réserves sur l’algorithme de génération de mots de passe. Par défaut, c’est simplement une concaténation du mot de passe « maître » et de l’URL du site cible, passé dix fois de suite à la moulinette de MD5.
La fonction MD5 est à mon avis beaucoup trop faible pour être encore utilisée de cette façon. Faire dix passages au lieu d’un seul n’y change pas grand’chose. Pour peu que le mot de passe maître ne soit pas suffisamment complexe, quelqu’un qui sait que tu génères tes mots de passe de cette façon pourrait probablement remonter jusqu’au mot de passe maître (et là, c’est jackpot, il connaît tous tes mots de passes pour tous les sites que tu visites).
Il est possible d’utiliser SHA512 au lieu de MD5, ce qui est certes nettement mieux mais ce n’est toujours pas une fonction appropriée pour ce genre de tâche.
[^] # Re: SuperGenPass
Posté par Trollgouin . Évalué à 1.
Arg. J'aurais du relire tout le thread avant de répondre :)
On a les mêmes inquiétudes…
[^] # Re: SuperGenPass
Posté par gUI (Mastodon) . Évalué à 4.
Merci pour vos retours, mais je comprends pas trop les contre arguments. J'essaie surtout de comprendre, je ne suis pas particulièrement partisan de quel camp que ce soit.
Par contre je vois quelque chose de vos retours : SGP va nécessairement avec un mot de passe fort, très fort, voire très très fort :D
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 2.
Si l’attaquant sait que tu utilises SGP, il lui suffit de craquer un seul des mots de passe générés pour retrouver ton mot de passe maître, et à partir de là obtenir les mots de passe pour tous les sites.
Nul besoin d’inverser la fonction de condensation si
Ma pauvre machine de bureau est capable, sans forcer (pas d’utilisation de plusieurs cœurs, du GPU, ou d’autres optimisations de ce genre) de calculer environ dix millions de MD5 par seconde.
Note que même un mot de passe d’apparence complexe peut être « faible » s’il est dans un dictionnaire, ou s’il peut être construit à partir d’un dictionnaire.
Ce n’est pas une faiblesse propre à MD5. Comme je le disais plus haut, toutes les fonctions de condensation conçues pour être rapide ont le même problème (SHA-512 ? Je peux en calculer environ six millions par seconde, les doigts dans le nez). C’est pour ça qu’elles ne sont pas adaptées à la condensation de mots de passe.
Pas comparable.
Dans ton cas, il suffit à l’attaquant d’obtenir un seul de tes mots de passe (de quelque façon que ce soit : via un keylogger sur ta machine, en sniffant le réseau — il y a encore des sites dont les formulaires de login ne sont pas protégés par TLS… —, en obtenant un dump de la base de données d’un site — non, je ne suis pas parano, renseignez-vous, il ne se passe pas une semaine sans qu’un site ne se fasse pas pirater sa BD —, etc.) pour pouvoir ensuite tenter de le craquer à loisir, totalement « offline », en y mettant autant de ressources que possible et sans que tu ne te doutes rien.
De mon côté (avec un fichier de mots de passe chiffré par GnuPG, mais ce serait à peu près pareil avec un gestionnaire de mots de passe comme KeePassX ou assimilé), si l’attaquant obtient un de mes mots de passe, ben… il a un de mes mots de passe. Chouette pour lui mais ça ne lui permettra jamais d’obtenir les autres.
S’il veut tous mes mots de passe, il lui faut impérativement mettre la main sur mon fichier de mots de passe, et casser la protection dudit fichier¹. Pas impossible certes, mais la grosse différence par rapport à ton schéma est que l’attaquant n’a plus le choix du point d’attaque. Il doit s’en prendre à ma machine, il ne peut pas choisir de sniffer un point quelconque du réseau ou s’en prendre à un site mal protégé.
¹ Ce qui chez moi implique de devoir
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 3. Dernière modification le 28 janvier 2016 à 19:09.
Pour enfoncer le clou (et peut-être être plus clair), les deux gros points faibles du principe de SGP sont :
[^] # Re: SuperGenPass
Posté par gUI (Mastodon) . Évalué à 2.
C'est là que je comprends pas.
Exemple : sur linuxfr.org, mon mot de passe est xFe8q0Lksf. Si d'une manière quelconque tu arrives à le choper, ok, tu as donc accès à linuxfr.org. Mais pour aller sur un autre site, il va te falloir retrouver mon master password.
Et tu me dis qu'à coup de qques millions de tentatives par secondes tu vas arriver à retrouver mon master password "facilement" ?
C'est là que tout se joue je pense. SI c'est réellement le cas, en effet, SGP ne sert strictement à rien. On peut calculer une espérance théorique ? Concrètement, ça prend 1h ou 1 million d'années à le trouver ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 2.
Oui, et le problème est que c’est possible, vu que ton mot de passe pour linuxfr.org est directement dérivé de ton master password.
Je ne dis pas que c’est facile (ça peut même être tellement difficile que ça cera, concrètement, infaisable si ton mot de passe maître est suffisamment complexe), mais c’est possible.
S’il est trop simple ou s’il est dans un dictionnaire, oui, définitivement.
Il faut noter qu’un « dictionnaire », aujourd’hui, ce n’est plus une simple liste de mots sortis d’un « Robert » ou d’un « Larousse » (ou de
/usr/share/dict). les craqueurs élaborent aujourd’hui des dictionnaires très riches, alimentés notamment par de vrais mots de passe issus des innombrables bases de données de sites piratés (par exemple, le dictionnaire utilisé pour craquer les mots de passe de LinkedIn comportait plus de 500 millions de mots et a permis de retrouver des mots de passe de plus de vingt caractères).Dis-moi quel est ton mot de passe, je te dirai s’il est suffisamment fort. :D
Plus sérieusement, c’est justement parce que je ne peux pas répondre à cette question que je préfère éviter d’utiliser une méthode où la sécurité de tous mes mots de passe dépend de la réponse à cette question…
[^] # Re: SuperGenPass
Posté par gUI (Mastodon) . Évalué à 2.
Ok, donc ça me conforte dans ce que j'ai appris de vos remarques : le master password doit être un mot de passe fort. Quand je dis fort, c'est style 20 caractères.
Le mien actuel est pas ridicule (strictement aucun rapport avec le dictionnaire, mais seulement 8 caractères).
Bon, je le note… et je change mes passwords :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 2. Dernière modification le 31 janvier 2016 à 21:02.
Désolé, mais 8 caractères, aujourd’hui, c’est ridicule.
Dans le meilleur des cas (utilisation de lettres minuscules et majuscules, de chiffres, et plus généralement de toute la plage de caractères ASCII imprimables), il y 895 = 6 634 204 312 890 625 combinaisons à tester.
C’est certes hors de portée de ma machine (il me faudrait environ 21 ans), mais largement à la portée de beaucoup trop de monde (en gros, quiconque peut investir dans quelques cartes graphiques) pour que je sois à l’aise.
Je dirais que 12 caractères, c’est vraiment le strict minimum de nos jours. Et pour un « master password » dont dérivent tous les autres, je pense que je ne descendrai pas en-deçà de 18.
[^] # Re: SuperGenPass
Posté par gouttegd (site web personnel) . Évalué à 2.
J’ai écrit ça trop vite, grossière erreur, c’est 958 combinaisons, pas 895…
# À l'ancienne
Posté par Lutin . Évalué à 5.
Sur une feuille cachée sous le matelas, entre deux magazines coquins.
# Algo en tête maison
Posté par wilk . Évalué à 2.
Depuis que j'utilise un algo en tête maison plus de soucis. C'est à dire un petit algo perso qui transforme le nom du service en un mot de passe, par exemple la première lettre + 1, la deuxième + 2, le nombre de lettre x l'année de naissance de ma fille etc…
Pour les cas un peu particulier où ça ne marche pas directement (pas assez de lettre ou autre) je l'écris sur un fichier qui lui n'a aucun besoin d'être crypté.
Pour les mots de passes ou codes que je ne peux pas modifier moi-même, je les écris avec une erreur. Par exemple si c'est un numéro j'inverse systématiquement le premier et le dernier caractère ou je lui ajoute mon année de naissance etc… Donc là aussi ça permet de l'écrire n'importe où.
N'importe où c'est généralement un fichier qui n'a l'air de rien genre test.py dans un répertoire build par ex.
# dans ton c ?
Posté par djibb (site web personnel) . Évalué à 2.
dsl…
-> []
# Vive le mail
Posté par Philippe F (site web personnel) . Évalué à 3.
Je stocke mes mots de passe sous forme de messages cryptés dans un répertoire de ma boite mail. J'ai rarement besoin d'être mobile mais si le besoin s'en faisait sentir, un petit coup de gpg + imap pourrait résoudre le problème.
Comme quoi les vieux trucs, ça marche très bien.
[^] # Re: Vive le mail
Posté par KiKouN . Évalué à 3.
J'ai toujours adoré les solutions comme celle-ci basées sur Imap. Malheureusement, ça ne courent pas les rues.
Imap est parfait/assez courant/suffisant pour stocker et rendre accessible de petites informations comme celle-ci.
# Cryptographie, mon oeil !
Posté par Gwen Gaumend . Évalué à -7.
Bonjour,
Bon, en gros, si je comprends bien, vivement la reconnaissance oculaire, faciale, et testiculaire, pour échapper à nos futurs terroristes/gouvernements tout plein méchants qui n'en veulent qu'à nos données personnelles, qui, si elles étaient connues, renverseraient d'elles-mêmes une bonne partie de l'Univers pas très bien étoilée.
Et ben, "Ils" ont raison de se faire du souci, rien qu'en les regardant en face, on va bientôt "les" renverser.
Ouf, vive les dernières technologies !
E-Gwen.
[^] # Re: Cryptographie, mon oeil !
Posté par Sufflope (site web personnel) . Évalué à 3.
Si j'en crois les films y en a qui coupent le doigt/la main pour outrepasser la reconnaissance digitale (j'aurais sûrement dû dire reconnaissance d'empreintes mais j'avais envie de caser digital à un endroit justifié pour une fois), alors non pas vivement.
# Dans une clef USB
Posté par Mildred (site web personnel) . Évalué à 1.
Pour ma part, je viens tout juste de mettre en place un gestionnaire de mot de passe sur ma machine qui va sans doute me permettre d'avoir des mots de passe un peu plus sécurisés. J'utilise pass pour cela. Il stocke les mots de passe en chiffré via une clef GPG. Pour partager ces mots de passe entre mes différents ordinateurs, je mets le tout sur une clef USB, avec la clef GPG que j'utilise exclusivement pour mes mots de passe.
Et je ne vais certainement pas mettre le tout sur Internet. Pas une seule seconde.
Après, si tu préfères passer par le réseau, tu fais un joli scp :)
[^] # Re: Dans une clef USB
Posté par oinkoink_daotter . Évalué à 3.
Wai. Gare à la sauvegarde quand même. Une clef USB, ça se casse, ça se petitsuicide, ça se perd.
Donc en confidentialité, voir en intégrité, c'est plutôt bien, mais en dispo, c'est pas terrible.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.