Si la connexion n'est pas sécurisé en effet LOL se promenerait en clair, mais à ce niveau j'ai toujours utilisé SSL.
Version imprimable
Si la connexion n'est pas sécurisé en effet LOL se promenerait en clair, mais à ce niveau j'ai toujours utilisé SSL.
Tu confonds je crois. Le SSL se situe entre le navigateur et le serveur web. De ce côté là, de fait, c'est secure (jusqu'à preuve du contraire du moins...).
Entre le serveur web et le serveur MySQL, il n'y a pas de cryptage.
Oh je vois. Ce que tu veux dire c'est qu'entre PHP et MySQL mon "LOL" voyage en clair c'est ça ?
Si c'est le cas :oops: bonne remarque, mais par chance tous mes serveurs ont PHP et MySQL sur la même station !!!
En effet, cela dépend ou se situe l'attaque. Hasher côté BDD pose problème à cause de la liaison Serveur d'appli <-> Serveur de BDD. Hasher côté client pose le problème de la liaison Client <-> Serveur d'appli.Citation:
Envoyé par 10_GOTO_10
Il suffit donc de :
- Hasher côté client (edit : non c'est mal)
- Appliquer la protection préconisée par les experts
Edit :
En fait le hashage est rarement fait en local, il est plutôt fait soit côté serveur de BDD soit côté serveur d'appli. D'ailleurs, s'il était fait en local, ça voudrait dire que le pirate dispose sur le client du code qui hashe le mot de passe ! Bouh que c'est mal !Citation:
Envoyé par 10_GOTO_10
La protection Client <-> Serveur d'appli se réalise en général en SSL. Ensuite, du côté des serveurs, on hashe ou l'on veut ce qu'on veut. Pour que le pirate essaye de trouver le hash avec cette technique, ça veut dire qu'il a directement la main pour interroger l'appli serveur qui prend en entrée un mot de passé hashé et ressort la validation ou non du mot de passe. En général, si un pirate arrive à là, il arrive facilement à se procurer le mot de passe root de la bdd. En particulier dans le cas d'une appli php.
Evidemment, c'est tout de même un cas de figure à envisager, et la correction est à faire côté base de données. Ce qui est emmerdant car en général, une base ne sait pas si le champ stocké est un mot de passe ou pas ! C'est juste une chaîne de caractère. Changer la méthode de comparaison pourrait faire chuter les perfos du parcours d'autres tables qui ne nécessitent pas cette protection.
Bref, j'en reviens à mon affirmation première : si on crypte, on est pas emmerdé !
C'est quoi c'est protection préconisée ?Citation:
Envoyé par jblecanard
Celle citée en début de post, à savoir dé-corréler le temps de réponse et l'opération de comparaison de celui-ci.Citation:
Envoyé par CIFQ_Drew
au pire un petit:
et ca règle tout doute !Code:<?php usleep(rand(0,500)); ?>
Le problème revient au même: au lieu de lancer le mot de passe, tu lances le hash. On peut alors le considérer comme le mot de passe pour le site.Citation:
Envoyé par jblecanard
Alors effectivement le hacker ne pourra pas voir le mot de passe voyager en clair sur le réseau. Mais s'il veut juste entrer dans le système, il s'en fiche pas mal.
Oui oui j'ai dit une connerie, voir mon edit. Je campe sur ma première position :mrgreen: le hash n'est jamais fait en local sur le clientCitation:
Envoyé par Antoine_935
Alors, ma technique est-elle bonne ? 10_GOTO_10 et Antoine_935 ont semé le doute sur ma technique !!!
Si tu n'oublies pas d'ajouter une graine et que ta base de donnée n'est accessible que depuis le serveur d'appli, oui, à mon avis.Citation:
Envoyé par CIFQ_Drew
10_GOTO_10 a semé le doute en disant que le hashage était local au client :mrgreen: mais ce n'est pas le cas.
Heu, oui, j'ai semé le doute mais de bonne foi: c'est ce qui est généralement conseillé, voir ici, par exemple.Citation:
Envoyé par jblecanard
Mais en creusant un peu, c'est effectivement totalement inutile (voir ici):
Comme quoi en matière de sécurité il ne faut être sûr de rien.Citation:
Le principe consiste donc à crypter une partie seulement des informations échangées. En l'occurrence, le mot de passe. Mais attention à ne pas tomber dans le piège classique !
En effet, certains programmeur procèdent comme suit :
L'utilisateur entre son mot de passe, et soumet le formulaire. Le mot de passe est crypté en Javascript. Le champ de mot de passe est vidé et le mot de passe crypté est inséré dans un champ caché.
Enfin, le formulaire est soumis au serveur. Le serveur récupère le mot de passe crypté et le compare aux mots de passe cryptés dans la base.
Cela ne sert strictement à rien ! En effet, le pirate n'aura qu'à envoyer directement la chaîne cryptée ! A la limite, ça permet au pirate de ne pas utiliser le mot passe sur des sites différents et à l'administrateur de la base de donnée de ne pas voir les mots de passe en clair.
Ça complexifie l'attaque mais ça ne résout pas le problème.Citation:
Envoyé par laclac
J'imagine que pour lutter contre les "network jitter", et atteindre une précision de l'ordre de la nano, leurs algos se basent sur des statistiques. En augmentant (fortement ?) le nombre d'essais pour une entrée fixée tu dois à priori pouvoir retrouver les mêmes résultats.
Cela est effectivement possible mais il faudrait alors des milliers/millions de requêtes pour croiser temps de reponse + propabilité...Citation:
Ça complexifie l'attaque mais ça ne résout pas le problème.
J'imagine que pour lutter contre les "network jitter", et atteindre une précision de l'ordre de la nano, leurs algos se basent sur des statistiques. En augmentant (fortement ?) le nombre d'essais pour une entrée fixée tu dois à priori pouvoir retrouver les mêmes résultats.
D'autant que je ne crois pas que cette technique soit applicable pour le web. Il suffit que le serveur soit un peu en charge pour faussé les temps de reponses (ou le debit).
Autant dire que l'expert qui a pondu son analyse se fait bien voir, mais c'est complément inapplicable dans le domaine du web. Peut-être pour ça que personne s'y protège !
Oui, je ne comprends pas comment ce type d'attaque est réalisable sur un réseau qui peut avoir des temps de latence si différents...
Edit : un ami vient de me donner la réponse : pour un serveur web, il est possible de récupérer son stamp...
Qu'est ce que le stamp ?Citation:
Envoyé par Flaburgan
Sinon j'ai réfléchi un peu au problème hier soir et ça ne tient pas trop la route selon moi...
Déjà pour toutes les applications Web qui sont sur des serveurs mutualisés je ne vois pas comment on peut tenir compte du temps de réponse. Le temps de réponse du serveur dépend des autres applications qui tournent en même temps. Les bases de données sont aussi mutualisées en général dans ce cas là... ça fait quand même beaucoup d'aléatoire je trouve pour quelque chose qui doit être très précis... :(
Ensuite vient le problème du hachage. Et je suis tout à fait d'accord avec ce qui a été dit au niveau du hachage.
Imaginons qu'il rentre le mot de passe "toto", et que les hacker arrivent tant bien que mal à trouver que les deux premières lettres du hach sont les bonnes. Ils font quoi ensuite... ils essaient "touo" "totp" ? le hache va changer complétement... ça ne rime à rien...
Donc je dirais que leur attaque ne marche que sur un serveur dédié et sur des mots de passe non crypté. Et je dirais même que vu la latence du web et de toutes les données qui y transitent ça ne marcherait qu'en local.
PS : Crypter le hash en javascript pourrait servir à ne pas diffuser les mots de passe en clair sur le réseau au moment du login. Mais bon j'en ai jamais trop entendu parler au niveau de la sécurité et ce n'est pas ce qui est exploité ici. Dans ce cas là il faut mieux utiliser une connexion https je pense.
Salut
En fait, j'ai compris d'où vient la confusion :
10_GOTO_10 pense au cryptage en matière de sécurité de transmission du mot de passe. Je pense que la solution d'Elitwork d'ajouter un le captcha est inutile aussi : un pirate peut consulter et comprendre le code javascript utilisé. Mon avis : autant forcer SSL pour l'authentification, c'est beaucoup plus sûr.
Moi, je pensais au cryptage du mot de passe sur le plan du stockage dans la base de donnée. Pour moi, on ne doit plus stocker les mots de passes en clair, car si un pirate parvient à obtenir le contenu de la base, il obtient les mots de passes ! Mots de passes probablement utilisés sur d'autres applis par les mêmes utilisateurs. S'ils sont cryptés, ils sont inexploitables.
Inconvénient : on ne peut pas redonner son mot de passe à un utilisateur qui l'a perdu. Solution : lui en redonner un généré au hasard. Je déteste les sites qui me redonnent mon mot de passe en clair : ça veut dire qu'il est stocké en clair et c'est dangereux !
Pour crypter un mot de passe, il vaut mieux utiliser SHA-1 ou SHA-2 plutôt que MD5. Il faut également ne pas oublier d'ajouter une graine.
Par exemple :
est dangereux. En effet, si le pirate voit deux chaînes cryptées identiques, il pourra en déduire que les deux utilisateurs ont des mots de passes identiques !Code:mdpCrypte = sha2(mdp)
Il faut faire par exemple :
motcle étant un mot unique connu seulement des programmeurs de l'application. Ainsi, vous êtes certains que la chaîne cryptée sera unique pour chaque utilisateur, quand bien même d'autres auraient le même mot de passe et/ou le même login dans d'autres bases.Code:mdpCrypte = sha2(mdp + login + motcle)
Rapport avec le post : la comparaison du mot de passe étant un calcul SHA-2 et une comparaison entre deux chaînes cryptées, l'attaque suggérée n'est pas exploitable.
Pour la 425 000 000 ème fois, SHA-1 et MD5 ne sont pas des algorithmes de chiffrement (cryptage n'existe pas en français) mais de hachage, cela n'a vraiment rien à voir.
Attention à employer la bonne syntaxe quand vous parlez de ça, pensez aux centaines de gens qui lisent vos messages :evil:
C'est tout à fait exact, mais l'abus de langage n'est pas si choquant à partir du moment ou on ne peut pas retrouver le mot de passe original à partir du hash.Citation:
Envoyé par Marco46
Si, on peut retrouver le mot de passe original avec un dictionnaire.Citation:
Envoyé par jblecanard
Tu prends le mot "toto". Il sera toujours haché de la même manière. Alors qu'avec un algo de chiffrement c'est la clef qui détermine l'output donc du coup tu n'auras pas le même output en fonction de la clef.
-> rien à voir.