Dans quelle mesure l'authentification par formulaire de base est-elle sécurisée dans asp.net?
-
02-07-2019 - |
Question
Imaginez que vous ayez un site simple avec seulement 2 pages: login.aspx et secret.aspx. Votre site est sécurisé en n'utilisant que l'authentification par formulaires ASP.net et un contrôle serveur de connexion ASP.net sur login.aspx. Les détails sont les suivants:
- Le site est configuré pour utiliser le fournisseur SqlMembershipProvider
- Le site refuse tous les utilisateurs anonymes
- Les cookies sont désactivés
Il y a évidemment beaucoup de choses à considérer concernant la sécurité, mais je suis plus intéressé par l'expérience zéro code livrée avec le framework .net.
Si, pour répondre à cette question, les seuls points d'attaque sont les zones de texte nom d'utilisateur / mot de passe de login.aspx, un pirate informatique peut-il injecter du code qui leur permettra d'accéder à notre page secret.aspx?
Quel est le degré de sécurité de l'expérience «zéro code» fournie par Microsoft?
La solution
Certaines variables ne sont pas prises en compte:
- Sécurité dans le magasin de données utilisé par votre fournisseur d'appartenance (dans ce cas, la base de données Sql Server).
- sécurité d'autres sites hébergés dans le même IIS
- sécurité générale du réseau des machines impliquées dans l'hébergement du site ou sur le même réseau que celui hébergé
- sécurité physique des machines hébergeant le site
- Utilisez-vous les mesures appropriées pour chiffrer le trafic d'authentification? (HTTPS / SSL)
Ces problèmes ne sont pas tous spécifiques à MS, mais ils méritent d’être mentionnés, car ils sont plus susceptibles de l'emporter sur ceux pour lesquels vous vous posez des questions, à condition qu'ils ne soient pas réglés. Mais, aux fins de votre question, je supposerai qu’ils ne posent aucun problème.
Dans ce cas, je suis presque sûr que l’authentification par formulaires fait ce qu’elle est supposée faire. Je ne pense pas qu'il y ait d'exploit actuellement actif sur le marché.
Autres conseils
Autant que je sache, le mot de passe sera envoyé sous forme de texte brut (mais codé). Le plus important est donc d’utiliser le protocole HTTPS sur les écrans de connexion.
L'autre paramètre semble être sécurisé pour moi.
Avec l'authentification de base HTTP, utilisée par l'authentification de base .NET, pour pouvoir afficher la page secret.aspx, le navigateur doit envoyer une concaténation codée Base64 du nom d'utilisateur et du mot de passe.
Sauf si vous utilisez le protocole SSL, toute personne ayant accès à l'analyse du réseau entre le serveur et le navigateur peut lire ces informations. Ils peuvent décoder le nom d'utilisateur et le mot de passe. Ils peuvent rejouer ultérieurement le nom d'utilisateur et le mot de passe pour accéder à la page secret.aspx.
Cela dit, à moins que vous n'utilisiez le protocole SSL, une personne peut également analyser toute la session d'une autre personne à l'aide de secret.aspx. Par conséquent, elle aurait également accès au contenu de la page.
Eh bien, essayez de regarder dans les coulisses:
Protection par mot de passe
Les applications qui stockent des noms d'utilisateur, mots de passe et autres authentifications l'information dans une base de données ne devrait jamais stocker les mots de passe en texte clair, de peur que le base de données soit volée ou compromise. À cette fin, SqlMembershipProvider prend en charge trois formats de stockage ("codages") pour les mots de passe et mot de passe répond. Le fournisseur Propriété PasswordFormat, qui est initialisé à partir de passwordFormat attribut de configuration, détermine quel format est utilisé:
- MembershipPasswordFormat.Clear, qui stocke les mots de passe et mot de passe répond en texte brut.
- MembershipPasswordFormat.Hashed (valeur par défaut), qui stocke les disques salés des hachages générés à partir de mots de passe et mot de passe répond. Le sel est un hasard Valeur 128 bits générée par le .NET RNGCryptoServiceProvider de Framework classe. Chaque mot de passe / mot de passe réponse paire est salée avec cette valeur unique, et le sel est stocké dans le Le mot de passe de la table aspnet_Membership champ. Le résultat de hacher la mot de passe et le sel est stocké dans le Mot de passe. De même, le résultat de hacher la réponse de mot de passe et la le sel est stocké dans le PasswordAnswer champ.
- MembershipPasswordFormat.Encrypted, qui stocke les mots de passe cryptés et mot de passe répond. SqlMembershipProvider crypte mots de passe et mot de passe en utilisant le chiffrement / déchiffrement symétrique clé spécifiée dans le decryptionKey de la section de configuration attribut, et le cryptage algorithme spécifié dans le section de configuration attribut de décryptage. SqlMembershipProvider lance une exception s'il est demandé de chiffrer mots de passe et mot de passe répond, et si decryptionKey est défini sur Générer automatiquement. Cela empêche une base de données d'adhésion contenant des mots de passe cryptés et mot de passe répond de devenir invalide si déplacé vers un autre serveur ou un autre application.
Ainsi, la force de votre sécurité (clé en main) dépendra de la stratégie de format de protection par mot de passe que vous utilisez:
- Si vous utilisez du texte en clair, il est évidemment plus facile de pirater votre système.
- En revanche, en utilisant Encrypted, la sécurité dépend de l’accès physique à votre machine (ou au moins, machine.config).
- L'utilisation de mots de passe hachés (la valeur par défaut) garantira la sécurité en fonction: a) des inversions connues de la stratégie de hachage de la classe RNGCryptoServiceProvider et b) de l'accès à la base de données pour compromettre le sel généré de manière aléatoire.
Je ne sais pas s'il est possible d'utiliser une sorte de table arc-en-ciel dans le système par défaut de Hash-base.
Pour plus de détails, consultez ce lien: http://msdn.microsoft.com/en-us/library/aa478949. aspx
Si configuré correctement via le fournisseur d'appartenance, vous aurez un niveau de sécurité adéquat. En dehors de cela, l'accès à cette page peut être accessible via des attaques canoniques, mais cela a à voir avec votre sécurité générale. J'ai donné une présentation sur l'utilisation des blocs de Security Enterprise Application . Vous voudrez peut-être vous renseigner sur ces problèmes et les examiner lors de la mise en œuvre de la sécurité sur votre site, et vous tenir au courant des menaces à la sécurité courantes. Aucun site ne sera jamais 100% inaccessible, étant donné que vous êtes sur un réseau partagé ouvert et que la sécurité totale serait un serveur débranché verrouillé dans un coffre-fort gardé 24 heures sur 24 par l'armée (autour du niveau de sécurité "DoD", basé sur Orange livre). Mais la fonctionnalité prête à l'emploi des fournisseurs d'adhésion (lorsqu'elle est configurée correctement) offrira une bonne quantité de sécurité.
Éditer: Oui, je suis d’accord avec l’autre commentaire qui a été fait, HTTPS au moins sur les écrans de connexion est une donnée, si vous voulez protéger le nom d’utilisateur / mot de passe des renifleurs de paquets et des moniteurs de réseau.
Asp.Net prend en charge les sessions sans cookies, comme cet article de blog . Au lieu d'un cookie de session, il utilise un identifiant dans l'URL pour suivre les utilisateurs.
Je ne sais pas si c'est sécurisé, mais je pense que c'est une sécurité, car il est difficile de forcer brutalement la chaîne d'identité.
Il semble que cela fonctionne plus ou moins rapidement, mais lorsque vous redirigez un utilisateur et que vous souhaitez conserver l'état de session, vous devez inclure l'identifiant de session. L'article de blog montre comment faire cela, ainsi que de nombreux autres articles sur le Web.
Voici deux bons articles de Microsoft sur le sujet:
Procédure: protéger l'authentification par formulaire dans ASP.NET 2.0
INFO: aidez l'authentification sécurisée par formulaires à l'aide de la couche Secure Sockets (SSL)
Les cookies sur l'URL ne sont pas suffisamment sécurisés, ils posent de nombreux problèmes (en particulier les fuites de référents si vous en avez) et l'utilisation de HTTPS.