Version imprimable
Bonjour,
Dans une application C#, l'utilisateur doit un moment saisir un mot de passe dans l'application et dans le code, je compare ce que l'utilisateur saisit avec le mot de passe en clair dans la code.
Je sais que ce n'est pas bien de mettre le code en dur dans le code, et je voulais savoir quelle est la bonne pratique dans ce cas là pour ne pas mettre le mot de passe en claire dans le code ?
Auriez-vous un exemple précis avec du code ?
Merci.
Bonjour,
C'est effectivement une très mauvaise pratique et pour plusieurs raisons. Mot de passe facilement accessible (même une fois le programme compilé), il peut se retrouver dans le gestionnaire de code source et sur des dépôts, etc...
Le strict minimum a faire est de ne pas comparer le mot de passe, mais le mot de passe hashé avec utilisation d'un sel.
L'usage d'un sel permet de se prémunir des attaques par table arc-en-ciel (rainbow table attack).
Le hashage doit être fait avec un algorithme robuste. On oublie donc le MD5 et le SHA1 pour lesquels les attaques par collision sont possibles. On privilégie une solution à base de SHA2, PBKDF2, bcrypt etc.
Le strict minimum, c'est SHA2(salt + password) car sans doute le plus simple d'utilisation tout en étant un minimum sécurisé.
Ensuite, il existe bien évidemment d'autres possibilités pour la gestion des mots de passe, comme externaliser le stockage des hash dans un fichier ou BD (avec des restrictions d'accès en lecture !), l'usage de certificat, etc. Mais ce sont de ssolutions qui peuvent être plus lourdes/plus intrusives à déployer sur une architecture déjà existante.
Le sel ajouté au mot de passe est en clair dans le code source ?
Mais si le sel est connu par une personne, est-ce que cela rend cette technique inefficace ?
A partir d'un hash, on peut donc par un calcul revenir en arrière et donc trouver le mot de passe, c'est cela ?
Merci.
Ce n'est pas gênant. Le sel n'a pas besoin d'être secret. Son objectif est simplement de rendre inopérant des attaques par tables précalculées (les attaques rainbow table)Citation:
Envoyé par speedcristal
Non.Citation:
Envoyé par speedcristal
Un bon algorithme de hashage rend l'opération inverse extrêmement difficile. Donc, à partir d'un hash, si l'algorithme est robuste, il est quasi impossible de retrouver la valeur d'origine. Pour déterminer si les mots de passe sont bon, il faut donc faire la comparaison sur les hash et non plus sur les mots de passe.
Ainsi, au moment où un utilisateur souhaite s'identifier, son mot de passe est hashé, et c'est ce hash qui est comparé au hash sauvegardé.
Bonjour François,
Je suis entièrement d accord avec tout ce que tu as dis.
Cependant, à mon sens même si le Pwd est hashé il serait assez facile de debugger le binaire (reverse engineering) et remplacer le booléen de comparaison pour que l attaquant puisse se voir donner l acces aux fonctionnalités de l appli.
A mon sens, en dotnet nous ne devons pas stocker d informations sensibles.
Le + secure serait en effet d'utiliser un service web. .conjoint a des requêtes web sécurisées....
Mais il s agit la d un grand débat......
Cordialement.
Un programme .NET n'est pas fait pour faire de l'obfuscation. Donc, de ce point de vue, je ne peux qu'être d'accord avec toi. Comme tu le disais, la sécurisation d'une application .NET est un grand débat (ce n'est pas pour rien que la classe SecureString est dépréciée par exemple, car donnant un faux sentiment de sécurité).Citation:
Envoyé par wallace1
Je ne faisais que répondre à la question initiale (comment stocker un mot de passe pas en clair dans le code). La question est simple quand on se limite à ce cadre :D