Est-ce suffisamment de sécurité?
J'obtiens mon prochain système de connexion pour les administrateurs d'un site Web de commerce électronique, qui aura ceci:
- le formulaire de connexion est SSL sécurisé
- le mot de passe est converti en SHA-256 avant d'être transmis (BCRYPT est trop lent pour le client JS/Navigateur)
- bCRYPT stocké hachage (je ne veux pas que ma base de données soit jamais volée à être facilement brisée)
- le mot de passe haché est crypté avec clé privée stockée comme constante dans l'application ou le fichier
- un hachage de toutes les valeurs de base de données de connexion importantes pour cet utilisateur, de sorte que si elles sont modifiées par injection d'une manière ou d'une autre, le hachage ne correspond pas et le compte est verrouillé
- reCAPTCHA lors de la première insuffisance de connexion
- système de frappe de connexion par périphérique, donc si l'utilisateur essaie 5 connexions différentes et ils sont tous faux, il est sorti - ce n'est pas 5 par login
- deuxième étape Auth. Utilisation de SMS, de courrier électronique ou d'alterego - peut-être une fois par lieu + Emplacement et d'être utilisé si vous souhaitez modifier votre mot de passe.
- si vous vous connectez à partir d'un emplacement différent différent de l'historique, envoyez SMS ou courrier électronique à l'utilisateur
- si les informations de périphérique ou d'emplacement changent lors de la connexion, TuR Session (pour empêcher la vol de la session)
- autoriser l'historique de connexion à nettoyer d'anciens périphériques (les utilisateurs peuvent supprimer des périphériques qu'ils n'utilisent plus)
- avoir la possibilité de sauvegarder le périphérique de connexion + l'emplacement de l'historique (c'est-à-dire que vous n'utilisez pas cette option si vous êtes sur un réseau NetCafe ou un réseau public, etc.) afin qu'il demandera toujours votre deuxième étape
Est-ce suffisamment de sécurité? Pensez-vous que je vais trop trop manger?
Méfiez-vous des surpuissant, il est contre-productif. Si votre système de connexion est trop gênant ou ennuyeux, les utilisateurs tentent activement de travailler autour d'elle. " Les utilisateurs ", ici, comprend les développeurs d'applications et les administrateurs de serveur.
le formulaire de connexion est SSL sécurisé
Celui-ci est le plus important, mais pas " seul ". En théorie, tout le site doit être sécurisé avec SSL, non seulement le formulaire de connexion. SSL fournit la confidentialité en ce qui concerne les oreilles indiscrètes, mais si elle se traduit par un cookie que vous envoyez ensuite en clair pour maintenir la session, puis un indiscret il suffit d'envoyer le même cookie à Hijack une session. Si seul le formulaire de connexion est protégé par SSL, la seule sécurité que vous obtenez ici est en combinaison avec une formation anti-hameçonnage complet: vous éduquer les utilisateurs d'envoyer en leur abstenant mot de passe pour les sites qui n'ont pas SSL actif, et donc vous avez besoin d'un site SSL vous. Mais c'est marginal.
mot de passe est converti en SHA256 avant d'être transmis (bcrypt est trop lent encore JS/navigateur client)
Celui-ci est inutile. Cela signifie simplement que le résultat SHA-256 est le mot de passe. Si elle peut être saisie par un attaquant, l'attaquant peut l'utiliser pour vous connecter, sans même connaître le mot de passe " vrai ".
mot de passe est crypté avec hachage clé privée stockée sous forme CONSTANT dans app/fichier
Cette fonction est un gain de sécurité que dans la situation où l'attaquant pourrait obtenir les mots de passe hachés, mais pas l'application fichiers eux-mêmes. Que ce soit une situation réaliste est discutable. D'autre part, cette touche constante embêter les administrateurs lorsque l'application doit être mis à jour, et peuvent entraîner des temps d'arrêt supplémentaire (il est si facile de l'oublier lors du déploiement ...). En outre, ce qui rend la confidentialité de l'application dépose un objectif important, ce qui est assez rare.
recaptcha sur 1er échec de connexion
Ce sera plus ennuyeux que sûr.
connexion système de frappe par appareil, donc si l'utilisateur essaie 5 connexions diff et theyre tout faux, il est sorti. ce ne est pas 5 par login
Ne pas bloquer les comptes, il suffit d'ajouter des retards (par exemple une minute). Dans le cas contraire, tout le monde peut verrouiller le compte de personne, ce qui est un problème. Compter essais par appareil est bon, mais est subtile et peut se retourner contre: il y a des réseaux (y compris ISP) là-bas avec massif NAT ou mandatement, qui se transforment en, du point de vue du serveur , des milliers de demandes de connexion de la même adresse IP source.
auth 2step par sms, email? ou AlterEgo - peut-être une fois par appareil + emplacement et à utiliser si vous voulez changer votre mot de passe
si la connexion d'un autre emplacement différent de l'histoire, envoyer des SMS/Email à l'utilisateur
SMS peut agacer les utilisateurs: ils ne fonctionnent pas bien pour les utilisateurs internationaux, ils ont besoin d'un téléphone mobile fonctionnel sur place, et certaines personnes sont chargées du SMS qu'ils reçoivent (cela dépend du pays et opérateur de téléphonie mobile). le courrier électronique est un peu mieux (mais, bien sûr, non si l'application que vous essayez de protéger est un webmail ...).
ont option pour enregistrer dispositif login + emplacement dans l'histoire (par exemple ne l'employez pas cette option si votre à un netcafe ou un réseau public, etc.) il sera toujours demander votre 2step
Notez que dans un netcafe, la sécurité va dans l'évier. Un keylogger est trop invisible. Il n'y a pas grand-chose que vous pouvez faire contre cela.
Pense donc je vais Overkill?
Oui. Mais, plus important encore, il vous manque aussi la caractéristique importante, qui est SSL du site à l'échelle.
Les facteurs clés que je recherchent toujours dans une définition de projet sont manquants ici:
Qu'est-ce que vous protégeez-vous? Qui le protège-tu? Quel est l'impact s'il est compromis?
Si vous protégeez votre liste d'anniversaires d'amis, il est presque certainement trop exclu. Si vous protégeez le matériel haut secreté de l'espionnage international ou d'entreprise, cela pourrait bien être trop faible.
Vous devez penser au risque potentiel, les acteurs de la menace qui peuvent vous cibler, ainsi que d'autres facteurs tels que la résilience (une connexion échouée le lundi matin le rendent extrêmement difficile pour qu'un utilisateur ait accès lorsqu'ils ont vraiment besoin de)
J'espère que vous avez des réponses à celles-ci, mais à moins que vous ne les postez ici, il peut être difficile pour les autres de fournir des conseils sur l'architecture de sécurité.
Vous utilisez beaucoup de mots à la mode de sécurité ici - mais le résultat final n'est pas aussi sécurisé que devrait être, et comme le dit Lucanos, il y a beaucoup de redondance.
Allez lire ce fil .
le mot de passe est converti en SHA256 avant d'être transmis (BCRYPT est trop lent encore pour le client JS/Navigateur) BCRYPT STOCKED HASHES
Cela signifie-t-il que vous générez un hachage BCRYPT du hachage SHA256 du mot de passe? Sans sel, le mot de passe SHA256 ne fait rien pour aider la sécurité, et en utilisant une deuxième série de hachages n'aident pas non plus.
le mot de passe haché est crypté avec une clé privée stockée comme constante dans l'application/fichier
Quoi? Pourquoi? Voulez-vous déjà récupérer le hachage du hachage du mot de passe? Même si vous l'avez fait, la façon de faire cela serait de chiffrer à l'aide d'une clé publique.
reCAPTCHA sur 1er échec de connexion
N'ajoute pas beaucoup de valeur.
si les informations de l'appareil/de l'emplacement changent lors de la connexion, de la session Kill
Nous parlons donc de la gestion de la session ainsi que de l'authentification - dans ce cas, vous avez toujours beaucoup de travail à faire.
Il y a quelques choses que je ne suis pas ici, et probablement une ou deux choses intéressant d'ajouter:
- mot de passe est crypté avec hachage clé privée stockée sous forme CONSTANT dans app/fichier
En tant que " CONSTANT " - qu'est-ce que cela veut dire? Est-il codé en dur? Comment est-il protégé. Je suis d'accord avec les autres commentaires que le sel est un bon plan - si vous le sel et le hachage des mots de passe, je ne vois pas nécessaire pour le chiffrement sur le dessus de celui-ci. Et - si la clé privée pour votre cryptage est stocké dans un fichier plat ou codé en dur dans l'application, vous avez une faiblesse là. Recommander trouver un moyen de mieux protéger cette clé.
- " Par dispositif "
Dans un certain nombre d'endroits où vous mentionnez que vous êtes comportement de suivi " par appareil " - qu'est-ce que cela veut dire? Comment déterminerez-vous ce que l'appareil est? Vous insinuez un type d'authentification de l'appareil ici, et de ce peu que je connais ce domaine, la plupart des voies sont extrêmement outrepassées, et les moyens qui ne sont pas besoin d'émission d'appareils à partir d'un point de confiance, ce qui peut grandement changer votre modèle de fonctionnement .
Dans les endroits où vous dites " par appareil ", vous allez devoir réfléchir à ce que cela signifie si l'appareil est truque votre système. En outre, si vous avez décidé que " Adresse IP " = " device ", alors vous pouvez avoir à envisager de nombreuses situations où l'adresse IP de l'utilisateur est en train de changer sans faute de l'utilisateur.
- permettent de l'histoire se connecter pour frottait des anciens appareils
Est-ce quelque chose que vous êtes complètement prêt à soutenir? LE LAVAGE, par exemple, un cookie est assez facile, mais voulez-vous dire toutes les parties de la mémoire? Personnellement, si je faisais cette promesse, j'enveloppèrent une certaine façon de sorte que si les informations de connexion a été mis quelque part étrange par le système d'exploitation, que ce n'était pas une violation de ce que mon système avait promis aux utilisateurs.
Je vois aussi quelques problèmes:
- Comment un utilisateur peut récupérer d'une perte/mot de passe oublié?
Je vois que vous citant un processus assez impliqué pour le changement de mot de passe. Si ce système est un web occasionnel, je serais prêt à parier de l'argent que ce sera votre fonction la moins utilisée. Au lieu de cela, l'utilisateur se dérive du système, pour revenir et ont besoin de leurs mots de passe et les ont complètement oublié (ou ils les a écrites sur une note collante sur leurs écrans ... qui est encore pire).
Vous aurez besoin d'un moyen de faire la récupération de mot de passe/réinitialisation qui correspond à votre modèle de haute protection. Est-il doté d'une personne? Est-ce qu'ils ont des questions de sauvegarde à répondre? Obtiennent-ils un mot de passe de réinitialisation envoyé par courriel pour les sortir de la bande? Chaque mécanisme de récupération comporte un risque, et généralement moins de risque = coût plus élevé - par exemple, contrôle d'identité ultime de ma compagnie de carte de crédit pour les questions comme celle-ci est un Q & A douloureuse avec une personne vivante sur mes antécédents d'achat. Très bon, mais cher en termes de salaire de cette personne.
- Une façon simple pour les utilisateurs du système de vétérinaire
Le titre présenté par le serveur SSL devrait être assez bon, mais très peu d'utilisateurs sont avertis PKI assez pour cela. Je sais que les grandes institutions financières ont commencé à faire usage des mots et des images sélectionnées par les utilisateurs que les utilisateurs sont censés vérifier lors de la connexion. L'objectif est d'éviter tout ici une situation où un fraudeur pourrait envoyer votre utilisateur un courrier électronique les diriger vers " paypa1.com " (numéro 1 pas l), et d'obtenir leur mot de passe. Puisque vous n'avez des fonctionnalités qui accommodent la connexion à distance, votre attaquant sera alors en mesure d'utiliser un compte utilisateur légitime de tout système.
- Autre ingénierie sociale
Ces deux questions ne sont probablement pas les seuls processus axés sur l'homme dont vous aurez besoin de réfléchir à - vous connectez accès? Avez-vous un plan d'audit de connexion séparé des privilèges d'administration? Dans quelle mesure l'accès ne admins ont et comment le système protégé contre eux? Y a-t-il d'autres attaques d'ingénierie sociale qui pourraient travailler?
Jusqu'à présent, ce que vous contour est tech-lourd, et la lumière humaine - vous parlez deux mécanismes qui peuvent avoir un impact de la facilité d'utilisation, ce qui pourrait entraîner des utilisateurs de ne pas utiliser le système ou les utilisateurs prenant des mesures pour pirater le système rendre plus facile à utiliser, et je crains que vous ne l'avez pas pensé les vecteurs d'attaque d'un ingénieur social. Tout comme l'eau, les pirates trouveront la fissure ou une crevasse qui est plus facile à utiliser.
Je vous frapper avec les trucs lourds ici, parce que ma perception est que vous essayez de concevoir quelque chose de fin un peu élevé pour quelque chose qui est sans doute un risque élevé. Si c'est ce que vous essayez de concevoir, alors vous devez sauvegarder et voir le entier système - votre communauté d'utilisateurs, naissance à la mort des comptes, le comportement au sein du système et les risques de mauvais comportement.
Je vais juste proférer quelques questions à essayer et à éduquer moi-même et 2) vous donner une perspective différente sur le système:
le mot de passe est converti en SHA256 avant d'être transmis (BCRYPT est trop lent encore pour le client JS/Navigateur)
Si vous utilisez une connexion SSL pour commencer, devez-vous faire cela? Même si quelqu'un a pu intercepter le mot de passe haché, comment est-ce plus sécurisé que d'intercepter le mot de passe en plainte? Si j'ai pu utiliser le login et envoyer la même charge utile hachée, comment est-ce différent?
un hachage de toutes les valeurs de base de données de connexion importantes pour cet utilisateur, de sorte que si elles sont modifiées via une injection d'une manière ou d'une autre, le hachage ne correspond pas et le compte est verrouillé
Donc, si l'utilisateur met à jour leur adresse e-mail ou leur mot de passe, le hachage changera et la session se terminera? Ou avez-vous des sauvegardes pour permettre ces changements légitimes?
si les informations de l'appareil/de l'emplacement changent lors de la connexion, TuR Session (pour empêcher la vol de la session)
Non sûr à 100% à ce sujet, mais cela pourrait-il signifier un combiné mobile peut être lancé à partir d'une session (légitime) si elle transitions de wifi à GSM/cellule, GSM/cellule au WiFi ou éventuellement dans le réseau GSM/Cellule (si elle change L'adresse IP publique présentée par l'appareil)?
système de connexion de connexion par périphérique, de sorte que si l'utilisateur essaie 5 logines DIFF et ils sont tous faux, il est sorti. ce n'est pas 5 par login
Comment suivez-vous "par périphérique"? Par l'adresse IP? Il peut être partagé. Par un cookie? Il peut être purgé. Par une chaîne d'agent utilisateur? Cela peut aussi être changé.
Outre ceux-ci, certaines des autres idées sonnent bien.
ok donc c'est ce que j'ai appris des réponses de chacun
- Utilisez SSL, pas besoin de hachage le côté du client de mot de passe comme son inutile, SSL est la bonne façon de protéger de renifler.
- Utilisez BCRYPT (w/sel) pour stocker le puits de mot de passe, Scrypt si je peux trouver un PHP implémentation de celui-ci.
- Ne bloquez pas la connexion en panne pour un mot de passe échoué, utilisez simplement une limite de temps croissante pour éviter les DOS. Ça va enregistrer les tentatives infructueuses et alerter les administrateurs si son devient inhabituellement élevé.
- cryptage et réhabation des mots de passe est inutile
- considérons des moyens de vétériner le système et de prévenir l'ingénierie sociale
- forcer des mots de passe longs et durs sur les utilisateurs, comme Utilisez PASSWDQC pour vérifier et laisser les utilisateurs savoir quels mots de passe sont attendus.
- verrouillage en raison des changements de périphérique/emplacement peut être problématique sur les téléphones portables, sans fil ou certains fournisseurs de services Internet, envisagez peut-être simplement de vous déconnecter de la session.
- besoin de mettre correctement la gestion de la session
- la session d'administration devrait rester dans la zone SSL.