Pour protéger les données des utilisateurs il y a des bonnes architectures et des mauvaises architectures.
C’est aussi simple que cela. Ne vous laissez pas dire que tous les systèmes sont faillibles, qu’il y a de bonnes raisons, ou que ce n’est pas important. C’est vrai, mais il reste que votre architecture peut être bonne ou mauvaise. Ça aura un impact un jour ou l’autre, plus rapidement que vous ne l’espérez.
Stocker en clair c’est mal
Des gens meilleurs que vous s’y sont laissés prendre. Des sociétés solides se sont faites avoir. Y compris des gens qui avaient de bonnes raisons techniques ou fonctionnelles de faire ainsi.
Rien ne change, si vous stockez les mots de passe en clair (ou de façon déchiffrable), un jour une faille logicielle ou système y donnera accès et vous aurez un gros problème avec vos utilisateurs.
Dans le meilleur des cas vous serez prévenus rapidement et vous aurez juste une très mauvaise publicité comme Sony récemment, avec le risque de perdre la confiance de tous vos clients. Dans le pire… vous ne le remarquez que trop tard et vous pouvez mettre la clef sous la porte avec des problèmes juridiques, financiers et humains insolvables.
Ne pas utiliser SSL / TLS pour les communications réseau c’est mal
Des gens meilleurs que vous s’y sont laissés prendre. Des sociétés plus solides se sont faites avoir. Ai-je besoin de tout répéter ?
Si vous ne chiffrez pas toutes les communications réseau avec vos clients dès que vous transférez des données sensibles, vous prenez un risque important pour la sécurité des dites données. Chiffrer uniquement la phase d’authentification ne suffit pas, quoi qu’on vous dise.
Vos utilisateurs ont besoin d’une connexion sécurisée. Tout le reste n’est que bidouillage et mauvaise architecture. Tôt ou tard il y aura un abus d’un état, d’un FAI, d’une entreprise, d’une école, qui aura un peu de publicité et qui vous posera un problème important.
Chiffrer avec la clef de déchiffrage sur le serveur c’est mal
Non, je ne vais pas me répéter encore une fois, si ce n’est pour dire que vous n’êtes pas un cas spécial.
Chiffrer et déchiffrer sur le serveur en laissant la clef sur place, c’est comme avoir une porte blindée avec serrure trois points et laisser la clef sous le pot de fleur à côté. Pour faire court, si c’est le serveur qui chiffre, déchiffre, et gère la clef, c’est comme si vos données étaient en clair, ou presque.
Dropbox avait fait de la publicité autour de la sécurité de leur service. Ils avaient une unique clef de chiffrage, sur leur serveur. Les utilisateurs ont râlé, fait de la mauvaise publicité, et même porté plainte. D’aucuns ont dit que ce n’était pas important.
Voilà hier qu’un problème tiers a donné accès pendant quatre heures à toutes les données de tout le monde, sans mot de passe. Ça ne serait pas arrivé si chaque client gérait sa propre clef, sans la partager avec Dropbox.
Les râleurs n’avaient pas de boule de cristal, ce qui est arrivé était évident. On savait que ça arriverait, et on peut dire que les conséquences ont été les extraordinairement faibles par rapport aux risques. La prochaine fois ce sera bien plus gênant.
Quelle que soit la raison, une mauvaise architecture reste mauvaise
Il se peut qu’on soit obligé d’utiliser une mauvaise architecture. Il se peut que cette mauvaise architecture soit un compromis acceptable, ou même souhaitable en fonction de besoin spécifiques.
C’est rare, tout le monde a tendance à se penser dans le cas exceptionnel alors que ce n’est pas le cas, mais ça peut arriver. Mais, même dans ce cas, il ne faut pas perdre de vue que ça reste une mauvaise architecture, et qu’on en subira les conséquences.
Il y a des bonnes et des mauvaises architectures, c’est ainsi. Faites ce que vous pensez le mieux, il se peut que vous ayez de bonnes raisons de choisir la mauvaise architecture (même s’il y a toutes les chances que vous fassiez erreur). Mais quelles que soient ces raisons, elles ne transformeront pas votre mauvaise architecture en « bonne » architecture. Vous venez de choisir une mauvaise architecture pour de bonnes raisons, voilà tout. Et vous allez le payer.
2 réponses sur « Bon chasseur et mauvais chasseur : architectures et données personnelles »
Nuançons le « Stocker en clair c’est mal ». En effet, il faut être conscient de la relative inutilité du cryptage de mots de passe : en effet, on voit dans des études comme celle de Troy Hunt ( http://www.troyhunt.com/2011/0… ) que la majorité des passwords sont d’une banalité impressionnante.
Donc ( situé dans ce contexte où les utilisateurs protègent mal leurs données) la personne ayant récupéré une base de donnée avec mots de passe cryptés va en décrypter la plupart avec une grande facilité (le salage ne sert ici à rien).Finalement, le cryptage, dans ce cas, n’est qu’une protection contre un utilisateur lambda qui tomberait sur les données, mais pas contre un pirate « mal intentionné ».
Sachant que crypter des données, ça prend du temps, et ce à chaque opération et que dans certain cas, un critère important est la réactivité de l’application web, le stockage en clair devient une option pertinente.
Attention toutefois : cette option n’est pertinente que si des efforts particuliers sont alors réalisés pour empêcher la fuite de donnée, autant bien par des mesures techniques que humaines.
Comme je dis : Il y a plein de bonnes raisons, mais ça reste une mauvaise architecture. Après chacun fait ses choix et assume les conséquences.
Après côté éthique tu es en train de justifier de ne pas sécuriser les mots de passe des gens qui font attention à leur données (et confiance à ton service) par le fait qu’une partie des autres a des mots de passe trop simples. Ça me parait pour le moins discutable.
Bref, je ne suis pas certain que tu tiennes vraiment une bonne raison, mais quand bien même, tu ne fais qu’ajouter au discours : Si tu choisis une mauvaise architecture sur cette base, attention à ne pas croire qu’elle est bonne pour autant, et ne pas oublier les conséquences qu’elle aura.