Discussion :

[Swoög]

J'en profite tant que je peux pour poster

Je pense que limiter le nombre de demande d'envoie de pass par la poste et vérifier l'adresse postale (vérification du couple pseudo + adresse postale) pour chaque demande serait largement suffisant...

Il faut également se dire qu'un oublie de mot de passe est quand même sensé être exceptionnel, donc il ne devrait pas y avoir trop de demandes...

et puis au-delà d'une limite, on peut toujours mettre un envoie sous condition d'un système type allopass comme ça, ça permettra de réduire les "frais postaux" au stricte minimum....

[Sub0]

Oui, il me semble aussi plus sûr de demander au membre qui fait une demande de perte de mot de passe, une confirmation de son adresse postale. L'administrateur de l'espace membre devra alors comparer "manuellement" les adresses qui seront différentes si la comparaison des adresses au caractère près échoue...
Et enfin, donner la possibilité à l'admin de limiter le nombre de demande pour un certain nombre de jours...

Pas mal aussi l'idée de l'allopass Swoög pour que le membre participe aux frais postaux! (à prévoir en option)

[m@]

Bonjour !

moi, si quelqu'un me demande un allopass pour récupérer mon mot de passe, j'ouvre un autre compte ou je pars.

sinon, je pense qu'il faudrait la possibilité de tester un mot de passe avec crack et insister dans la doc sur la nécessité d'utiliser SSL dès que possible.

pour les sessions, ce serait pas mal de rajouter des appels à session_regenerate_id() pour lutter contre les vols de session.

enfin au niveau du cryptage client/serveur, comme j'en ai parlé avec Bob :
avec HTTPS -> il faut chiffrer sur le serveur
sans HTTPS -> le mieux est de chiffrer sur les deux :
->le chiffrage client permet qu'un sniffer ne puisse pas voir le mot de passe en clair
->toutefois, le vrai mot de passe devient le mot de passe chiffré puisque c'est lui qui est attendu sur le serveur. en fait, pour un ordinateur, le mot de passe est toujours en clair.
->du coup un piratage du serveur compromet tous les comptes, qui doivent être changés
->un hash sur me serveur permet de protéger les mots de passe d'un tel vol

cordialement

[Sub0]

Salut m@!

moi, si quelqu'un me demande un allopass pour récupérer mon mot de passe, j'ouvre un autre compte ou je pars.

Ok! J'ai réfléchis et en fait, si il sagit d'une inscription pour un hébergement payant par exemple, le prix de l'hébergement comprend les frais postaux pour l'envoi du courrier des identifiants... Donc on oublie l'allopass pour l'instant.

sinon, je pense qu'il faudrait la possibilité de tester un mot de passe avec crack...

Pour le moment, le programme possède une option pour choisir entre un mot de passe aléatoire ou laisser le membre définir son mdp. Je pense aussi que la dureté du mdp devrait être testée dans le cas d'un mdp choisi par le membre.

...la nécessité d'utiliser SSL dès que possible.

Tout à fait!

pour les sessions, ce serait pas mal de rajouter des appels à session_regenerate_id() pour lutter contre les vols de session.

Bien reçu! (prochaine version)

enfin au niveau du cryptage client/serveur,...

Nous avions déjà vu que le fait de crypter le mdp côté client ne sert à rien puisque le pirate récupère le mdp hashé et que le serveur attend le hash du mdp... Je préfère insister sur la nécessité d'utiliser SSL à ce niveau, plutôt que d'essayer de développer un "SSL maison"... Qu'en pensez-vous?

un hash sur le serveur permet de protéger les mots de passe d'un tel vol

Actuellement, les mdp sont hashés avec md5... Je voulais aussi ajouter l'option d'un cryptage RSA à la place, afin que l'admin puisse obtenir le mdp en clair si il le désire. Hélas, le script RSA que j'ai n'est pas très puissant...
Merci tout de même à Bob pour ses recherches!

[m@]

pareil je suis plus pour du SSL. chiffrer avec du RSA est en fait une très bonne idée. c'est lourd à mettre en place, mais ça permet de récupérer le mot de passe sans prendre de risque. reste le stockage de la clé privée (admin ?)

[Sub0]

reste le stockage de la clé privée (admin ?)

Oui, admin!
Voici le script dont je parlais: http://sub0.developpez.com/php/rsa.php.txt

[m@]

je ne l'ai pas regardé
que lui reproches-tu ?

[Sub0]

J'ai regarde la source aussi. Mais apparament, il genere des cles vraiment tres petites. La cle privee qu'il m'a genere etait 15000 (a peu pres). On est loin d'une cle de 512 bits (cad 10^154). Donc ca n'ira pas, a moins de reussir a modifier la source pour qu'elle genere des cle convenables.
Cela dit, il faut etre prudent en modifiant les source, parfois on denature l'algo et il est crackable...
J'essaierai de trouver un meilleure implementation.

Je suis convaincu qu'il a raison!

[Swoög]

Dites les gars, j'avais trouvé comment était effectué le cryptage RSA, ça devrait pas être trop dur à retrouver puis à créer un générateur de clé... bon, ensuite, faut voir niveau certificats... pasque avoir les clés, c'est bien, mais sans certif... en fait, il y a en vérité (selon mes souvenirs...) deux clés privées et deux clées publiques : les clées privées sont deux nombres premiers très grands, une des clées publiques est le produit des deux clées privé, et l'autre est définie avec je sais plus quelle relation mathématiques entre les trois clées précédente....

Ensuite, il y a un algo de cryptage//décryptage qui met chacune des clés en jeux... (cryptage : clées publiques; décryptage : clées privées)

ce qui est pratique avec ce système (toujours d'aprés mes souvenirs) c'est que on peux tout à fait inversé les clées et le cryptage fonctionne :
C'est la différence entre signature et cryptage (ça marche par exemple pour les mails) : Signature : on crypte avec ses clées privées et le décryptage est fait avec les clées publiques, donc on est sûr que c'est bien nous qui avons envoyé le message puis les clées de cryptage sont les clées privées.
Cryptage : on crypte avec les clées publiques du destinataire et comme ça, seule la personne qui possède les clées privées (donc le destinataire légitime) peut décrypter le message !)

Voilà, ensuite l'algo ne devrait pas être trop dur à trouver, ensuite, il faut trouver un moyen de généré des nombres premiers suffisaments grand (généralement du 512bits (~10^154 comme le précise Bob) suffisents, mais j'ai déjà entendu parler de clées de 2048bits) la taille spécifées étant celle de la "grande clée publique" (produit des deux clées privées)

Voilà, je vais tenter de retrouver cet algo puis de retrouver un autre algo qui permettait de "créer" des grands nombres premiers...)

Je vais chercher ça... je vous tiendrez au courant si besoin est...

pour ce qui est du Allopass, je pensait ne l'utiliser qu'au-delà d'un certain nombre de demande... (par exemple : 3/mois et par compte , 3 pertes de mot de passes en un mois étant quand même considérable à mon avis ou une autre limite du même genre....)
Bien sûr, faire passer les frais postaux dans le prix même du compte est bien plus pratique !

[m@]

les certificats ne sont pas nécessaire pour le chiffrement, juste pour l'authentification des interlocuteurs.

[Swoög]

les certificats ne sont pas nécessaire pour le chiffrement, juste pour l'authentification des interlocuteurs.

Faux !

Ce sont les clées qui sont nécessaires pour l'authentification des interlocuteurs dans le cas du cryptage !

Dans le cas des certificats d'identification, la clée (il n'y en a généralement qu'une) correspond à une entrée dans la BDD de l'éméteur et permet donc de vérifier la correspondance entre l'identité donnée par le possesseur du certificat au client et celle données à l'émetteur du certificat (le nom du demandeur du certif étant généralement directement porté sur le certif).

Des vérifications étant normalement effectuées au niveau de l'indentité du demandeur pour une demande de certificat d'indentification, on peut assimiler cela à une identification sécurisé et sûre du possesseur du certificat ! mais en fait ce n'est que l'organisme émetteur qui se porte garant de l'identité du porteur du certif s'il y a correspondances entre les infos...

Donc les certificats ne sont que des conteneurs de clées plus convivial !!

[Swoög]

Comme promi, j'ai cherché des renseignements sur le RSA : http://sebsauvage.net/comprendre/encryptage/crypto_rsa.html

Voilà qui donne toutes les infos nécessaires...

[m@]

pourquoi est-ce faux ? tu dis la même chose que moi.

+ un chiffrement en RSA ne nécessite pas de certificat
+ un certificat permet d'associer le possesseur d'une clé à une identité réelle. l'autorité délivrant le certificat étant elle-même certifiée, et ainsi de suite, jusqu'à ce qu'on arrive à qqn que l'on sait digne de confiance

[Swoög]

au lieu d'un certificat d'indentification (pour un site par exemple) il est tout à fait possible de mettre en haut de page un lien vers la base de données de l'organisme auprès de qui on est enregistré avec le numéro d'enregistrement...

on pourrait vérifier de la même façon que le nom présenté et le nom enregistré correspondent, les certificats sont bien plus pratique, mais pas nécessaire ! (pardon si je n'ai pas été clair...)

[Swoög]

Bon, fini le troll tout ça a été réglé par MP, donc maintenant qu'on est d'accord, est-ce qu'on utilise le RSA ??

Si Oui, je peux essayé de faire passer en php les formules mathématiques de traduction présentées sur la page Web citée ci-avant... (j'ai remarqué que Sub0 l'avais lu, tu en penses quoi ? )

Je pourrai aussi essayer de vous faire un générateur de clées à partir d'un mot de passe, comme ça, on pourra toujours retrouver les clées à partir du passe (pas besoin d'avoir les clées stockées...) et puis je pourrais également m'arranger pour gérer le cryptage//Décryptage de manière à ce que la fonction prenne le pass en paramètre (plus de clées, simplement un pass : c'est plus simple à retenir, non ???)

Woilà, vous en pensez quoi ???

[m@]

moi je suis pour

[Sub0]

je peux essayé de faire passer en php les formules mathématiques de traduction présentées sur la page Web citée ci-avant...

Si vous vous sentez capable de réaliser une lib de cryptage RSA digne de ce nom, oui, c'est une très bonne idée, d'autant plus qu'elle pourra servir pour d'autres projets. Mais je croyais qu'il existait déjà ce genre de code sur le net. Bob en a trouvé du bon je crois (du code ). Cela me paraît être beaucoups de travail pour programmer cela, mais il est clair que c'est vraiment intérressant! Qu'en pense les autres membres?

je pourrai aussi essayer de vous faire un générateur de clées à partir d'un mot de passe, comme ça, on pourra toujours retrouver les clées à partir du passe (pas besoin d'avoir les clées stockées...) et puis je pourrais également m'arranger pour gérer le cryptage//Décryptage de manière à ce que la fonction prenne le pass en paramètre (plus de clées, simplement un pass : c'est plus simple à retenir, non ???)

EXCELENT!!! :o

J'ai trouvé ce script, je ne sais pas ce qu'il vaut, mais il encrypte avec un seul mdp...
http://sub0.developpez.com/php/clsencrypt.zip

Que se passe-t-il si c'est le mdp que l'on veut encrypter justement?

[Swoög]

Pour ce qui est du cryptage//décryptage en lui-même, ça ne doit pas être si compliqué que ça : il suffit d'avoir le format du flux à crypter... ensuite, c'est l'adaptation de formules mathématiques (exponentielle et modulo) (+ si nécessaire de quoi manipuler les grands nombre pour éviter un dépassement de mémoire...) donc php fournit les outils ensuite, il faut savoir sous quel format est encypter le message (par paquet de byte ? par byte ?, quel encodage standard est utiliser au départ ? etc...) une fois qu'on a ces infos, on découpe le paquet qui représente le message (quitte à le demander sous une forme particulière par exemple : byte[] ) et on crypte tout ça avec le jolie petite formule ! bis pour le décryptage

ensuite, je pense que le plus dur devrait être le générateur de clés : la force du RSA provient en grande partie du fait que ce soit de très grand nombres premiers qui sont utiliser dans le code, et générer des nombres premiers est tout sauf simple... ils ont toujours étaient très embêtant à générer !

Dites-moi si je me trompe, mais j'ai vraiment l'impression que le génrateur de clée sera le plus compliqué à faire (ça doit exister, mais il faudra rajouter un grain de sable "au cas où" (impossible de retrouver les clées même avec le pass) ça sécurise encore plus les clées, le tout est qu'elles soient valides et constantes !! (un mdp => un couple de clées)
ensuite, les clées privées n'auront même pas besoin d'être stockées, seul le pass sera important : à chaque cryptage ou décryptage : génération des clées et cryptage via l'algo RSA...

Je pensais partir sur le code ascii d'un hash md5 du mot de passe (ou un autre type de hash qui donnerait un id composé uniquement de nombres, je pense que ensuite, en composant cette base avec un grain de sable, on doit pouvoir généré des nombres premiers, à peu près égaux (à 10^2 près autour de la dureté des clées que l'on souhaite...
p.e. : on veut une clées de 512byte soit ~10^154 ("clée longue") donc les deux nombres premiers servant de clée doivent être ~10^77 donc il faudrait qu'ils soient dans l'intervale ]10^76;10^78[ ainsi la taille de la clée longue est dans l'intervale ]10^152;10^156[ ce qui reste correct à mon avis, ensuite, on peut toujours resserer cet intervale...

mais le plus dur à mon avis est (je le répète) la génération des nombres premiers, je pense que (quand j'en serais là...) je vais aller poster dans le forum algo pour pouvoir faire ce générateur...

si vous pouviez me dire ce que vous en pensez (notamment Bob, puisqu'il semble avoir des connaissances en cryptologie : est-ce que mon raisonnement tiens la route ??)

[Pose dans la rédaction du POST : je regarde l'algo de cryptage que tu as posté]

Bien, je viens de regarder en vitesse la classe de cryptage, il faudra que je m'y pense un peu plus....

à vue de nez, ce n'est pas du RSA (crypt trop compliqué.... )

et il semble que la correspondance soit plutôt restrictive (encodage sur un string en pseudo-ascii : pas de possibilité d'encoder fichier &/ou autre infos, mais bon, normalement, ça peut toujours s'arranger...)

il utilise en fait plein de petits grain de sables personnalisables (à vue de pif : la clé, les deux scrambles (tables de correspondance entre crpyté et décrypté), les deux variables adj & mod) ensuite, il utilise également une clée différente pour chaque message (la clée dépend de la taille du message...)

l'algo a été créé soit par plusieurs personne et n'a pas été optimisé après coup soit par une personne qui n'a pas une excellente vue mathématique... (utilisation un coup de l'opérateur modulo '%', un coup d'une astuce qui retranche au dividende le diviseur jusqu'à obtenir le reste, alors que même sans utiliser le modulo, il y a une technique plus simple.... ) ==> Je ne veux pas dénigrer ni critiquer les personnes qui ont mis cet algo sur pied, c'est juste que le code aurait gagné à être lu à tête reposée et à être optimisé, car aucune optimisation de code n'a été faite, même les lignes de debuggage sont encore présentes !!! (mais commentées) le niveau d'optimisation des lignes de débugages (ce sont des echo donc c'est facile à juger) est différent dans une même fonction !

Voilà, après ces petits commentaires, voici mon humble avis (il devra être corrobé par Bob avant d'obtenir une valeur véritable) :

Ce script peut peut-être être solide ssi il est utilisé "en local" (cryptage et décryptage toujours efféctué au même endroit) et ce à cause de la grande quantité de grains de sables inscrits en dur (scrambles + adj & mod)...

Ensuite, je ne pense pas que pour l'échange d'infos il soit sûr : c'est un algo symétrique : l'échange des clées (& grains de sable) est indispensable à l'utilisation de l'algo : il y a donc un risque si les clées sont intercéptées durant l'échange !

Je ne pense donc pas qu'il soit bon à utiliser dans le cas d'échange d'infos... pour ce qui est du stockage sous cryptage, pourquoi pas...

Woilà, je ne sais pas si ce point de vue à une réelle valeur au niveau cryptologique... il faudrait que quelqu'un (Bob ou un autre) qui posséde de vraies connaissance dans ce domaine regarde l'algorithme et dise ce qu'il en pense...

[PS] pour ce qui est du cryptage du pass, je ne vois pas très bien ce que tu veus dire...[/PS]

[Sub0]

Salut!

Je suis d'accord! Je pense aussi qu'il vaut mieux oublier ce script et rechercher un code RSA qui tient la route!

pour ce qui est du cryptage du pass, je ne vois pas très bien ce que tu veus dire...

Le mot de passe peut-être facilement hashé avec md5 ou sha1 pour le protéger dans la bdd. Seulement, je souhaiterais qu'on puisse aussi le crypter en RSA au lieu de le hashé, afin que l'admin puisse récupérer en clair les mdp...
Mais tu as dis:

(plus de clées, simplement un pass : c'est plus simple à retenir, non ???)

Est-ce possible de crypter les données avec un mdp crypté et non hashé si ce mdp sert de clé à lui-même?
Je n'arrive pas bien à visualiser si c'est réalisable ou pas... Je pense que oui, mais j'aimerai avoir une confirmation... Si cela ne pose pas de problème, nous pourrions utiliser le mdp d'identification du membre pour le chiffrement des données (double-emploi). Ou alors, je suppose que le mdp devra avoir une clé différente... (je ne sais pas).

J'ai pratiquement terminé la classe d'envoi de mail au format html avec l'intégration des images et pièces jointes (pour la v2). Je vais maintenant pouvoir me concentrer avec vous sur la fonction de cryptage. Je pense déjà essayer de trouver un script RSA sur le net. Sinon, nous pourrions envisager d'améliorer celui-ci, non? Ou l'utiliser comme modèle... Autre solution peut-être, le PGP?

[Swoög]

en fait il y a deux type de pass : le pass admin ou appli qui sert à générer les clées, et le pass client qui est à crypter, on peut tout à fait crypter le pass client à partir du pass admin, c'est le pass admin qui servira de clée, ensuite, on peut toujours crypter les infos du client en se servant de son pass comme clée (et lui fournir ainsi une paire de clées RSA, mais qui aurait l'inconvénient de changer avec son pass : pas évident pour une utilisation prolongée... on pourrai peut-être alors se rabattre sur un id d'account ou qqchose du style...) puis crypter son pass à l'aide notre clée (ou utiliser son pass crypter avec le notre comme clée de cryptage etc.... on peut immaginer plein de combinaisons !) mais je ne sais si c'est réellement utile... il faudrait sans cess décrypter ou crypter tout ce qui passe, bon, ça peut-être transparent... mais je pense pas que ce soit réellement utile, à la limite, ça peut être ajouté pour une sécurité à très très haute échelle, mais ça m'étonnerai que quelqu'un qui n'ai pas les moyens de développer ou de faire développer cela en ait besoin un jour ....

je me pencherai sur cet classe RSA que tu viens de donner, j'ai compris pourquoi les clées étaient minuscules : le plus grand nbre premier stocké est 9533 ... et pour info 9533² = 90878089 ... donc niveau grandeur de clée, c'est pas génial, mais il semblerait qu'il ne doive y avoir que cela qui gêne dans l'utilisation de cette classe... (mais je n'ai pas vraiment regardé...) le flux encodé est ici aussi un string... plus ça va, plus je pense vraiment qu'utilise un stream sous forme de byte[] qui représenterai l'ascii du string ou le contenu d'un fichier serait le plus polyvalent...(et le plus simple à mettre en pratique !) (à vue de gros (très gros pif) ça semble bien être du RSA, j'ai reconnu le fil général de l'algo...)

enfin, pour le moment, je furete sur les forums, donc pas trop le temps de me pencher sur cette classe pour le moment, je verrai pendant les heures creuses....