Discussion :

[jgrmstr]

Bonsoir,

Mes questions ici ont peu à voir avec le langage lui-même mais plutôt avec la sûreté des procédures utilisées.
En effet je me demande actuellement quel est le plus sûr moyen de gérer l'authentification à un site web par session.

Admettons que j'ai dans ma base de données une table Utilisateur avec pour champs _Login et _MDP.
Comment gérer l'authentification sur mon site ?
Bien sûr, après avoir validé le formulaire de connexion, vérifier la correspondance login/mdp est très simple, mais ma question porte sur la suite :
Une fois que cette connexion a été approuvée, que dois-je ou que puis-je stocker en session pour garder la connexion de l'utilisateur active par la suite ?
Je stocke bien évidemment le login.
Dois-je également stocker en session le hash du mot de passe, pour ensuite à chaque page refaire une vérification du couple login/mdp ?
Ou bien dois-je faire confiance à la session et ne pas renouveler les tests, mais simplement me baser sur le login stocké en session ?

[meziantou]

Je te conseille de regarder les MembershipProvider. Si tu utilises une base de données SQL Server tu as la classe SqlMembershipProvider.
http://msdn.microsoft.com/fr-fr/libr...(v=vs.80).aspx

[jgrmstr]

J'ai connaissance de cela, mais si justement je veux m'en passer au profit de mon propre système ?

[meziantou]

Si le SqlMembershipProvider ne te correspond pas, rien ne t'empêche d'implémenter ton provider en héritant de la classe MembershipProvider.

Pour garder la connexion active tu peux utiliser la méthode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FormsAuthentication.SetAuthCookie(UserName, RememberMe);

pour se déconnecter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FormsAuthentication.SignOut();

[jgrmstr]

Je te remercie pour tes réponses, néanmoins je vais poser la question autrement car je désire vraiment ne pas passer par ce système.
Ma demande pourrait se résumer en fait à "est-ce que stocker en session login et hash du mot de passe" est sécure ? Afin de refaire les tests à chaque page.
Et aussi, est-ce qu'en .NET et IIS, il est facile d'usurper des sessions ? Car je viens du monde PHP, et je sais qu'il est possible de voler ou "spoofer" des sessions.

[meziantou]

Je te remercie pour tes réponses, néanmoins je vais poser la question autrement car je désire vraiment ne pas passer par ce système.

Tu ne sais pas ce que tu rate ! Tu ne pourra pas utiliser tous les mécanismes mis en place dans le framework dotnet et qui permettent de se simplifier la vie.

Ma demande pourrait se résumer en fait à "est-ce que stocker en session login et hash du mot de passe" est sécure ?

La session permet de stocker des valeurs seulement accessible par le serveur pour chaque utilisateur. Tu n'a pas besoin de mettre le login et le mot de passe dans la session. Un booléen indiquant si l'utilisateur est connecté pourrait suffire.
Voici un lien expliquant ce qu'il faut stocker dans la variable de session, vu que c'est ce que tu souhaite faire
http://stackoverflow.com/questions/1...225668#1225668

PS: Ne stocke jamais le hash du mot de passe seul dans la base de données. Il faut utiliser un sel en plus ! Chaque utilisateur a donc un login, un sel et un hash (SHA256 par exemple)

Et aussi, est-ce qu'en .NET et IIS, il est facile d'usurper des sessions ? Car je viens du monde PHP, et je sais qu'il est possible de voler ou "spoofer" des sessions.

C'est possible. De la à dire que c'est simple il y a un grand pas.
La sécurité est un domaine très large qui part du matériel pour aller au logiciel. Ca ne sert pas à grand chose de sécuriser au niveau de ton site, si les connexions sont en http et non en https (un exemple parmis tant d'autres).


Voici quelques liens expliquant la manière dont l'authentification est gérer en dotnet
http://support.microsoft.com/kb/910443
http://msdn.microsoft.com/en-us/library/ff647070.aspx
http://msdn.microsoft.com/en-us/libr...ionticket.aspx

[jgrmstr]

Merci pour le post sur les sessions, celui-ci a évaporé quelques-uns de mes doutes.

Au passage, les SqlMemberShipProvider m'intéressent quand même, mais pour des projets parallèles (d'ailleurs je ne trouve pas facilement de documentation en français sur le sujet, ou bien de projet de démo).

PS :
Pour le salage, je ne vois pas trop l'intérêt : si un intrus peut voir le contenu de ma BDD, il verra aussi le sel..?

[meziantou]

Pour le salage, je ne vois pas trop l'intérêt : si un intrus peut voir le contenu de ma BDD, il verra aussi le sel..?

Par exemple si tu recherches le hash md5 "dcf7fb88d38b9cbc0719c4d47af0b9ca" dans google tu verra que le mot de passe original est "TestPass". Cela est possible car il existe des rainbow tables qui contiennent en fait l'association mot de passe, hash. Si tu as le hash tu peux retrouver le mot de passe.
En ajoutant un sel tu rend ces tables inefficace. L'attaquant devra les recalculer pour chaque utilisateur, ce qui bien sur prend beaucoup de temps. De plus si tu utilises une fonction de hash qui prend un peu de temps, l'attaquant sera dans l'impossibilité de calculer les rainbow tables.
Pour info les MD5 sur un PC portable se bruteforce à plusieurs millions de hash par seconde. Je te laisse essayer par toi même http://3.14.by/en/md5.
Personnellement j'utilise l'algo SHA-512.