Comment garantir aux utilisateurs que le site Web et les mots de passe sont sécurisés [fermé]


15

Sur des sites Web fiables, je vois toujours des allégations telles que «Toutes les données sont chiffrées» ou «Tous les mots de passe sont chiffrés à l'aide du chiffrement 128 bits», etc. Cependant, je n'ai jamais rencontré de réclamation comme «Tous les mots de passe sont hachés».

Sur mon site Web, je stocke tous les mots de passe des utilisateurs dans une base de données après avoir utilisé le hachage SHA-512 (le plus probable) avec un sel aléatoire. Je veux ajouter un snipet garantissant aux utilisateurs que leurs mots de passe sont sécurisés afin qu'ils ne soient pas dissuadés d'utiliser mon site Web car il nécessite un mot de passe. Je veux que les utilisateurs se sentent en sécurité mais je ne pense pas que tout le monde sache ce qu'est le hachage.

MA QUESTION: Est-il correct de fournir un message disant que "tous les mots de passe sont cryptés et sécurisés" car je ne pense pas que l'utilisateur moyen saura quelle est la différence entre le hachage et le cryptage, et se sentira plus probablement en sécurité juste parce qu'il voit le mot de confort "cryptage"? Ou existe-t-il un autre message que je devrais fournir?

Soit dit en passant, je suis nouveau dans le cryptage et le hachage de mot de passe et je me demandais si cela serait suffisamment sûr pour l'instant lorsque je lance mon site. Je ne veux pas dire aux utilisateurs qu'il est sécurisé s'il ne l'est pas. Toute information serait grandement appréciée. Merci.


7
Personnellement, je ne m'inquiéterais pas trop de la communication: écrivez une description technique de ce que vous faites, enfoui quelque part au fond de la FAQ où les experts techniques le trouveront. Quiconque d'autre ne s'en soucie pas vraiment de toute façon. Plus important encore: assurez-vous de faire la bonne chose (c'est difficile si vous êtes nouveau, mais au moins vous essayez!). Ne construisez pas votre propre hachage, utilisez quelque chose comme bcrypt .
Joachim Sauer

4
Eh bien, la bonne chose est de fédérer la connexion et de ne pas déranger les utilisateurs avec un autre nom d'utilisateur et mot de passe.
Jan Hudec

1
OpenID est bon, mais le nom d'utilisateur / mot de passe est ok aussi. Je ne pense pas que votre problème soit de persuader les utilisateurs que votre site est sécurisé. Puisque vous êtes inexpérimenté, c'est comme promettre quelque chose que vous n'avez pas. Appliquez simplement des normes communes - vous n'empêcherez pas les pirates professionnels de venir, mais personne ne peut vous en vouloir non plus.
Hoàng Long

3
@coredump Effectivement. L'utilisation de SHA-512 pour le hachage de mot de passe n'est tout simplement pas bonne. Ce n'est pas ok".
Thomas

3
Je serais probablement utile de poser des questions de suivi sur la sécurité de l'information pour vous assurer d'obtenir les meilleurs conseils à jour. (Cela ne signifie pas que vous obtenez de mauvais conseils ici, juste que nous ne sommes pas nécessairement des professionnels de la sécurité).
ChrisF

Réponses:


22
  1. Les utilisateurs s'en moquent.

    La seule fois où ils se soucient, c'est quand quelqu'un retire l'argent de leur compte bancaire et il semble qu'il y ait un lien qui, quelques jours auparavant, quelqu'un a eu un accès complet à votre base de données.

  2. Dans presque tous les cas où j'ai vu de tels messages, ils étaient trompeurs. Le plus hilarant était sur un site Web avec des étiquettes de style «sécurisé de qualité militaire» sur chaque page. Une alerte a indiqué que le certificat HTTP n'est pas valide. Il y avait une injection SQL sur le formulaire de connexion. Quelques semaines plus tard, le site Web a été piraté, puis a disparu pour toujours.

    J'arrête de compter le nombre de sites Web qui prétendent garder les informations sécurisées, tout en ayant un formulaire "Récupérer mon mot de passe", qui envoie en fait le mot de passe d'origine par e-mail.

    C'est comme ces étiquettes "XHTML valides W3C". Pourquoi sont-ils généralement mis sur des sites Web où même une page d'accueil contient au moins des dizaines d'erreurs et de codes comme <DIV COLOR='red'>?

Si vous voulez toujours rassurer les utilisateurs, vous pouvez mettre quelque chose comme:

Vos mots de passe sont sécurisés. N'oubliez pas que nous ne pouvons pas voir votre mot de passe et ne vous enverrons jamais d'e-mail vous demandant d'en fournir un.

Mais franchement, le formulaire "Réinitialiser mon mot de passe" remplaçant le "J'ai oublié mon mot de passe; envoyez-le moi par e-mail" est beaucoup plus rassurant que n'importe quel mot.

Conseils des différents commentaires:

  • Ne réinventez pas la roue: utilisez OpenID. De cette façon, vous ne stockez même pas les hachages.

    Source: commentaire de Jan Hudec .

  • Puisque vous êtes étudiant, open source votre projet. Puisque votre préoccupation est: "Je ne veux pas que les utilisateurs pensent que leurs mots de passe ne sont pas sécurisés parce qu'un enfant à l'école l'a conçu." , rien de plus rassurant que de pouvoir vérifier, en lisant le code source, qu'il a été écrit par un développeur habile qui se soucie de la sécurité.

    Source: commentaire de Jan Doggen .


Merci pour votre contribution. Le problème est que je suis un étudiant qui conçoit un service pour mon université. Je ne veux pas que les utilisateurs pensent que leurs mots de passe ne sont pas sécurisés parce qu'un enfant à l'école l'a conçu. J'ai regardé un tas de méthodes différentes, y compris bcrypt et je n'ai tout simplement pas décidé laquelle utiliser. Je pense qu'il sera suffisamment sécurisé maintenant et si beaucoup de gens commencent à l'utiliser, je peux y ajouter si nécessaire. Je travaille juste pour le faire sortir pour l'instant. Merci encore.
user2698818

3
@ user2698818 Ce que vous devez faire est de concevoir la sécurité, puis de poster une question la décrivant en détail et de demander «est-ce sécurisé (suffisant)». Une bonne sécurité peut être totalement publique.
Jan Doggen

@ user2698818: ok. Modifié ma réponse.
Arseni Mourzenko

6
@JanDoggen: eh bien, ce qu'il devrait faire, c'est utiliser un système de sécurité existant que quelqu'un d'autre a conçu et demandé "est-il suffisamment sécurisé". De préférence celui où cette question est posée depuis un certain temps et a attiré l'attention de plusieurs experts dans les domaines ;-)
Joachim Sauer

12

Ne stockez pas les mots de passe en premier lieu! Suivez l'exemple de Stack Exchange et laissez les utilisateurs se connecter avec leur identité sur un autre site qui fournit une authentification via OpenID . Les implémentations sont disponibles gratuitement pour la plupart des frameworks Web courants.

Ou éventuellement tout autre protocole. S'il s'agit d'un projet interne pour une institution (comme le suggère votre commentaire sur l'autre réponse), il existe presque sûrement déjà un LDAP, Kerberos (Windows Active Directory est également basé sur ces deux; apache prend en charge l'authentification HTTP contre eux) ou certains un tel service pour la connexion à l'ordinateur. Connectez-vous simplement à cela.

Cela vous évite de stocker des informations sensibles (vous devrez probablement stocker des autorisations, mais elles ne sont pas si critiques) et les utilisateurs d'avoir à se souvenir d'un autre nom d'utilisateur et mot de passe, donc globalement gagnant-gagnant.


1
Veuillez me dire quels sites vous avez créés afin que je puisse les éviter si vous considérez les autorisations comme non critiques pour la sécurité.
orlp

1
Et si l'exigence est de stocker les mots de passe. De plus, la question porte spécifiquement sur leur stockage.
Piotr Kula

3
@ppumkin: Il y a beaucoup de questions du type "comment utiliser X pour faire Y" où la meilleure réponse est "vous utilisez Z". Si vous n'êtes pas d'accord, fournissez simplement une meilleure réponse ;-).
Jan Hudec

3
@ppumkin Pour utiliser une analogie: "J'essaie de briser un rocher avec mon poing, quels gants dois-je utiliser?" Vérifiez s'ils connaissent les ciseaux avant de proposer des gantelets de cavalerie allemands du 19e.
deworde

1
J'éviterais d'être trop rapide pour suggérer OpenID. Oui, c'est génial, mais cela fonctionne généralement mieux si vous prenez en charge plusieurs fournisseurs OpenID / OAuth. Il existe de nombreux forums techniques, blogs, questions-réponses, etc., où vous devez vous connecter via le fournisseur OID de Facebook et ne pouvez en utiliser aucun autre. Je suis sur un réseau de travail qui bloque les domaines Facebook en gros, et je ne peux donc pas travailler avec ces sites. Si vous allez prendre en charge OID et que vous n'en utiliserez qu'un pour le moment, choisissez un fournisseur qui est populaire parmi votre public cible et qui ne sera probablement pas bloqué par un administrateur système. Google et Windows Live sont de bons choix.
KeithS

2

En disant:

"C'est sûr."

est un jugement personnel que vous portez sur certains faits ou processus technologiques, et ce jugement est limité par ce que vous savez vous-même sur la sécurité à ce moment-là. Mais pouvez-vous garantir sans aucun doute que votre cryptage, votre méthode de stockage, etc. résisteront à tout type d'attaque, même celles que vous ne connaissez pas ou que vous ne connaissez pas encore?

Signification: Cette déclaration risque d'être obsolète, peut-être même sans que vous en soyez conscient.

J'ai donc tendance à être d'accord avec le commentaire ci-dessus de @JoachimSauer: décrivez simplement ce que vous faites, comment vous enregistrez les informations utilisateur et dites aux utilisateurs comment cela est censé sécuriser votre service. Laissez ensuite les utilisateurs juger par eux-mêmes.


Non, "c'est sécurisé" n'est pas une déclaration "personnelle" ou subjective, ce n'est pas comme "c'est joli", pour moi . Il s'agit en fait d'une déclaration sémantiquement vide , sans spécifier "par rapport à quoi" ou "à l'abri de quelles attaques" ou "à quel niveau dans quel contexte". Si l'intégralité de votre déclaration consiste en "ceci est sécurisé", il est obsolète avant que vous ayez fini de le taper, et il est fort probable que vous n'en ayez pas connaissance. Je suis d'accord cependant sur la dernière partie, c'est une question de détails.
avid

@AviD: Vous avez peut-être trop lu dans mon choix de mots. Oui, dire que quelque chose "est sécurisé" sans donner plus de détails n'a pas de sens. Mais je reste convaincu que c'est aussi un jugement personnel, parce que tout le monde n'a pas exactement le même sens et les mêmes exigences de «sécurité»: ce que A trouve suffisamment sûr pourrait ne pas être sûr pour B. Donc, dire que quelque chose «est sûr» suggère que le la personne qui fait la déclaration "la trouve en sécurité". Et ce n'est pas un argument avec le même poids que de donner à quelqu'un les faits pertinents et de le laisser tirer sa propre conclusion.
stakx

Bien, "par rapport à ce que" je voulais dire pour quelles exigences, profil de sécurité, risques, etc. Toujours pas un jugement personnel, mais peut-être ce que vous vouliez dire par "personnel" est ce que je veux dire par "contexte". "Sécurisé" est une métrique scientifique difficile, pas un "sentiment" délicat. Mais oui, comme vous le dites, ne me dites pas que c'est "sécurisé", dites-moi ce que vous avez fait pour qu'il en soit ainsi.
AviD

@AviD: OK. Je n'insisterai pas davantage sur l'argument, sauf pour dire que la sécurité est aussi un sentiment insipide. C'est bien sûr plus que cela, mais quand la question est de «rassurer» les utilisateurs (voir le titre de la question), c'est le sentiment de larmes qui compte au final.
stakx

1

Cela dépend vraiment du contexte de votre site Web spécifique.

Par exemple, s'il s'agit d'un site Web grand public, il y a de fortes chances que la plupart d'entre eux ne se soucient que de leurs mots de passe (peut-être), de leurs informations financières / de santé (selon), et de leurs informations privées telles que des photos (hahaha, ouais c'est vrai ...) .

S'il s'agit d'une application métier, le niveau de sécurité de l'ensemble du site est pertinent, pas seulement les mots de passe. De même, cela dépend de qui sont vos utilisateurs cibles - hautement technique / pas si technique, etc.

Tout ce contexte définit considérablement ce que vous devez communiquer et le niveau d'assurance requis.

Par exemple, pour les consommateurs non techniques, il suffit d'avoir des commentaires génériques et simples, tels que:

Ce site est construit en utilisant des techniques de sécurité de pointe. Votre mot de passe est toujours crypté et nous n'enverrons jamais vos photos à la NSA.

(Et, comme d'autres l'ont dit, il vaut mieux ne pas avoir du tout de mots de passe, utilisez un standard comme OpenId ou OAuth.)

Pour les entreprises hautement techniques, vous voudriez avoir une page complète de détails techniques et procéduraux, tels que:

Nous avons mis en place un SDL complet (cycle de vie de développement sécurisé) tout au long de notre processus de développement et de déploiement.
...
Notre architecture de sécurité est ... Cela donne les avantages de ...
Nous assurons un codage sécurisé tel que ... par ... Nous effectuons ces tests et ceux-ci.
Notre cryptographie comprend ces algorithmes ... et ... Nous sommes conformes à la réglementation de l'industrie dont vous avez besoin et certifiés pour ...
Notre sécurité est vérifiée par ce consultant tiers indépendant.
...
Pour plus de détails, et pour revoir nos politiques ou pour organiser un audit indépendant, veuillez en discuter avec le service marketing.

Bien sûr, vous ne voulez pas donner trop d'informations détaillées, cela devrait être plus sur le processus que sur les mots de passe eux-mêmes ... Et bien sûr, cela devrait aller de soi que la réalité devrait en fait être conforme à tout ce que vous y écrivez , quel que soit le contexte avec lequel vous traitez.

Comme l'une des réponses a fait allusion, la plupart des utilisateurs ne s'en soucient pas, ne comprendraient pas ce que vous leur dites et continueraient de s'inscrire de toute façon, même si vous dites que vous ENVOYEZ des données utilisateur à la NSA.
Ce n'est pas pour eux.
Ils seraient tout aussi heureux de ne pas avoir de mot de passe, laissez-moi simplement choisir mon nom d'utilisateur dans la liste et me connecter automatiquement.

De toute évidence, c'est pour le petit pourcentage de ceux qui se soucient - vous devez permettre aux utilisateurs intelligents de faire ce qui est bien, de leur donner les informations dont ils ont besoin et de leur accorder l'éducation qu'ils pourraient demander.
Si vous ne le faites pas, lorsque cela se passe mal, les 98% restants se réveillent soudainement et se mettent en colère.
("Bien sûr, je savais que je n'avais pas besoin d'un mot de passe pour voir mes photos, mais je ne pensais pas que quelqu'un d' autre pouvait aussi les voir !!")


0

Si vous voulez que votre système soit sécurisé, la force de l'algorithme de mot de passe n'a pas de sens - la plupart des pirates peuvent casser des mots de passe en un rien de temps, surtout si le mot de passe choisi est petit ou est composé de mots génériques que le pirate a déjà "craqué et stocké" "utilisant des tables arc-en-ciel et similaires. Lisez l'article d'ArsTechnica sur le craquage de mots de passe pour plus d'informations.

Ce que vous devez faire, c'est assurer aux utilisateurs que les méchants ne peuvent pas se mettre à la place en premier lieu. Une entreprise soucieuse de la sécurité pour laquelle je travaillais avait un système Web à 3 niveaux où les serveurs Web n'étaient physiquement pas connectés aux serveurs de base de données. Quand mon patron a voulu mettre son site Web et avoir un accès direct à la base de données (code mal conçu, 'nuff a dit), on lui a dit qu'il ne pouvait pas l'avoir, et quand il a poussé ... on lui a dit qu'il n'y avait pas de fils entre eux . Il a dû le concevoir afin qu'il transmette toutes les demandes de données via un service de niveau intermédiaire. Et ces services étaient non seulement sécurisés, mais exposaient une surface minimale aux attaques et étaient verrouillés. Et la base de données n'a jamais exposé aucune de ses tables pour la lecture, seules les procédures stockées qui à leur tour ont été verrouillées, de sorte que seul le service concerné y avait accès.

Ce n'était pas aussi mauvais à coder que vous ne le pensez, une fois que vous connaissiez l'architecture et la séparation de chaque niveau, c'était assez facile à coder.


0

Vous pouvez développer le site le plus sécurisé de la planète et avoir une expérience utilisateur vraiment médiocre. Les utilisateurs supposeront que votre site n'est pas sécurisé.

Vous pouvez créer le site le moins sécurisé de la planète et avoir une expérience utilisateur incroyable. Les utilisateurs supposeront que votre site est sécurisé. Du moins jusqu'à ce qu'il apparaisse dans les nouvelles du soir.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.