Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
On est quand même d'accord sur le fait que md5 et sha sont vulnérables à cause des tables de comparaison (combien d'utiilisateur n'utilise pas un mot de passe "simple" ?) qu'on trouve partout et de leur risque de collision ?Envoyé par X_Cli
Ce qu'il ne faut pas lire quand même... la cryptographie, ça ne s'improvise pas. Je recommande la lecture de "Applied Cryptography" et de "Secret and Lies" de Schneier pour éviter de raconter des bêtises à ce sujet
Non, ce qui est vuln, c'est d'utiliser des sels très courts, comme "b9" ou autre. Mais si on fournit un salt avec ne serait ce que 4 octets complètement aléatoires (2^32 valeurs), ca fait 4 milliards de rainbow table à générer pour avoir des "dicos" précalculés. Improbable.
Par ailleurs, il y a des rainbow aussi pour les autres algo...
Je parlais d'une utilisation sans grain de sel , comme on le trouve dans la majorité des cas , hélas.
Je ne serais pas aussi catégorique.
Si tu hache le pass avant l'envoi coté client AVEC un salt fourni par le serveur (unique par client, et unique par demande de connexion), comme le système d'authentification de SPIP, tu fait circuler sur le réseau un hash qui n'est valable que pour un utilisateur et surtout une seule utilisation.
@grunk: dans ce cas, ce ne sont pas les algos qui sont en tort mais leur mise en oeuvre.
@Fladnag: l'algo que tu décris est une authentification par challenge/response : ce n'est pas un salt mais un nonce qui est envoyé. En l'occurence, cela ne dit rien sur la façon dont est stocké le mot de passe dans la base : si le token est généré par le hachage du mot de passe avec le nonce, alors le mot de passe doit carrément être stocké en clair ou de manière réversible dans la base. Vu l'historique de sécurité de SPIP, ca m'inquièterait, mais ne m'étonnerait pas.
De plus, cette authentification est parfaitement inutile, et est juste l'expression déraisonnable de geeks du Javascript : au travers de Https, un tel mécanisme est parfaitement superflu, puisque la confidentialité est déjà assurée par TLS. Si cela transiste à travers HTTP, alors le JS qui effectue le traitement n'est pas garanti fiable : il peut avoir été altéré par un attaquant en position de faire un Man In The Middle (le même qui écoute le mot de passe en clair quand il transite ainsi), et par exemple exfiltrer le mot de passe avant son utilisation dans la génération du condensat.
En un mot: TLS.
En plus de mots : suivez la formation SANS Dev522 (Web Application Security Essentials), qui détaille tous ces problèmes très bien(ce n'est pas de la pub, il y a plusieurs centres de formation)
Rien n'oblige le pass a être codé de manière réversible. Tu peux très bien garder dans la base une version haché par du md5 qu'il est possible de recoder en JS afin d'obtenir le même hash que ce qu'il y a dans la base. Le jeton envoyé a l'utilisateur n'est pas généré uniquement a partir du pass, mais a partir d'un salt généré a partir de la milliseconde de demande de connexion et d'une combinaison qui d'autre champs (tu peux utiliser le password mais aussi le login par exemple, ou autre, genre le mail, l'age, etc...)
Aucun système de sécurité ne protège complètement d'une attaque Man In The Middle. Même quand tu fait de l'https, a moins de forcer l'utilisation de routes TCP/IP différentes lors de l'envoi d'information sur le réseau, ou d'échanger les certificats de manière réellement sécurisée (genre sur une clé USB dans le monde physique), le MITM interceptera l'échange initial avec les certificats et les clés publiques et sera donc en mesure de faire croire a A qu'il discute avec B, et a B qu'il discute avec A en introduisant son propre certificat et en décodant / recodant la requête. Même les autorités de certification se font pirater et il est possible de générer de "faux-vrais" certificats qui ne demandent pas de confirmation a l'utilisateur final... et même avec un certificat envoyé par le MITM non "officiel", la plupart des utilisateurs l'accepterons parce qu'ils n'auront aucun moyen de déterminer facilement que c'est un faux.
La solution de SPIP n'est évidemment pas parfaite, mais elle est un bon compromis relativement facile a mettre en place quand tu n'a pas besoin d'un niveau de sécurité digne d'une interface web de lancement de missile nucléaire ;o)
Après on peux aussi se demander l’intérêt de crypter des échanges quand on sait que la majorité des serveurs mails autorisent l'envoi des mots de passe mail en clair, mais c'est un autre débat...
Répondre avec citation
Partager