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.

[wamania]

puisqu'en en est la

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

juste une illusion aussi....

[Sylvain71]

Oui enfin là tu peux y aller quand même hein ...

Mais bon voila, moi je vous signale juste que crypter les mots de passe sur le client pour éviter les sniffer ça ne sert absolument à rien !

Si tu ne veux pas admettre ça je n'y peux rien.

Je suis d'accord que le problème est intéressant et que c'est bien d'en discuter pour comprendre comment tout ce grand bazar qu'est le web marche.
Mais il ne faut pas parler de sécurité en plus quand ce n'est pas le cas c'est tout !

[july]

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.

Oui mais la c'est plus le meme problème c'est du vol de session (voir mon topic http://www.developpez.net/forums/sho...d.php?t=155575).

Alors la question est bien si un sniffeur récupère la chaine contenant le mdp hashé avec un gds aléatoire stocké en session, est-ce qu'il lui sera bien impossible de s'identifier avec cette chaine ?

Après oui ce sniffeur récupère un id de session et peut volé la session mais c'est un autre piratage !

[Fladnag]

le protocole ssl est basé sur un echange de clé au debut de la communication (non cryptée).

Donc si sniffage de reseau il y a, les clés peuvent etre récupérée et toutes les communications suivantes récupérées, décryptées, modifiée, etc...

Donc wamania a raison : il n'y a aucun moyen de se proteger totalement d'un sniffage reseau... autant essayer de se proteger d'une corruption des DNS sur le poste client...

[Sylvain71]

Donc wamania a raison : il n'y a aucun moyen de se proteger totalement d'un sniffage reseau...

C'est un peu ce que j'essaye de faire comprendre depuis le début :/
Donc déjà si https ne permet pas de protéger à 100%, les solutions à base de crypt par javascript et tout ça côté client je crois qu'on peut tout de suite oublier !

[wamania]

Mais il ne faut pas parler de sécurité en plus quand ce n'est pas le cas c'est tout !

si tu estime que la sécurité c'est tout ou rien, alors considère que rien ne l'est.
Comme on vient de le dire, oublie HTTPS, ça ne l'est pas non, plus, oublie le téléphone, le paiement par CB dans les magasin (je parle pas en ligne), retire ton argent de ta banque, ne met pas de wi-fi

faut savoir que les cryptages sont basés sur le fait que la technologie actuelle ne permet pas un crackage dans un temps raisonnable, PAS QUE C'EST INCRACKABLE EN ABSOLU

[wamania]

on connais tous les limites de ces systèmes, on se fait pas d'illusion, mais je prefere tenter d'apporter un plus que de me dire, de toute façon, ça protège pas completement, autant rien faire.....

[Sylvain71]

faut savoir que les cryptages sont basés sur le fait que la technologie actuelle ne permet pas un crackage dans un temps raisonnable, PAS QUE C'EST INCRACKABLE EN ABSOLU

Oui mais là ce que tu n'as pas l'air de comprendre c'est qu'un hackeur qui cherche à se connecter à un espace sécurisé à la place d'une autre personne, ça ne lui prendre pas plus de temps avec ou sans ta méthode. Avec ou sans cryptage fait maison !
Pourquoi ? Parce qu'il n'aura rien à décrypter ! Il aura juste à prendre la chaine qu'il voit passer et à la balancer au serveur ! Tout comme il l'aurait fait avec une chaine non cryptée !

Je ne dis pas qu'il faut oublier la sécurité, je dis juste que là, ça ne sert à RIEN !

Exemple non crypté :
- Le client envoi son mdp "abcd"
- Le serveur attend une chaine non cryptée, il reçoit "abcd", le crypt et verifié, c'est bon ça passe

Avec hackeur :
- Le client envoi son mdp "abcd"
- Le hackeur intercepte et envoi "abcd"
- Le serveur attend une chaine non cryptée, il reçoit "abcd", le crypt et verifié, c'est bon ça passe

Exemple crypté :
- Le client envoi son mdp "abcd"
- Cryptage par javascript : "1234"
- Le serveur attend une chaine cryptée par leclient, il reçoit "1234", c'est bon ça passe.

Avec hackeur :
- Le client envoi son mdp "abcd"
- Cryptage par javascript : "1234"
- Le hackeur intercepte et envoi "1234"
- Le serveur attend une chaine par le client, il reçoit "abcd", c'est bon ça passe.


Elle a servi à quoi ta sécurité ?
La seule chose que tu as ajouté c'est des traitements inutiles en plus !
En plus ce genre de traitement ne peut apporter que des emm***** vu qu'ils sont faits par le client.

Donc à toi de voir ...

[july]

Désolé mais quelqu'un peut répondre à ma question ?

Sylvain71, dans ton exemple précédent tu n'évoques pas le gds temporaire !

Oui mais la c'est plus le meme problème c'est du vol de session (voir mon topic http://www.developpez.net/forums/sho...d.php?t=155575).

Alors la question est bien si un sniffeur récupère la chaine contenant le mdp hashé avec un gds aléatoire stocké en session, est-ce qu'il lui sera bien impossible de s'identifier avec cette chaine ?

Après oui ce sniffeur récupère un id de session et peut volé la session mais c'est un autre piratage !

[Sylvain71]

je prefere tenter d'apporter un plus que de me dire, de toute façon, ça protège pas completement, autant rien faire

C'est comme sauter dans le vide avec 10 parachutes ... si ton harnais est pas solide ça te servira à rien.

ça n'apporte pas de plus.
Le serveur au lieu de comparer clair == clair, il va comparer crypt == crypt
Tu auras beau te donner tout le mal du monde pour avoir une chaine d'accès cryptée dans tous les sens, si tu ne sias pas de qui vient cette chaine en arrivant sur le serveur ça ne sert à rien puisqu'il sera possible pour le hacker de l'obtenir.

Maintenant je vois que le débat n'avancera plus et qu'on restera tous campés sur nos positions donc autant qu'on s'arrête là si aucun de nous n'a de solution miracle.

[Sylvain71]

Désolé la question je pensais y avoir déjà répondu :

Alors la question est bien si un sniffeur récupère la chaine contenant le mdp hashé avec un gds aléatoire stocké en session, est-ce qu'il lui sera bien impossible de s'identifier avec cette chaine ?

Vu que le sniffeur voit tout passer, il verra aussi passer l'identifiant de session et pourra l'utiliser. Il puorra donc s'identifier avec cette chaine.

[july]

Vu que le sniffeur voit tout passer, il verra aussi passer l'identifiant de session et pourra l'utiliser. Il puorra donc s'identifier avec cette chaine.

Dis moi si je me trompe, mais au moment ou il va renvoyer la chaine le gds ne sera plus en session et donc ca ne marchera pas ?
Comment il peut faire pour s'identifier quand meme ?

[Fladnag]

@july > oui, le gds temporaire reste la "moins pire" des méthodes a mon sens.

Le systeme employé par spip est pas mal pour ca mais assez lourd au niveau identification puisqu'il demande 2 validations de l'utilisateur :

Un premier formulaire lui demande son login
=> PHP va chercher en base un gds personnel et temporaire

Un deuxieme formulaire lui demande son pass, qui est crypté par javascript avec le gds trouvé en base
=> PHP verifie le pass et change le gds (c'est un peu plus compliqué que ca, y a 2 gds en fait car on conserve le dernier utilisé, je sais plus pourquoi)

Du coup, si le hacker essaye de s'authentifier avec le meme couple crypté pass/gds il ne pourra pas car le gds aura changé a la validation en base. Et le mot de passe, crypté avec le gds ne circule jamais en clair.

Il ne peux que récuperer le gds et la chaine crypté et tenter de trouver le pass par attaque brute chez lui (puisqu'il a le code javascript de cryptage)

Ou d'attendre l'etablissement d'une session pour voler betement l'ID de session (puisqu'on suppose qu'il peut intercepter les communications)

Mais personnellement, je prefere qu'un pirate me pique mon ID de session (information totalement impersonnelle) que mon password (car j'ai plein de compte partout et que pour les comptes "pas tres important" j'ai tendance a utiliser le meme mot de passe partout, donc si on me le pique, on a acces a beaucoup de compte ailleurs)