Catégorie : Sécurité informatique

Bon, tout le monde devrait le savoir, même si mon expé­rience récente me montre qu’un rappel n’est pas inutile :

• On ne stocke pas les mots de passe en clair, on les crypte
• On n’uti­lise pas un chif­fre­ment réver­sible mais une fonc­tion de hachage
• Un simple hachage ne suffit pas, il faut y ajou­ter un salage
• Le salage doit être diffé­rent pour chaque mot de passe
• L’al­go­rithme utilisé doit être lent, comme blow­fish par exemple

Croyez moi, j’ai encore décou­vert il y a peu que non seule­ment ce n’était pas évident pour tout le monde mais que certains refusent de consi­dé­rer un simple stockage sous forme md5 sans salage comme une erreur et un problème poten­tiel de sécu­rité.

Mais plus que tout ça, pour moi la règle de base c’est « ne jouez pas avec la sécu­rité ». Si vous n’êtes pas un expert dans la ques­tion : ne créez rien et n’im­plé­men­tez rien vous-même, utili­sez des biblio­thèques de codes toutes faites.

Et par pitié, ne tentez pas d’amé­lio­rer les choses

En jouant sur l’in­tui­tion, vous avez toutes les chances d’ar­ri­ver à un résul­tat opposé à celui que vous espé­rez.

Dans le texte du jour à lire, Properly Salting Pass­words, The Case Against Pepper, nous avons un superbe exemple que je tente d’ex­pliquer en vain à chaque fois qu’on lève le sujet :

Pour « amélio­rer » la sécu­rité, en plus du salage géré par l’al­go­rithme, propre à chaque mot de passe, certains cherchent à ajou­ter un second salage, global à l’ap­pli­ca­tion. L’idée est que le salage présent à côté du mot de passe dans la base de données ne suffit pas, il faudrait en plus connaitre le salage global utilisé par l’ap­pli­ca­tif, et donc profi­ter d’une faille de sécu­rité plus impor­tante afin d’ex­ploi­ter quoi que ce soit.

L’idée semble bonne, intui­ti­ve­ment. Malheu­reu­se­ment vous n’êtes proba­ble­ment pas un expert sur l’al­go­rithme blow­fish. Vous ne *savez* pas si ajou­ter le même salage en début ou en fin du mot de passe avant de l’en­voyer à blow­fish ne risque pas de réduire la sécu­rité du résul­tat. Oh, vous avez proba­ble­ment l’in­tui­tion que ce n’est pas le cas, voire vous en êtes certains, mais aucune docu­men­ta­tion de sécu­rité recon­nue comme étant d’au­to­rité ne le précise expli­ci­te­ment.

Vous en êtes à l’in­tui­tion et vous avez une chance sur deux de vous plan­ter. Au final, est-ce vrai­ment un bon pari ? Ça pour­rait l’être si l’état de l’art du stockage des mots de passe était fran­che­ment insuf­fi­sant et s’il n’y avait aucune méthode stan­dard pour l’amé­lio­rer. Ici il est probable que vous ne soyez pas encore à l’état de l’art (n’uti­li­se­riez-vous pas sha1 ou md5 ?) et cet état de l’art est proba­ble­ment suffi­sant si vous utili­sez suffi­sam­ment d’ité­ra­tions.

Mais plus que cette ques­tion du double salage, qui est une mauvaise idée pour ce que vous et moi en savons, c’est toute l’im­plé­men­ta­tion que vous ne devriez pas toucher. Utili­sez une biblio­thèque de code éprou­vée, ou mieux : une fonc­tion prévue pour. En PHP nous avons « crypt », qui avec avec l’al­go­rithme blow­fish et suffi­sam­ment d’ité­ra­tions, rendra votre stockage des mots de passe bien plus solide que tout le reste de votre appli­ca­tion.

Je ne sais que dire, si ce n’est que tout ça n’est pas vrai­ment éton­nant, ni même nouveau. Nous savons que des failles existent. Nous savons que certaines sont utili­sées et exploi­tées par des orga­ni­sa­tions.

Nortel Networks hackers had « access to every­thing » for years

Nortel, Veri­sign, des CA de certi­fi­cats SSL, ne croyez pas à la sécu­rité contre de grandes orga­ni­sa­tions ou gouver­ne­ments. C’est aussi pour ça que quelle que soit la tech­ni­cité du pres­ta­taire de solu­tion de sécu­rité, si les échanges reposent sur des certi­fi­cats, des clefs ou des proto­coles déte­nus par des tiers, vous ne faites que rajou­ter un risque.

Nortel did nothing to keep out the hackers except to change seven compro­mi­sed pass­words that belon­ged to the CEO and other execu­tives. The company « made no effort to deter­mine if its products were also compro­mi­sed by hackers, » the WSJ said. Nortel, which sold off parts of its busi­ness as part of a 2009 bankruptcy filing, spent about six months inves­ti­ga­ting the breach and didn’t disclose it to pros­pec­tive buyers.