Discussion :

[Calak]

Bonjour,

Je suis en train de dev (en c++, mais ça n'a pas d'importance ici) une application de gestion de compte utilisateur (Login/password/description) pour la connexion à un service tiers.

C'est une application de type "coffre fort" (a la manière de keepass par exemple), sécurisée par un mot de passe utilisateurs unique, pour qu'il n'ait pas à retenir les multiples login/password.

Je pensais stocker dans un fichier, le hash du password de décryptage, suivi des données de connexion cryptées. (Le tout avec un mécanisme de vérification d'intégrité).

Qu'en pensez vous?

[BufferBob]

salut,

Qu'en pensez vous?

• qu'on dit "chiffrer"
• que stocker le hash du mot de passe ne sert à rien, à part peut-être permettre à un attaquant de bruteforcer ledit hash justement
• que juste "crypter" les données ne veut pas dire grand chose, il faut tenir compte des algorithmes de chiffrement utilisés et aussi la structure des données chiffrées (cf. le principe des attaques à clair connu)
• que coder ce genre d'application ne s'improvise pas, il faut une vraie expertise en sécurité et en cryptographie, à moins que ce soit juste du coding for fun
• que tu as fais un deux fois le même topic

[Jipété]

Et à la suite de BufferBob,

Qu'en pensez vous?

Qu'on met un trait d'union à l'impératif --> Qu'en pensez-vous ?

Quant au titre, Fichier crypté de données sécurisée, c'est le fichier qui est sécurisé (un "e" de trop) ou les données (manque un "s", alors...) ?

[Calak]

salut,

• qu'on dit "chiffrer"
• que stocker le hash du mot de passe ne sert à rien, à part peut-être permettre à un attaquant de bruteforcer ledit hash justement
• que juste "crypter" les données ne veut pas dire grand chose, il faut tenir compte des algorithmes de chiffrement utilisés et aussi la structure des données chiffrées (cf. le principe des attaques à clair connu)
• que coder ce genre d'application ne s'improvise pas, il faut une vraie expertise en sécurité et en cryptographie, à moins que ce soit juste du coding for fun
• que tu as fais un deux fois le même topic

• L'important c'est que vous ayez compris, mais oui, tant qu'a faire autant utiliser la bonne terminologie.
• Enfin bon, attaquer par brutefore un hash Sha256 ou 512 faut être motivé. et cela l'aurait permis, a moindre coût de vérifier le mot de passe de décryptage rapidement.
• je pensais chiffrer a l'aide d'un algo AES, la structure de donnée comme une seule entité, plutôt que justement éléments par éléments. (En gros, un seul bloc chiffré, plutôt que élément par élément).
• il faut bien commencer par quelque part, et c'est aussi pour ça que je poste sur un forum d'entraide communautaire fréquenté par des professionnels.
• oui, je ne sais pas ce qui s'est passé. :/

[Calak]

Et à la suite de BufferBob,

Qu'on met un trait d'union à l'impératif --> Qu'en pensez-vous ?

Quant au titre, Fichier crypté de données sécurisée, c'est le fichier qui est sécurisé (un "e" de trop) ou les données (manque un "s", alors...) ?

Le titre est bien écrit, donc bon...
Oui, j'ai oublié un tiret, j'en suis désolé... Mettons cela sur le compte du fait que j'écris depuis mon téléphone

[BufferBob]

Enfin bon, attaquer par brutefore un hash Sha256 ou 512 faut être motivé. et cela l'aurait permis, a moindre coût de vérifier le mot de passe de décryptage rapidement.

c'est pas une affaire de fonction de hashage "forte", si le mot de passe est toto il ne tiendra pas longtemps, par ailleurs ça n'est pas utile puisque si le mot de passe est bon, on arrivera à déchiffrer le contenu, si le déchiffrement échoue c'est que le mot de passe est invalide tout simplement (c'est rapide)

je pensais chiffrer a l'aide d'un algo AES, la structure de donnée comme une seule entité, plutôt que justement éléments par éléments. (En gros, un seul bloc chiffré, plutôt que élément par élément).

ben si on prend l'exemple d'AES, il chiffre des blocs de 128bits, donc si on a plus de 128bits de données à chiffrer va se poser la question du mode d'opération adapté par exemple
mais il y aussi la question du format des données, admettons qu'on doive chiffrer par exemple un fichier XML, on connait déjà plus ou moins sa structure par endroits (ou on peut en supposer une partie) ce qui peut permettre d'attaquer tout ou partie du texte chiffré

mais je ne suis pas cryptologue, je serais bien en mal de faire des préconisations fiables à 100%, la seule chose dont je sois certain à ce niveau c'est que, comme dit, ça ne s'improvise pas, il faut des compétences assez pointues pour coder ce genre d'appli, particulièrement si le propos final est de le commercialiser...

[Neckara]

que stocker le hash du mot de passe ne sert à rien, à part peut-être permettre à un attaquant de bruteforcer ledit hash justement

S'il ne stocke pas le hash du mot de passe, il faudrait tout de même lui dire la manière dont il va pouvoir vérifier le mot de passe, ça ne s'invente pas.

D'un autre côté, rien ne l'empêche de brute forcer même sans avoir un hash, juste en ayant les données chiffrées et les algorithmes utilisés.

si le mot de passe est toto il ne tiendra pas longtemps

D'un autre côté, quelque soit l'algorithme utilisée, si le mot de passe est "toto", une attaque par brute force est toujours possible.


Si je ne m'abuse, on utilise (?) un algorithme de dérivation de clé afin de générer une clé à partir d'un mot de passe. Ainsi, on peut déchiffrer le contenu chiffré avec la clé générée.
Après, il doit y avoir au moins un hash du contenu, donc une fois le contenu déchiffré, on calcul son hash et on compare.

• Si le hash est identique on a bien le bon mot de passe et les bonnes données ;
• Si le hash n'est pas identique, on a pas le bon mot de passe donc les données "déchiffrées" ne sont pas correctes.

Comme la clé est générée à partir du mot de passe, on a pas besoin de la stocker sur l'ordinateur, donc on ne peut pas la retrouver en recherchant dans les fichiers.
Mais les attaques par brutes forces sont toujours possibles.

Certains logiciels proposent aussi de stocker une autre clé sur une clé USB et d'utiliser cette clé en complément du mot de passe.
Tu as ainsi deux facteurs d'authentification :

• la connaissance d'un secret, ici un mot de passe ;
• la possession d'un objet, ici la clé USB ;

Je ne connais pas l'algorithme utilisé ensuite, mais je pense que tu ne peux plus brute-forcer le mot de passe sans avoir connaissance de la clé stockée sur la clé USB.


Si tu veux t'amuser, n'hésite pas, fonce et prend ton pied.
Si tu veux commercialiser, oublie tout de suite, tu ne feras jamais mieux que l'existant, pire, tu risques d' vas avoir un produit plein de faille.
Si tu veux inventer un nouveau système, c'est le travail des chercheurs, piques pas mon boulot !