Discussion :

[july]

Bonjour à tous,

Après de nombreuses lectures (notamment sur ce forum), j'ai constaté plusieurs techniques de protection :

1) Lorsque l'utilisateur s'enregistre, on crée un grain de sel aléatoire. Le grain de sel est enregistré dans la bdd et il est propre à chaque utilisateur. Le mot de passe lui est hashé avec le grain de sel : sha1($pass.$graindesel). C'est cette chaine qui est stockée dans la BDD.
Lorsque l'utilisateur s'identifie, il saisit son mdp en 'clair'. Coté serveur on hashe et on fait la comparaison avec ce qu'il y a dans la BDD.

- Avantages : Si la base de données est volées, le pirate n'aura pas accès en clair aux mdp. Il ne pourra donc pas s'identifier. De plus, l'attaque brute force (avec ou sans dictionnaire) est rendu TRES difficile grâce au grain de sel.
- Inconvénient : Les mdp voyagent en clair entre le client et le serveur. Un sniffeur aurait facilement accès aux mdp.


2) Une autre méthode consiste à enregistrer les mdp en clair dans la BDD. Lorsque l'utilisateur s'identifie, le mdp est hashé coté client avec un javascript puis envoyé au serveur. Le serveur compare ce qu'il reçoit avec le hash du mdp qu'il a dans la BDD
- Avantage : Un pirate peut sniffer le mdp mais comme il est hashé il ne peut pas le connaitre.
- Inconvénients : Si la BDD est volée, les mdp sont en clair ! De plus si un sniffeur récupère les mdp en écoutant sur le réseau, je pense qu'il peut le réinjecter tel quel et accéder au site s'en s'identifier.


3) Enfin, j'ai vu une autre méthode. Lorsque l'utilisateur est enregistré, on stocke son mdp hashé. Un grain de sel est généré à chaque demande de login. Il est stocké dans une variable session et envoyé au client comme variable javascript. L'utilisateur s'identifie. Coté client, le javascript hashe le mdp avec le grain de sel : JS = sha(sha(mdp)+graindesel).
Coté serveur, on compare cette valeur avec la valeur dans la bdd (sha(mdp)) et le grain de sable en session :
if( JS == sha($mdpBDD.$_SESSION['graindesel']) ) return true;
Là, le grain de sel est supprimé.

- Avantages : Le mdp ne voyage pas en clair entre le client et le serveur.
Dans la BDD, on stocke le mdp hashé
- Inconvénients : Le mdp stocké dans la BDD est stocké sans grain de sel, juste hashé.
L'utilisateur peut désactiver JavaScript. Il faut donc prévoir la réception de deux types de données.



J'aimerai savoir ce que vous utilisez vous ? Quelle méthode vous semble la mieu ? Enfin si la dernière méthode ne vous semble pas fragile face à une attaque brute force puisque les mdp hashés sont hashés sans grain de sel ?

Merci beaucoup

[wamania]

pour moi le mieux est le dernier.
Le fait de ne pas avoir de GDS pour les mots de passe stockés dans la bdd peux être corrigé en définissant un GDS sur tout le site, pour tous les mots de passe
mais ça devient l'usine

Code :

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

1
2
3
     if( JS == sha(sha($mdpBDD).$_SESSION['graindesel']) )
avec JS = sha(sha(mdp.gds_universel)+graindesel)
et $mdpBDD = md5($mdp.$gds_universel)

perso, j'ai une autre approche
un GDS propre à l'utilisateur est généré à l'inscription, le mdp est stocké hashé avec ce gds.
Lorsque l'utilisateur veut se logguer, il saisit son loggin dans le champ, un script ajax va cherche son GDS propre.
Lorsque l'utilisateur rentre son mot de passe, au submit, on hash avec le GDS.
Si le gars a désactivé JS, on fait le hash avec GDS coté serveur

avantage : 1 gds par utilisateur, le mdp circule hash avec un gds, prend en compte la désactivation de js, le mot de passe est stocké hashé avec son GDS en base

inconvénients : recupération du GDS en ajax plutot contraignant

[july]

Bonjour,

Merci de ta réponse. Je trouve que ton idée est pas mal comme ca au moins le mdp est stocké avec son gds propre.

Par contre je ne connais pas du tout AJAX, c'est long à mettre en oeuvre ? C'est facile à prendre en main ? Comment cela foncitonne : c'est comme s'il y avait un onchange sur le champ login et qu'il allait chercher dans la BDD le gds? Ca s'exécute coté client ou serveur ?

Enfin, si on utilise pas ce procédé (AJAX) la meilleure solution est donc la 3eme méthode ?

Merci encore

[Sylvain71]

ça ne sert à rien de s'embeter a crypter le mot de passe coté client.

Si quelqu'un sniff le réseau, il n'a qu'à récuperer la chaine qu'il voit passer (cryptée ou non), et s'en servir pour se connecter au site.
D'accord, si le mot de passe est crypté, le hacker n'arrivera pas à avoir le mot de passe de la personne en clair. Mais il pourra quand même se faire passer pour elle sur le site.

La seule vraie solution pour sécuriser tout ça convenablement c'est de passer par du https.

Après il faut voir si tu as vraiment besoin d'un aussi gros niveau de sécurité.
Si c'est pour sécuriser un espace membre "classique" avec 2 ou 3 messages personnels à protéger, ce n'est peut être pas la peine.
Par contre si tu as des coordonnées bancaires ou truc du genre, là il faut sortir toute la panoplie !

[wamania]

La seule vraie solution pour sécuriser tout ça convenablement c'est de passer par du https.

oui, ça c'est sur, ça a été dit et répéter, mais sans https? on n'oublie la sécurité?

ça ne sert à rien de s'embeter a crypter le mot de passe coté client.
D'accord, si le mot de passe est crypté, le hacker n'arrivera pas à avoir le mot de passe de la personne en clair.

Après il faut voir si tu as vraiment besoin d'un aussi gros niveau de sécurité.
Si c'est pour sécuriser un espace membre "classique" avec 2 ou 3 messages personnels à protéger, ce n'est peut être pas la peine.
Par contre si tu as des coordonnées bancaires ou truc du genre, là il faut sortir toute la panoplie !

il a été determiné depuis longtemps que seul HTTPS sécurisait vraiment une connexion internet.
Cependant, ça n'empeche pas de réfléchir sur les autres solutions qui existent, et leurs viabilités.
ça permet de comprendre, d'apprendre et malgré tout, sans HTTPS, ça permet d'augmenter la sécurité, ce qui n'est jamais un mal;

[july]

Coucou,

Merci wamania, effectivement je sais que https reste vraiment la meilleure solution mais sans ça cela est-il possible de se protéger ?

La seule vraie solution pour sécuriser tout ça convenablement c'est de passer par du https.

Je me posais une autre question Quand tu dis :

ça ne sert à rien de s'embeter a crypter le mot de passe coté client.
Si quelqu'un sniff le réseau, il n'a qu'à récuperer la chaine qu'il voit passer (cryptée ou non), et s'en servir pour se connecter au site.

Si justement en utilisant un gds aléatoire généré à chaque demande de la page de login, quand le pirate réinjecte cette chaine il ne peut plus s'identifier puisque le gds n'est plus en session ! Je me trompe ? Est-ce que ca protège bien ?

Après il faut voir si tu as vraiment besoin d'un aussi gros niveau de sécurité.
Si c'est pour sécuriser un espace membre "classique" avec 2 ou 3 messages personnels à protéger, ce n'est peut être pas la peine.
Par contre si tu as des coordonnées bancaires ou truc du genre, là il faut sortir toute la panoplie !

Non effectivement, je fais un truc 'classique' qui ne nécessite pas des transactions bancaires mais j'aurai aimé tout de même présenter pas mal de sécurité. Cela me fait de plus un bon entrainement.

Merci à tous !

[Sylvain71]

oui, ça c'est sur, ça a été dit et répéter, mais sans https? on n'oublie la sécurité?

On ne peut pas vraiment parler de sécurié au moment des échanges puisque tout ce qui passe sur le réseau pourra etre intercepté et utilisé !
Crypté ou pas, si quelqu'un intercepte ton message il se connectera comme il veut au site ! Je ne dis pas d'oublier la sécurité, je dis juste que ces méthodes là ne servent à rien !

ça permet de comprendre, d'apprendre et malgré tout, sans HTTPS,

Ai je dis le contraire ?

ça permet d'augmenter la sécurité, ce qui n'est jamais un mal;

Juste une illusion ...

Si justement en utilisant un gds aléatoire généré à chaque demande de la page de login, quand le pirate réinjecte cette chaine il ne peut plus s'identifier puisque le gds n'est plus en session ! Je me trompe ? Est-ce que ca protège bien ?

Le gds est en session, mais le hacker pourra lui aussi récuperer l'identifiant de session vu qu'il est en train de sniffer le réseau et qu'il voit tout ce qui passe.