Il serait certainement plus pratique de stocker ma base de données KeePass sur S3, Dropbox ou mieux encore SpiderOak. Ma peur est que mon compte de stockage cloud soit compromis, puis que les informations d'identification soient récupérées par la force brute ou par un autre vecteur d'attaque. Est-ce que c'est sûr? Quels risques dois-je connaître?
Vous pouvez augmenter la résilience de votre base de données KeePass à la force brute en augmentant le nombre d'itérations PBKDF2 lors de la dérivation de la clé de chiffrement de la base de données à partir de votre mot de passe. Vous pouvez le faire dans KeePass sous Fichier> Paramètres de la base de données> Sécurité. Personnellement, j'utilise environ 5 000 000 de tours (1 s de retard). N'oubliez pas que les appareils mobiles sont plus lents.
Il est difficile de quantifier exactement, mais si vous avez la base de données sur un appareil mobile, je ne dirais pas que c'est particulièrement moins sûr. KeePass crypte la base de données car le fichier restant sécurisé n'est pas censé être une garantie. Il est certainement préférable que le fichier DB ne soit pas dans la nature, mais si votre sécurité dépend du fait que le fichier chiffré reste confidentiel, alors vous avez de plus gros problèmes que d'utiliser ou non le stockage cloud.
Un maître suffisamment fort Le mot de passe doit empêcher le forçage brutal au moins assez longtemps pour qu'une violation soit détectée et que vous puissiez modifier les mots de passe qu'il contient. De cette manière, il peut même être légèrement préférable d'avoir une copie locale sur un appareil mobile car quelqu'un peut compromettre le fichier si vous quittez votre appareil des yeux même momentanément et il serait beaucoup plus difficile d'identifier cette violation.
Si vous souhaitez le sécuriser encore plus, vous pouvez ajouter une autre couche de sécurité en chiffrant le fichier que vous stockez dans le stockage cloud en ligne. Le mot de passe principal offre une assez bonne sécurité tant que vous choisissez un mot de passe difficile à forcer (long et vraiment aléatoire), mais il ne peut toujours pas rivaliser avec une clé de cryptage longue. Si vous cryptez le fichier que vous stockez en ligne et que vous conservez cette clé avec vous protégé par un mot de passe principal similaire, le composant en ligne seul est désormais beaucoup, beaucoup plus difficile à décrypter (probablement impossible si cela est fait correctement) et si votre fichier de clé est compromis, il vous suffit de rechiffrer immédiatement votre base de données en ligne avec une nouvelle clé. Vous avez toujours des problèmes si quelqu'un peut d'abord compromettre votre compte cloud et obtenir le fichier, mais cela nécessite deux points de compromis au lieu d'un.
Personnellement, je finirais probablement par utiliser mon OwnCloud (qui est auto-hébergé), mais j'ai l'avantage d'avoir mon propre serveur Web personnel et je me rends compte que ce n'est pas une option dont tout le monde peut profiter. (La seule raison pour laquelle je ne l'ai pas fait est que je n'ai pas un besoin particulier de coordonner une base de données de clés de cette manière.) Une solution basée sur le cloud public devrait cependant fonctionner comme une bonne deuxième option.
J'utilise la combinaison KeePass-Dropbox. La base de données de mots de passe est chiffrée à l'aide d'une clé dérivée d'un mot de passe principal fort . Même si quelqu'un acquiert votre base de données de mots de passe chiffrés via votre compte cloud, un mot de passe principal suffisamment fort rend les attaques par force brute irréalisables.
En termes simples: Utilisez un mot de passe principal fort et ne vous inquiétez plus à ce sujet.
Le cloud n'est pas digne de confiance par nature, et les fichiers qui y sont conservés doivent être considérés comme vulnérables, vous avez donc besoin d'un cryptage fort pour vous protéger. KeePass offre cela. Cependant, vous devez ensuite pouvoir faire confiance à chaque client dans lequel vous entrez votre mot de passe. Si vous les lisez sur un iPhone, faites-vous confiance à la plateforme? Protégez-vous votre mot de passe des caméras du métro lorsque vous y entrez, à chaque fois? Et votre ordinateur portable?
Vous devez également tenir compte de la valeur de ce que vous protégez. Est-ce que cela protège vos fonds de retraite? Vos scores dans la ligue de bowling fantastique? Une dissension politique illégale dans votre pays? Dans certains cas, cela ne vaut tout simplement pas le risque de faire une erreur.
Donc oui, tant que vous faites confiance à KeePass, que vous faites confiance à vos appareils, et que vous faites confiance à votre capacité à garder votre clé principale sécurisée, ne vous inquiétez pas pour garder la base de données dans Dropbox.
Même si votre base de données KP devait être compromise à partir de Dropbox, l'utilisation à la fois d'un mot de passe fort et d'un fichier de clés non stocké dans Dropbox devrait vous offrir une sécurité au-delà de tout moyen connu d'attaque électronique (tant car vos appareils ne sont pas déjà compromis).
Le fichier de clés doit être stocké dans un emplacement sécurisé séparé, tel qu'une clé USB que vous pouvez sécuriser physiquement. Cela offre 3 niveaux de protection:
Bien qu'un chiffrement suffisamment fort devrait être capable de résister aux attaques par force brute, considérez qu'en stockant votre base de données de mots de passe dans le cloud, vous donnez à l'attaquant potentiel beaucoup plus d'informations qu'il ne pourrait en obtenir, par exemple. un téléphone perdu avec la même base de données.
Chaque fois que vous modifiez un mot de passe, l'attaquant obtient une nouvelle base de données, qu'il peut utiliser avec des versions plus anciennes dans des attaques par analyse différentielle. Vous aurez besoin d'un chiffrement plus fort pour résister à cela, par rapport à un simple COA. S'il a également l'un de vos mots de passe (par exemple en craquant une base de données de mots de passe mal protégée à partir de l'un des sites que vous visitez), il pourra peut-être identifier ce mot de passe dans votre base de données. Cela ouvrirait des portes pour KPA qui pourraient être presque insignifiantes si vous réutilisez des mots de passe.
Vous donnez également à l'attaquant des informations sur votre activité liée aux mots de passe. Il saura à quelle fréquence vous modifiez vos mots de passe et pourra peut-être en déduire les mots de passe que vous modifiez.
Donc, si vous décidez de stocker votre base de données de mots de passe dans un cloud public,
Choisissez un algorithme de chiffrement fort, résistant à la crypto-analyse différentielle. Assurez-vous que chaque mot de passe de la base de données est salé individuellement.
Changez le mot de passe principal régulièrement, de préférence aussi souvent que vous le faites avec votre mot de passe le plus précieux.
Ne réutilisez pas les mots de passe.
Je suggérerais une solution qui implique ce qui suit:
Comme tout le monde l'a mentionné, il est très important d'avoir un mot de passe principal fort pour votre fichier de base de données pour contrecarrer les brutes attaques forcées. Mais si vous combinez cela avec un fichier de clé, il devient pratiquement impossible d'utiliser la force brute.
Si Cloud Storage 1 est compromis, le fichier de base de données lui-même sans le fichier de clé sera impossible à la force brute, à moins il existe une faille de sécurité sérieuse dans l'implémentation du chiffrement de Keepass.
Si Cloud Storage 2 est compromis, le fichier de clé lui-même est inutile sans le fichier de base de données. C'est juste une extension de votre mot de passe principal, il ne contient aucune donnée.
Je dirais qu'il serait très peu probable que les deux Cloud Storages soient compromis en même temps par le même attaquant. Vous devrez être une personne de haut niveau pour cela (par exemple, politicien, milliardaire, agent secret, etc.) :)
Si vous n'êtes pas l'un des ci-dessus et êtes prêt à sacrifier un peu de sécurité en échange de la facilité d'accès (par exemple, vous oubliez toujours où vous avez mis le maudit disque USB), puis stockez à la fois le fichier de base de données et le fichier de clé sur l'ordinateur local. Cependant, dans ce cas, l'ordinateur local devient le point faible, s'il est compromis, l'attaquant aurait accès au fichier de clé, il aurait donc juste besoin de forcer brutalement le mot de passe principal sur la base de données, il est donc préférable d'en définir un fort. Ce serait la même chose que de ne pas utiliser du tout de fichier clé.
Si vous voulez vraiment prendre les choses au sérieux, exécutez Boxcryptor en conjonction avec Dropbox. Boxcryptor crypte tout à votre extrémité AVANT l'envoi aux serveurs de Dropboxs. Tout ce qui est à la fin de Dropbox est une charge de choses cryptées. Votre base de données Keepass est doublement chiffrée!
J'utilise personnellement un mot de passe très fort de 35 caractères mélangés à des symboles et je garde mon fichier DB sur Google Drive. Si vous ne conservez pas des millions de crypto ou autre chose que vous ne pouvez pas récupérer, tout devrait bien se passer. Donc, même si quelqu'un volera votre base de données et même si quelqu'un sera capable de la crypter (j'en doute fortement), il existe d'autres moyens de protéger vos comptes et d'autres choses importantes. J'utilise personnellement l'authentification Two Factor dans chaque compte lié à Money et chaque compte important, donc son double coffre-fort de deux côtés. Je pense que je suis en sécurité. + en lisant ce fil, j'ai également augmenté mes itérations comme @Matrix le suggérait, donc j'ai ajouté une autre couche de sécurité. :) Il y a une autre couche que j'ajouterais si je me sens menacé d'une manière ou d'une autre et ce sont des services comme https://www.boxcryptor.com/en/ qui chiffrent en plus les fichiers dans votre cloud.
Je crois fermement en la défense en profondeur à ce sujet.
Peu importe la force de votre mot de passe, c'est aussi celui qui ne peut pas être changé.
Donc, pour protéger mon Keepass DB, j'utilise trois couches:
Pourquoi le mot de passe ne peut pas être changé: bien sûr, vous pouvez changer le mot de passe, et il va en fait rechiffrer la base de données Keepass, mais vous ne pouvez pas le modifier rétroactivement sur d'anciennes copies.
Surtout (mais pas seulement) si vous stockez la base de données dans le cloud, vous devez supposer qu'un adversaire a mis la main sur la base de données à un moment antérieur, avec un ancien mot de passe . Cela peut lui donner les informations qu'elle recherche.
Une autre option: n'utilisez le cloud que pour transférer votre base de données sur votre prochain appareil, puis supprimez-la du stockage cloud. Cela exposerait votre base de données pendant une durée limitée. Pas exactement ce que vous demandiez mais une option qui peut être envisagée en fonction de votre niveau de sécurité requis.
Je vous dis d'aller avec la solution cloud "chiffrée chez le client" de votre choix, chiffrez avec le plus grand nombre d'itérations PBKDF2 avec lesquelles vous êtes à l'aise, le plus grand fichier de clés avec lequel vous pouvez vivre et, surtout, stockez les informations que vous gardez près de vous ( localement) sur un lecteur SELF ENCRYPTING. Mettez un système de fichiers crypté au-dessus si vous le devez, mais le cryptage des données susceptibles d'être perdues ou volées, comme une clé USB, doit être automatique.
Si un groupe est capable de compromettre suffisamment un service cloud pour découvrir que vous avez un kdb à craquer, il peut être plus motivé pour installer un key logger / root kit sur vos appareils personnels. Bien sûr, si un tel groupe peut vous voir télécharger le logiciel à partir de sourceforge ou d'un magasin d'applications, il obtient des informations similaires. En fait, cet article est un indice beaucoup plus facile, donc l'inquiétude pour ce vecteur d'attaque peut être pour des individus plus paranoïaques que nous.