Dans quelle mesure l'authentification par formulaire de base est-elle sécurisée dans asp.net?

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?

Answer 1

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é.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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)

Answer 8

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.