Chiffrement de mot de passe utile ?

(reprise du message précédent)

perfectionniste a écrit :
Dans le cas pk pas, utiliser une fonction personnalisé de hashage (avec des salts) par jours.
En fonction de la date d'enregistrement on sait qu'elle fonction utiliser pour récupérer le mdp

Je pense que tu n'as rien compris de la précédente remarque de Paolo.

Salut à tous,

En ce qui me concerne, j'ai toujours utilisé des mots de passe md5(); avec des chaines personnalisées. Par exemple : md5('dxv22'.$_POST['password'])

Je sais que ce n'est pas la méthode idéale et il est tant de la changer. Je profite du sujet - que j'ai lu entièrement - pour savoir quel type de fonction PHP utilisez-vous ? crypt() en 512 avec un long salt personnalisé ?

Merci d'avance

perfectionniste a écrit :
Disont que t'arrive à capter un mot de passe envoyer par un utilisateur lors de son inscription , que le mdp soit sallé ou qu'il soit haché qu'estce que ça change , tu a juste a entrer le mdp intersépté.

Quand on parlé de client => serveur, il s'agissait pas de PC Client => Serveur, mais de Serveur de Prod (Client) => Serveur de BDD distant (Serveur).

Bien évidement, tu ne peut pas hasher un mot de passe directement aprés la saisie de l'utilisateur, ou tu expose ta methode en JS , ce qui réléve de l'incompétence notoire. Le SSL est le seul bouclier dans ce cas.

tournikoti a écrit :
Je rappelle que le mot de passe dans la base de données est haché. Pour le comparer, il faut que le mot de passe que l'utilisateur tape, soit aussi haché. Comme il l'est sur son ordinateur, il faut ensuite l'acheminé via le réseau. La faille est bien le réseau !

Et comme le réseau est chiffrer, donc codage réversible, un hacker connaissant ce chiffrement et passant son temps à écouter le réseau peut cracker n'importe quoi !

Oui, en utilisant la fameuse fonction ssl_decode()

Soyons sérieux, un chiffrement SSL est réversible, oui, mais a condition de posséder les clés de sécurité du chiffrage... Ce que le Hacker ne peut trouver que sur ton serveur, et a priori, si il a accès au serveur, aucun intérêt de renifler le réseau...

Si ça se passait comme tu le dit, le web serai mort depuis longtemps.

@Gaylord: Malheureusement, changer de cryptage n'est pas une mince affaire. Choisir la fonction la plus sûre est le plus facile

Tu doit conserver ton cryptage d'origine en parallèle et quand un utilisateur parvient a s'authentifier avec l'ancien, recrypter son mot de passe avec le nouveau Hash. la tâche se complique encore aprés, car une fois que tu a commencer la procédure, tu doit tester d'abord si le 'authentification fonctionne avec l'ancien hash, et sinon avec les nouveau.

Bref, c'est la m***e
Modifié par JJK801 (21 Jun 2012 - 09:41)

a écrit :
Tu doit conserver ton cryptage d'origine en parallèle et quand un utilisateur parvient a s'authentifier avec l'ancien, recrypter son mot de passe avec le nouveau Hash.

Exactement, et c'est pas bien méchant à mettre en place.

@gaylord: quitte à changer, passe à bcrypt directement.

Oui évidemment, mais je n'ai pas encore beaucoup d'utilisateurs sur mon projet - je n'en ai pas encore fait la promotion -, donc pour la trentaine d'utilisateurs (et bien moins encore de réguliers) ... pas très grave, ils redéfiniront leur mot de passe.

Je vais voir comment faire pour Bcrypt, merci.

paolo a écrit :
Exactement, et c'est pas bien méchant à mettre en place.

Méchant, non, chiant et sale, oui

@ jb_gfx : oui je parle bien de SSL !

@ Paolo : je répondais à Perfectionniste pour dire qu'il est illusoire de croire que ton mot de passe est protégé en utilisant n'importe quel code de hashage.
Le problème n'est pas la façon dont tu vas le coder mais bien son accessibilité sur le réseau.

Sinon ta remarque suivante est tout à fait juste. Sauf qu'il n'est pas besoin de cracker un mot de passe pour l'utiliser.

@JJK801 : quand tu dis que "Le SSL est le seul bouclier dans ce cas", je ne vois pas pourquoi tu devrais te limiter à ce cas uniquement. Il l'est dans tous les cas ! Ne te focalise pas uniquement sur les mots de passe. Il n'y a pas que cela qui puisse être hacké sur le net.

Tu le dis toi même, le chiffrement SSL est réversible à la condition de posséder les clés. Mais tu estimes à combien de temps, la durée de vie de ces clés avant d'être cracker ? Donc si tu veux protéger tes données, en théorie, il faudrait changer les clés fréquemment.

tournikoti a écrit :
@JJK801 : quand tu dis que "Le SSL est le seul bouclier dans ce cas", je ne vois pas pourquoi tu devrais te limiter à ce cas uniquement. Il l'est dans tous les cas !

Bin perso, me m'amuserai pas a mettre du SSL partout...

tournikoti a écrit :
Ne te focalise pas uniquement sur les mots de passe. Il n'y a pas que cela qui puisse être hacké sur le net.

On est d'accord mais dans les 3/4 des hacks un mot de passe est en cause. De plus c'est le sujet qui nous intéresse ici.

tournikoti a écrit :
Tu le dis toi même, le chiffrement SSL est réversible à la condition de posséder les clés. Mais tu estimes à combien de temps, la durée de vie de ces clés avant d'être cracker ? Donc si tu veux protéger tes données, en théorie, il faudrait changer les clés fréquemment.

Si on est parano oui. Ceci dit vu la gueule d'une clé SSL et le fait qu'elle soit généré de manière aléatoire, je souhaite bon courrage au hackeur qui voudrai en cracker une a partir de données récupérés en transit

@tournikoti
C'est un non sens. Renseigne-toi sur le protocole ssl. Soit je ne comprends pas ce que tu essaies d'exprimer, soit tu te méprends sur l'ensemble du processus.

tournikoti a écrit :

Tu le dis toi même, le chiffrement SSL est réversible à la condition de posséder les clés. Mais tu estimes à combien de temps, la durée de vie de ces clés avant d'être cracker ? Donc si tu veux protéger tes données, en théorie, il faudrait changer les clés fréquemment.

Bruteforcer les algos utilisés pour chiffrer les données avec le protocole SSL (par exemple RSA avec une clé de 2048 bit ou plus), en utilisant une très grosse puissance de calcul, ça se chiffre facilement en centaines voir milliers d'années.

EDIT : DigiCert dit en milliard d'années, j'étais loin.

http://www.digicert.com/TimeTravel/math.htm
http://www.digicert.com/TimeTravel/math.htm
Modifié par jb_gfx (21 Jun 2012 - 18:59)

ça ressenble à quoi une clé ssl ?

Une clé SSL ça n'existe pas, c'est un certificat SSL ou une clé RSA. Une clé RSA c'est un big number.

Ça ressemble à ça (clé 2048 bit) :

Clé publique, utilisée pour chiffrer les données :

C6E130B3AC1EDB3BEFE8FBD326A4245095D8B8A68B21797ACA402B2C56A2F73CF52C0B7699BBD76B3F40FA228DAF4DE8DEC9D0E05588EE3CD4FAAE7115773DBFE74210CCE513CA85355D73F817638A1EFC8A6028FC400CB12067100AA2696B71E6938B52173BBC9DB88274DB36D8803579B0789C2435E6BD4D03CFFC0646CF6E74F35B491372437CB304A5A7E5F82BC5E7912A900CB3359C32BD2AE806FDD44F39A09B93BF6EC0E7C5DD5DCA0150F17FD333EBCF77635B9E7D9776766D011F593DE2E86CCFFBFE768AF73D4EC75508C88469301C8E5670263BC14777D2BD256B3ED43D95B1367A38504E5AEAA66CE022B08F9B01FDEC2EA74CB8A3AB0B7901E1

Clé privée (stockée sur le serveur), utilisée pour déchiffrer :

426BF3580EA43F94450C0B0EFA58D7C81243CF67D00FDE02A489C9E1850DE884F35D4276D9E16290EF0F447B45D6C6AE7FB9E789050836891A989EAA26012D1E6A9E25FE4883D39FA9B30C884F476F59E9FE4D1F6320011D273544A64897ECCA9DB7A9504172320C7B1316F41FDD2EF4AD2FC31862FF9D909BA82A4E81CA247CA7C5E230FF9BC75E873A2B1BDEFF6E1DED3DFDD264A42ABBB4366B1041B296ACD0F8CE0C8AE53618C308E9658E03622C3786122632667C6A976BD3A6985A4B06F9F7BD98E5663DAEA9BFC0984E0B944F691EB22D3AEA284D2CF13A9CD8C515E651AE231A3AB187BE9159C369BF58CE6F2AFAC0D9A1C4D273E11E75E06B5E2E01

Modifié par jb_gfx (21 Jun 2012 - 19:45)

merci pour les éxplications sur le fonctionnement d'ssl, sinon je comprend
pourquoi il faudrai des milliards d'années pour cracker cette clé

@ paolo : qu'est-ce qui est un non sens ?

@ jb_gfx : il ne faut tout de même pas exagéré ! Plusieurs milliers d'années ?

Voici quelques résultats concernant le RSA :
Le RSA-155 (Clé à 512 bits) a été cracké en aout 1999. Il a fallu sept mois et 300 processeurs.
Le RSA-200 (Clé à 663 bits) a été cracké en 2005.
Le RSA-232 (Clé à 768 bits) a été cracké en janvier 2010. Il a fallu 30 mois et 1500 processeurs.
Des chercheurs estiment qu'une clé de 1024 bits sera cracké avant 2020 !
Aujourd'hui on conseil vivement des clés à 2048 bits, mais jusqu'à quand ?

tournikoti a écrit :

@ jb_gfx : il ne faut tout de même pas exagéré ! Plusieurs milliers d'années ?

Aucune exagération, le temps nécessaire pour attaquer une clé RSA augmente exponentiellement avec la taille de la clé.

tournikoti a écrit :

Voici quelques résultats concernant le RSA :
Le RSA-155 (Clé à 512 bits) a été cracké en aout 1999. Il a fallu sept mois et 300 processeurs.
Le RSA-200 (Clé à 663 bits) a été cracké en 2005.
Le RSA-232 (Clé à 768 bits) a été cracké en janvier 2010. Il a fallu 30 mois et 1500 processeurs.
Des chercheurs estiment qu'une clé de 1024 bits sera cracké avant 2020 !

Attention, tu parles là de cas particuliers qui visent soit l'implémentation soit la clé elle même (mauvais choix des nombres, faille due à la symétrie de la clé, nombres trop proches) et pas l’algorithme RSA de manière générale. Notes quand même que dans tes exemples le temps/puissance de calcul est quand même exponentiel.

En plus on ne sait pas à quoi avaient accès les cryptographe qui ont cassé ces clés : la clé publique uniquement ? Ou bien toutes les valeurs : E, P, Q, N ? Bref sans plus d'infos, ces exemples ne veulent rien dire.

Toutes les clés de ces tailles ne sont cassables dans le même temps et dans les même condition. La plupart ne le sont pas. Du RSA 512 c'est déjà très sécurisé à l'heure actuelle.

tournikoti a écrit :
Aujourd'hui on conseil vivement des clés à 2048 bits, mais jusqu'à quand ?

Ça dépend pour quoi faire et qui le conseille.
Modifié par jb_gfx (22 Jun 2012 - 15:22)

Je suis d'accord sur le fait que le temps nécessaire est bien exponentielle.

Je crois qu'il s'agit de la factorisation de la clé public dans les trois cas. J'ai recueilli ces informations sur le net en tant qu'article de journalistes pour signaler la performance. Je n'en sais pas plus.

Si on veut se donner les moyens, on peut arriver à cracker n'importe quelle clé. Mais à part la performance, je ne vois pas trop l'intérêt, surtout si tu mets moins de trois ans pour y arriver.
Modifié par tournikoti (22 Jun 2012 - 01:49)

tournikoti a écrit :
Je suis d'accord sur le fait que le temps nécessaire est bien exponentielle.

Je crois qu'il s'agit de la factorisation de la clé public dans les trois cas. J'ai recueilli ces informations sur le net en tant qu'article de journalistes pour signaler la performance. Je n'en sais pas plus.

Tu pars de la clé publique (N) et de l'exposant (E), tu factorises la clé publique. Là tu récupères P et Q et tu peux t'en servir pour calculer la clé privée. Le but final étant d'avoir la clé privée pour pouvoir signer et/ou déchiffrer des messages.

tournikoti a écrit :

Si on veut se donner les moyens, on peut arriver à cracker n'importe quelle clé. Mais à part la performance, je ne vois pas trop l'intérêt, surtout si tu mets moins de trois ans pour y arriver.

Quand je lis ça je me dis que tu n'as rien mais alors absolument rien compris... comment se donner les moyens de casser une clé qui demande des centaines d'années pour être factorisée ? En devenant immortel ou en achetant une collection d'ordinateurs quantiques ?
Modifié par jb_gfx (22 Jun 2012 - 12:59)

Je crois que l'on ne se comprends pas très bien. Lorsque tu utilises le protocole http, celui-ci n'est pas protégé ! C'est ce protocole qui est utilisé pour les sites web. Dans ce cas, faire véhiculer un mot de passe crypter (le hash par exemple) ne permet pas de donner une sécurité maximal car n'importe qui écoutant le reseau à cet instant, peut récupérer ce mot de passe crypter et l'envoyer à son convenance. Je ne sais pas qui à dit, sur ce forum, qu'un enfant de six ans pouvait lire n'importe quelle informations transitant par method "get" ou "post". A moins de te contredire, tu ne fais que confirmer mes dires. Donc utiliser un cryptage ou pas ne sert à rien. Les propos de JJK801 confirme cette vision.

Ensuite le protocole SSL ou TSL est utilisé essentiellement dans l'acheminement du courrier et aujourd'hui, il y a encore des serveurs mail qui ne sont pas protégés. Par exemple : "smtp.sfr.fr". Bravo pour la sécurité ! Mais ca, c'est un autre débat.

Maintenant, si pour chaque site tu utilises le protocole https, il sera crypté et l'utilisateur sera identifié. Il utilise aussi le protocole SSL, mais il y en a d'autres que je ne connais pas. Dans ce cas là uniquement, je considère qu'il y a une sécurité correcte ! Mais ce protocole est fait pour transiter des flux financiers ou encore les informations concernant la carte bancaire mais pas pour un simple mot de passe.

Donc dans 99% des cas, un mot de passe qui transite sur le net ne possède pas toute la sécurité qu'il devrait avoir.

Maintenant, nous avons débordé sur le cryptage par le code RSA. Je crois que c'est toi jb_gfx qui n'a pas compris les enjeux de la sécurité. Aujourd'hui avec les moyens dont on dispose, ce qu'il y a dix ans paraissait impossible à cracker (exemple le RSA-155) dans un temps relativement court devient tout à fait réaliste. Et il ne faut pas des milliers d'années pour arriver à cela ! Sinon tu n'as jamais entendu parlé d'espionnage sur le net ? Et je ne parle pas d'un utilisateur lamda mais bien de société ou de pays qui ont d'autres moeyns que nous.

Donc non, il est recommendé de ne pas utiliser des cles inférieurs à 2048 car ils sont devenus obsolètes . Et il n'y a pas de "ça depend". C'est remarque montre que c'est toi qui n'a rien compris !
Modifié par tournikoti (22 Jun 2012 - 12:48)

Bon vu que t'y connait absolument rien mais que tu ramènes ta science en racontant n'importe quoi et en mélangeant des sujets qui n'ont rien à voir les uns avec les autres je crois qu'on va arrêter la pseudo discussion ici.

Bon si je suis dans l'erreur, qu'une âme charitable m'explique ce que je n'ai rien compris.

tournikoti a écrit :
Bon si je suis dans l'erreur, qu'une âme charitable m'explique ce que je n'ai rien compris.

Tous les participants de ce sujet ont essayé de le faire, hélas sans succès.