authentification - Page 1

Est ce que le système HMAC-MD5 est vraiment fiable, ie on peut pas du tout retrouver le secret?

sachant que dans mon système, le challenge vient directement de /dev/urandom, et que si l'authentification échoue, le challenge est regénéré (ce qui évite les essais multiples)

edit: HMAC selon RFC2104, ici ftp://ftp.rfc-editor.org/in-notes/rfc2105.txt

je ne connais pas le "HMAC" mais vu que le MD5 est un checksum "loosy" il est impossible de faire un reverse pour avoir la donnée "MD5-isé"

On dit pas LOSSY ?

si

parce que ça existe les checksums "inversables" ?

Justement... non. Donc "lossy" ou "avec perte".

Faute de frappe

nan. L'idée c'est que je file un nb aléatoire, je le concatène à un "secret" et je hashe le tout.

serveur ---> nb random ---> client
(le serveur calcule md5(random+sec1) )
(le client calcule md5(random+sec2) )
client ---> résultat ---> serveur

le serveur compare son résultat et celui reçu.
Si c'est pareil, ça veut dire que les secrets étaient les mêmes.
L'avantage c'est que les secrets se baladent pas sur le réseau.

Si le secret du serveur et du client sont les mêmes, les hash seront les mêmes, donc ça permet de vérifier que les deux partagent le même code secret, sans le transmettre. ca me parait correctement secure, mais y'a ptet des failles.

si les secrets sont "secrets" ça veut dire que le client est bien authentifié.

md5 est un peu cassé donc c'est pas bien, mais il y a d'autres fonctions de hashage alternatives (SHA1 toussa)

oué, je sais. Je devrais faire du SHA.

il commence à être bien cassé pour des messages supérieurs à quelle taille?

Parce que je fais pas un truc pour le DoD là, hein

"md5 est un peu casse" ouais, mais bon, faut pas exagerer non plus, qui va aller peter le systeme de squalyl avec du md5?
beh pas nous avec nos pauvres pc de merde hein...

squalyl (./8) :
nan. L'idée c'est que je file un nb aléatoire, je le concatène à un "secret" et je hashe le tout.

Ca s'appelle le "salt"
http://en.wikipedia.org/wiki/Salt_(cryptography)

En général on avance l'intérêt du sel pour contrer les rainbow tables et le brute force, mais je te laisse lire l'article wikipedia qui est très intéressant

nEUrOO (./11) :
"md5 est un peu casse" ouais, mais bon, faut pas exagerer non plus, qui va aller peter le systeme de squalyl avec du md5?
beh pas nous avec nos pauvres pc de merde hein...

Certes certes.
Mais l'idée c'est que, quand on commence à trouver des faiblesses, il se peut qu'on fasse de gros progrès prochainement, alors autant passer aux successeurs qui sont encore sûrs...

pour authentifier des commandes envoyées à un bot IRC, t'inquiete on m'attaquera pas

d'après http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator, il y a de bonnes techniques.

Mais dites donc, ça fait peur, en fait, /dev/random (cf liens externes à la fin de l'article)

Hippo: ouep... mais bon, s'il salt ses donnees alors c'est okay!

vieille étude sur une ancienne version, mais c'est vrai qu'on a toujours dit que /dev/[u]random était sécurisé, et à l'époque de cette étude, y'a eu pas mal de travaux qui ont montré que des progrès étaient à faire de ce côté là.

OK. Je m'en doute.

même au niveau du DoS en faisant dd if=/dev/random of=/dev/null ?

squalyl (./8) :
L'idée c'est que je file un nb aléatoire, je le concatène à un "secret" et je hashe le tout.

Ce n'est pas HMAC, ça.
Cette construction (juste hasher la concaténation) n'est pas satisfaisante au niveau sécurité pour plein de raisons.
Maintenant, en pratique, pour des applications peu « sensibles », ça peu faire l'affaire... (selon la façon dont tu l'utilises)

Si tu veux un truc vraiment sûr, il faut faire quelque chose du genre H(k|H(k|m)) - cf. HMAC.

je sais, t'inquiete pas, j'utilise le code de la RFC 2104 que j'ai donné dans le tout premier post

Je montrais juste l'idée.

squalyl (./19) :
t'inquiete pas

Ah, non, ça, y'a pas de soucis ; je ne m'en fais pas.

Je montrais juste l'idée.

OK

si je veux un truc de barbare y'a toujours http://www.random.org/ basé sur le bruit atmosphérique (y'avait des sources de bruits quantiques, aussi)

Quelle différence avec balader directement le md5(secret) par le réseau ? (vu que de toute façon, on part du principe qu'il n'y a pas besoin de faire un truc hyper sécurisé...)

Si tu veux quelque chose de vraiment sûr, il faut du SHA-256 au minimum. Le SHA1 a aussi été partiellement attaqué.

./22 : balancer le md5(secret) par le réseau ? Qu'entends-tu par là ?
Si tu veux dire par là que la fonction de cryptage est sur le poste client, ça veut dire grosso modo que le md5 devient le mot de passe, et donc (entre autres) il est en clair dans la base...

squalyl (./21) :
(y'avait des sources de bruits quantiques, aussi)

Oui. Moi, je connaissais : Quantum Random Bit Generator Service.
Mais ça reste du bon gros overkill pour ce que je veux faire...

lol c'est certain