Je crypte des données (industrie de la santé) en utilisant les classes de cryptage aes dans le cadre .net. Quels sont les endroits recommandés pour stocker la clé en toute sécurité? Je l'ai dans le web.config pour le développement, mais cela ne me semble pas digne de production, c'est le moins qu'on puisse dire.Où stocker la clé de cryptage
Si l'application nécessite une authentification à l'aide de vos clés, alors
l'approche normale sur les machines Unix est de stocker les mots de passe sous forme hachée.
Vous pouvez utiliser le sel sha-512 +.
Ensuite, vous pouvez calculer le hachage lorsque l'utilisateur entre le mot de passe et vérifier par rapport à votre.
Les mots de passe/la clé elle-même peuvent être stockés n'importe où s'ils ont été hachés. Si ce n'est pas le cas, stockez-le dans le répertoire de l'utilisateur technique auquel aucun utilisateur n'a accès.
EDIT pour ceux qui ne veulent pas mettre trop d'effort pour comprendre cas d'utilisation que j'ai présenté
Johny a des données cryptées AES.
Il range sa clé dans la tête.
Il veut stocker ce bon quelque part sur son PC pour automatiser l'accès.
Il peut le stocker en ASCII dans web.config.
Mais il peut hacher cela pour ne plus être ASCII mais hash.
Pendant l'application d'authentification calcule les contrôles de hachage est la clé appropriée, puis utilise cette clé ....
Faible probablement de collision avec l'algorithme approprié.
ps. juste poster mon point de vue sur le sujet.
Pourquoi êtes-vous si sensible pour le mot "hash" ???
EDIT 2
Je sais ce qui est hachage,
Je sais ce qui est ce qu'on appelle le chiffrement à 2 voies ....
Vous pouvez chiffrer vos valeurs web.config en utilisant les méthodes intégrées dans la cadre:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Ceci est probablement un endroit raisonnable pour stocker la clé - si quelqu'un a réussi à accéder à votre serveur pour récupérer ces informations, alors vous avez probablement bi les soucis de gger.
True. Le DPAPI est-il plus "sécurisé"? – Saraz
@Saraz - Désolé, je ne connais pas la réponse à cela ... – Paddy
@Saraz: Plus sûr que quoi? C'est plus sûr dans le sens où «il est impossible de récupérer sans accès au niveau administrateur * sur cette machine spécifique *» (car l'algorithme de chiffrement dépend de données qui sont propres à la machine). En d'autres termes, si quelqu'un a réussi à obtenir votre fichier web.config, il ne peut toujours pas le décrypter sur une autre machine. – Piskvor
Ce que vous devez faire est de cacher cette clé quelque part, et un emplacement sécurisé serait à l'intérieur d'une base de données. De préférence une base de données différente de celle qui contient vos données. Comme les données nécessitent des combinaisons nom d'utilisateur/mot de passe pour les ouvrir, il vous suffit d'ajouter une seconde couche de sécurité à votre application. Votre application doit se connecter à la base de données de clés, récupérer la clé X pour l'application Y et peut ensuite l'utiliser. Cependant, vous devrez stocker la chaîne de connexion pour cette base de données.
Même si vous ne stockez qu'une seule clé dans une base de données de clés, cela en vaut la peine. Cela force un pirate à prendre un peu plus de mal à ouvrir cette base de données pour trouver la clé avant de pouvoir accéder aux données. Comme il n'y a pas de sécurité parfaite, vos options se limitent à retarder la durée d'accès d'un pirate.
Le cryptage du fichier web.config ou de ses données contribuera également à retarder le pirate, mais si la clé se trouve dans le fichier de configuration, tout ce qu'il doit faire est de le déchiffrer à nouveau.
Ce n'est pas vraiment différent de stocker une clé dans le fichier de configuration - vous devez stocker la chaîne de connexion dans votre base de données clé quelque part, et si votre pirate a accès à votre fichier de configuration, il pourra probablement obtenir ceci ... – Paddy
True. Mais il ajoute une deuxième couche. Vous devez accéder à la base de données pour obtenir la clé et, en général, les bases de données sont stockées sur un système différent. Si le serveur de base de données est configuré pour accepter uniquement les appels provenant de l'emplacement du serveur Web, il est plus difficile pour un pirate distant d'accéder à la clé. Et si la base de données stockait quelques centaines de clés (factices!), Le pirate ne sait toujours pas lequel utiliser. –
Une approche qui offrira une bonne sécurité si les seules personnes qui auront besoin d'utiliser la clé à quelque fin que ce soit peut absolument être de stocker la clé cryptée avec une autre clé, dont une copie est stockée pour chaque utilisateur , chiffré avec un hash du mot de passe de cet utilisateur (salé différemment de celui stocké pour la validation du mot de passe!). Même une personne malveillante ayant accès à toutes les données, n'importe où dans l'univers, associée à la clé de la base de données, ne pourrait pas accéder à la base de données sans avoir inversé au moins l'un des mots de passe.
Notez que si les mots de passe pour tous les comptes valides étaient perdus ou oubliés, les données seraient irrécupérables. Cela fait partie de la nature de la sécurité réelle. Si l'on veut éviter la possibilité de perdre des données, il faut s'assurer que les copies de sauvegarde des clés et/ou mots de passe nécessaires sont stockées en toute sécurité.
Vous pouvez utiliser le chiffrement basé sur certificat à la place. Voir http://en.wikipedia.org/wiki/Certificate-based_encryption et http://msdn.microsoft.com/en-us/library/ms867080.aspx et http://msdn.microsoft.com/fr-fr /library/ms229744.aspx –