Mise en place d'une authentification - Comment.

Dans le message:O3XzBGXSFHA.2132@TK2MSFTNGP14.phx.gbl,
fabrice écrit :

Bonjour à tous.

Bonjour,

Sur l'identification Windows.

Je n'ai pas essayé.

L'identification par formulaire.

Cette voie est sympa aussi et semble pas trop complexe. Cepandant je
me pose plein de questions sur le stockages des comptes users et
password. La plupart des tutoriaux stockent les infos dans le Web.config.
Cela
me semble léger et comment faire si on a 'beaucoup' d'utilisateurs.
Quelle serait la meilleure façon de stocker ces informations et la
sécuriser ?
Une base de données acces par exemple ?
Peut on crypter le password et la vérification ?

Tout est là, avec de nombreux exemples de code. En particulier pour le
stockage sécurisé des comptes et mots de passe dans une base de données SQL
(MSDE par exemple).
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_netsecurity.asp

Utilisé avec succès pour une de mes applications.

Cela doit se trouver aussi en français(?) et en local dans la MSDN Library.
Pour ma part j'avais téléchargé le document PDF complet (sur la page ci
dessus)


--
Fred

> Bonjour à tous.

Bonjour à vous !

Je suis en train de mettre en place une authentification sur une application
Web.

Ok.

Je suis encore hésitant sur le choix, à savoir via Windows ou par
Formulaire.

Ok.

Sur l'identification Windows.
Est il intéressant et judicieux de mettre en place une identification
Windows.

Uniquement dans le cas où l'application en sera utilisée qu'au sein d'un intranet et si
vous pouvez vous affranchir de contraintes liées au navigateur : tout le monde devra
utiliser Internet Explorer si vous voulez être certain d'être à l'abri d'éventuelles
incompatibilités.

- Sachant que l'application Web serait sur une machine en DMZ, en autonome
donc avec une SAM locale. Ce qui veut dire que les comptes seraient
identifiés par cette SAM.

Sage décision si vous optez pour une authentification Windows.

Est ce possible et y t il des limitations, notamment dans la récupération
des informations de comptes pour les mettre dans une variable.

Aucune idée...

J'ai cru lire aussi que cela pouvait être difficile d'utilisation dans le
cadre d'une connexion Internet. Je ne sais si c'est vrai.

Oui. Difficile, voire dans certains cas, impossible sans la mise en place
d'une architecture bien plus complexe (terminaux)

- Les utilisateurs de l'application seront identifiés et limités. Moins de
5000 personnes. Il ne s'agit pas d'un Intranet.

Vous êtes donc sensiblement client pour une architectre avec authentification
par formulaire = )

L'identification par formulaire.

Cette voie est sympa aussi et semble pas trop complexe. Cepandant je me pose
plein de questions sur le stockages des comptes users et password.

Très bonne idée de se poser des questions sur ce point ; )

La plupart des tutoriaux stockent les infos dans le Web.config. Cela me
semble léger et comment faire si on a 'beaucoup' d'utilisateurs.

C'est la solution d'apprentissage. Elle est à éviter pour de nombreuses raisons
(stockage en clair, longueur du fichier si beaucoup de membres, ergonomie
pour la mise à jour les mots de passes, etc.)

Quelle serait la meilleure façon de stocker ces informations et la sécuriser
Une base de données acces par exemple ?

Une base de données serait un choix plus judicieux. Ne serait-ce que pour
des questions d'architecture et d'organisation générale de votre application.
Le fournisseur final (access, sql2000, mysql, oracle, etc.) importe peu en
ce qui concerne le choix d'une authentification.

Peut on crypter le password et la vérification ?

Le processus de vérification peut être protégé via une connexion sécurisée.
L'on utilisera par exemple une connexion HTTPS durant l'étape d'authentification
puis redirigera le client vers la zone HTTP lorsque l'authentification est
terminée.

En ce qui concerne le mot de passe : vous gagnez quelques mois d'expérience
professionnelle si vous vous mettez tout de suite à chiffrer tout mot de passe
se trouvant dans votre base de données ; )

Certains développeurs ont tendance à stocker le mot de passe dans la base
pour la simple raison que cette information leur semble nécessaire.

Pourtant, l'on ne cherche pas le mot de passe, on cherche à vérifier si l'utilisateur
connaît son mot de passe. D'où la petite nuance visant non pas à stocker le
mot de passe lui-même mais une information qui vous permettra de vous
assurer qu'il le connaisse ; )

Pour vous faire gagner du temps, il vous suffira d'utiliser une fonction de
hachage pour vérifier/stocker les mots de passes de vos utilisateurs. Ces
fonctions génèrent un texte court et garanti unique, c'est ce texte qu'il vous
faut sauvegarder et non le mot de passe. Ainsi si la base est volée, les mots
de passes ne seront toujours pas accessibles.

----------------exemple------------------------------------
//enregistrement
u.Login = tbLogin.Text.Trim();
u.Password System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(tbPassword.Text.Trim(), "sha1");
u.Save();

//authentification
string sql = " SELECT COUNT(*) AS total FROM users WHERE login = @login AND pass = @pass ";
string passHashed = System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(tbPassword.Text.Trim(), "sha1");

cmd.CommandText = sql;
AddParameter(cmd, "@login", tbLogin.Text.Trim());
AddParameter(cmd, "@password", passHashed);

if(GetResult(sql, cmd) == 1)
//ok
else
//pas ok
-----------------------------------------------------------------

Cela vous donne une idée du travail à effectuer. Bien entendu, il manque
toutes les règles annexes, telles que l'expiration de mot de passe, nb. de
tentatives maximum, options de réinitialisation de mot de passe, détection
d'attaques, etc. mais ceci viendra avec vos besoins plus précis.

merci de votre aide et d'avoir pris le temps de me lire.
fabrice

Bonne continuation,

AF

Merci beaucoup de toutes ces informations.
fabrice
"Messenger of the red snake mountain" <neNOwsaSPlaAMska@nxPLEASEtg.net> a
écrit dans le message de news: %23onZSQaSFHA.1236@TK2MSFTNGP14.phx.gbl...

Bonjour à tous.

Bonjour à vous !

Je suis en train de mettre en place une authentification sur une
application
Web.

Ok.

Je suis encore hésitant sur le choix, à savoir via Windows ou par
Formulaire.

Ok.

Sur l'identification Windows.
Est il intéressant et judicieux de mettre en place une identification
Windows.

Uniquement dans le cas où l'application en sera utilisée qu'au sein d'un
intranet et si
vous pouvez vous affranchir de contraintes liées au navigateur : tout le
monde devra
utiliser Internet Explorer si vous voulez être certain d'être à l'abri
d'éventuelles
incompatibilités.

- Sachant que l'application Web serait sur une machine en DMZ, en
autonome
donc avec une SAM locale. Ce qui veut dire que les comptes seraient
identifiés par cette SAM.

Sage décision si vous optez pour une authentification Windows.

Est ce possible et y t il des limitations, notamment dans la récupération
des informations de comptes pour les mettre dans une variable.

Aucune idée...

J'ai cru lire aussi que cela pouvait être difficile d'utilisation dans le
cadre d'une connexion Internet. Je ne sais si c'est vrai.

Oui. Difficile, voire dans certains cas, impossible sans la mise en place
d'une architecture bien plus complexe (terminaux)

- Les utilisateurs de l'application seront identifiés et limités. Moins
de
5000 personnes. Il ne s'agit pas d'un Intranet.

Vous êtes donc sensiblement client pour une architectre avec
authentification
par formulaire = )

L'identification par formulaire.

Cette voie est sympa aussi et semble pas trop complexe. Cepandant je me
pose
plein de questions sur le stockages des comptes users et password.

Très bonne idée de se poser des questions sur ce point ; )

La plupart des tutoriaux stockent les infos dans le Web.config. Cela me
semble léger et comment faire si on a 'beaucoup' d'utilisateurs.

C'est la solution d'apprentissage. Elle est à éviter pour de nombreuses
raisons
(stockage en clair, longueur du fichier si beaucoup de membres, ergonomie
pour la mise à jour les mots de passes, etc.)

Quelle serait la meilleure façon de stocker ces informations et la
sécuriser
Une base de données acces par exemple ?

Une base de données serait un choix plus judicieux. Ne serait-ce que pour
des questions d'architecture et d'organisation générale de votre
application.
Le fournisseur final (access, sql2000, mysql, oracle, etc.) importe peu en
ce qui concerne le choix d'une authentification.

Peut on crypter le password et la vérification ?

Le processus de vérification peut être protégé via une connexion
sécurisée.
L'on utilisera par exemple une connexion HTTPS durant l'étape
d'authentification
puis redirigera le client vers la zone HTTP lorsque l'authentification est
terminée.

En ce qui concerne le mot de passe : vous gagnez quelques mois
d'expérience
professionnelle si vous vous mettez tout de suite à chiffrer tout mot de
passe
se trouvant dans votre base de données ; )

Certains développeurs ont tendance à stocker le mot de passe dans la base
pour la simple raison que cette information leur semble nécessaire.

Pourtant, l'on ne cherche pas le mot de passe, on cherche à vérifier si
l'utilisateur
connaît son mot de passe. D'où la petite nuance visant non pas à stocker
le
mot de passe lui-même mais une information qui vous permettra de vous
assurer qu'il le connaisse ; )

Pour vous faire gagner du temps, il vous suffira d'utiliser une fonction
de
hachage pour vérifier/stocker les mots de passes de vos utilisateurs. Ces
fonctions génèrent un texte court et garanti unique, c'est ce texte qu'il
vous
faut sauvegarder et non le mot de passe. Ainsi si la base est volée, les
mots
de passes ne seront toujours pas accessibles.

----------------exemple------------------------------------
//enregistrement
u.Login = tbLogin.Text.Trim();
u.Password > System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(tbPassword.Text.Trim(),
"sha1");
u.Save();

//authentification
string sql = " SELECT COUNT(*) AS total FROM users WHERE login = @login
AND pass = @pass ";
string passHashed =
System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(tbPassword.Text.Trim(),
"sha1");

cmd.CommandText = sql;
AddParameter(cmd, "@login", tbLogin.Text.Trim());
AddParameter(cmd, "@password", passHashed);

if(GetResult(sql, cmd) == 1)
//ok
else
//pas ok
-----------------------------------------------------------------

Cela vous donne une idée du travail à effectuer. Bien entendu, il manque
toutes les règles annexes, telles que l'expiration de mot de passe, nb. de
tentatives maximum, options de réinitialisation de mot de passe, détection
d'attaques, etc. mais ceci viendra avec vos besoins plus précis.

merci de votre aide et d'avoir pris le temps de me lire.
fabrice

Bonne continuation,

AF