Meilleures pratiques pour l'authentification / la sécurité des applications Web (toute plate-forme)

J'ai eu une question aujourd'hui de la part de mon responsable me demandant ce que je considère comme une conception acceptable pour l'authentification d'une application de formulaire Web, en particulier en ce qui concerne la nature de nombreux navigateurs populaires, à "Mémoriser le mot de passe" pour vos champs de connexion de mot de passe de nom d'utilisateur typiques .

J'ai du mal à trouver une réponse qui me semble acceptable. À la lumière des failles de sécurité embarrassantes de Sony, je veux vraiment être prudent, même si les données stockées sur les personnes sont d'une sensibilité moindre. Nous ne stockons pas de numéros de sécurité sociale ni même d'adresses, mais nous stockons des numéros de téléphone, des adresses e-mail et une photo d'un visiteur.

Il craint qu'un utilisateur puisse simplement mémoriser le mot de passe sur un terminal public, puis que quelqu'un puisse simplement sauter sur ce terminal et commencer à visualiser ou à modifier des données de manière non autorisée. Cependant, je suis assez certain qu'au moins sur les postes de travail Windows, le navigateur ne "mémorisera pas le mot de passe" sur les comptes d'utilisateurs Windows.

Au-delà de cela, j'implémente un cryptage de mot de passe unidirectionnel côté serveur (stocker le mot de passe crypté dans la base de données, crypter le mot de passe fourni par l'utilisateur sur le serveur, comparer à la chaîne cryptée de la base de données). Il n'y a pas de plans immédiats pour incorporer le cryptage SSL, mais c'est toujours une option.

Existe-t-il des failles de sécurité majeures dans cette approche? Avez-vous de meilleures suggestions?

Quelques conseils de haut niveau:

1. Stockez uniquement les données dont vous avez besoin
2. Chiffrez toujours les données sensibles (SSN, mot de passe, numéro de carte de crédit, etc.) lorsque vous les stockez
3. Chiffrez toujours le trafic à l'aide de SSL lors de la transmission / réception de données sensibles
4. En cas de doute sur la sensibilité des informations, chiffrez-les
5. Ne faites pas confiance à la saisie de l'utilisateur (quelqu'un tentera de saisir quelque chose de mauvais)
6. Ne faites pas confiance à vos données (quelqu'un peut les changer dans la base de données - injecter un script malveillant par exemple)
7. Ne roulez pas votre propre cryptage
8. Sécurisez les serveurs hébergeant les applications / bases de données
9. Augmentez la charge des utilisateurs finaux pour des raisons de sécurité (restrictions de mot de passe, n'exposez jamais les mots de passe, n'envoyez pas d'URL par e-mail, réduisez le temps de session, etc.)

Ma suggestion serait de vous procurer un livre sur la sécurisation des applications Web. Il y a tout simplement trop d'informations à transmettre dans une seule réponse / blog / article. Le sujet du chiffrement à lui seul est important.

Vous pouvez essayer de contourner le comportement du navigateur - quelques bons conseils ici:

/programming/32369/disable-browser-save-password-functionality

Je dirais que ça devrait aller.

La plupart des utilisateurs seront suffisamment intelligents pour ne pas enregistrer leur mot de passe sur un terminal public, et les mots de passe seront stockés par profil. Gardez à l'esprit qu'ils pourraient tout aussi bien l'écrire sur une note autocollante ou utiliser un mot de passe faible.

Si la page de connexion n'est pas chiffrée via SSL, il ne serait pas trop difficile pour un attaquant de renifler ce mot de passe lors de son déplacement sur le réseau. Bon travail de hachage du mot de passe dans la base de données, qui empêchera un attaquant potentiel de voir les mots de passe de tout le monde (qu'ils pourraient utiliser avec l'adresse e-mail pour tenter de se connecter à d'autres sites sur lesquels l'utilisateur pourrait se trouver.)

Si vous le souhaitez, il existe des moyens de désactiver le comportement du navigateur, comme l'a souligné Chad. Je ne l'ai vu que moi-même sur le site Web de ma banque et sur le système Live de Microsoft.

À un certain moment, vous ne pouvez pas (et n'êtes pas légalement tenu de) protéger un utilisateur contre lui-même. La fonctionnalité "Mémoriser le mot de passe" peut être risquée, mais c'est un risque assumé par l'utilisateur. De même, si l'utilisateur décide de réutiliser son mot de passe pour plusieurs services, il assume également ce risque. Vous n'êtes pas non plus tenu de les avertir de ne pas écrire leur mot de passe sur une note autocollante et de le coller sur leur moniteur, même si les utilisateurs le font souvent aussi.

Autrement dit, jusqu'à ce que quelqu'un plaide avec succès et change les règles. Voir aussi: "Avertissement: le contenu peut être chaud".

Je ne pense pas que vous puissiez contrôler de manière fiable si le navigateur se souvient ou non d'un mot de passe. C'est tout simplement hors de vos mains, que le navigateur le fasse ou non. Ce n'est pas non plus nécessairement un énorme risque pour votre sécurité . Vous devez toujours supposer que les attaques peuvent être effectuées à partir de connexions valides. Ne présumez pas parce que quelqu'un a un utilisateur / pass de connexion valide qu'il ne sera pas bon. Après tout, les mots de passe peuvent tomber entre de mauvaises mains de plusieurs façons.

Je suppose que ce que vous pourriez faire est de randomiser les noms de champs dans votre formulaire de connexion à chaque fois. Au lieu de <input name="username", utilisez quelque chose comme <input name="user658667587". Cela rendrait les noms d'utilisateurs mis en cache assez inutiles. Mais je ne sais pas si les frais généraux en valent la peine. Sans parler des inconvénients pour les utilisateurs qui ne sont pas sur des machines publiques.

Si vous êtes dans une situation extrêmement sensible à la sécurité (banque, investissement), vous pouvez simplement demander aux gens lors de la connexion s'il s'agit d'une machine publique. Vous pouvez également mettre en cache les adresses IP connues lorsque les gens se connectent, et s'ils se connectent à partir d'un emplacement différent nécessitent un numéro d'identification non typable (par exemple, cliquez sur les images) en plus de l'utilisateur / passe normal. Ma banque fait quelque chose de similaire.