Bonjour
 
J'ai un site de paiement en ligne, quand je valide ma commande et que j'arrive sur la page où l'on rentre le numero de CB j'ai un probleme.
 
Si le montant de ma commande vaut 100 euros, la page SSL me dit que la valeur veut 1 euros et ainsi de suite (200=2, 400=4, 222=2,22).
J'ai mis un type int et je me demande comment je peux me retrouver avec un float.
 
Quelqu'un a t'il déjà rencontré ce problème ?

Je precise que je passe le montant de ma commande en url du type
 
"montant=777"

Ben ... ton script doit certainement diviser cette somme par 100 quelquepart ... forcément ...
 
Vérifie bien le script.
 
Edit : Euh ... je sais pas, mais pour moi ça me semble assez abérant de passer le motant par l'url non ?

Quand je regarde la forme d'url que veut le prestataire qui s'occupe du paiement et bien il y a le montant dans l'url.

Tout dans l'URL Tu commandes pour 1000 euros de matos pis tu trafiques l'URL en mettant 10 euros et hop, 990 euros de réduc
J'veux l'adresse, vite !@#

c'est pas un site ou on achete des choses c'est un concept particulier

C'est sûr que c'est particulier, comme concept Jusque dans la réalisation
Sérieux, c'est pas du tout sécurisé, comme méthode, fais ça autrement

C'est pas du tout aberrant, ça marche souvent comme ça.
 
Mais il y a un "secret" connu uniquement du système de paiement et au marchand et propre à chaque marchand qui permet de faire passer avec les paramètres un checksum de vérification.
 
Donc pas d'inquiétudes quant à la sécurité.
 
Il n'a pas dit qu'il passait juste le prix

Certains systèmes de paiement demande en fait le prix en centimes. Donc pour 1 euro faut envoyer 100 comme valeur du prix.
 
Ca doit être indiqué dans la doc de l'API du module de paiement que tu appelles (c'est quelle banque ?).

Un checksum, comment c'est trop secure
Non mais sérieux, faut arrêter Si tous les prix sont dans une base, il suffit de faire passer le panier et de calculer le montant total dans le script côté serveur, hein Sa mange pas plus de pain.
Après, si les prix sont en dur dans le code HTML, effectivement...

En fait la boite ou je suis ils font du conseil par telephone. Et le site que j'ai fait, le conseiller rentre le montant de la consultation téléphonique puis il arrive à la page de paiement et il saisi le numero de carte bleu du client.
 
Que pensez vous cette idée ??
 
Moi personellement je suis en stage donc je leur fait ce qu'il demander et pi quoiqu'il arrive je suis payé pareil

 
C'est kadishop mais comme y'a tres peu de documentation je vais leur envoyer un mail

Oui mais quand même il doit bien y avoir moyen de récuperer lem ontant sans le passer par l'URL ... je me doute bien qu'il y ai un système derrière, mais quand même ... ça fait super crade je trouve ...
 
Enfin bref, quoiqu'il en soit, pour passer de 400 à 4 c'est qu'il y a forcement une kooye dans le script, le tout est de trouver où.
 
Regardes bien partout où est traitée ta variable, décode ton script pas à pas, tu devrais bien finir par trouver ...
 
On peut l'avoir d'ailleurs le code source de la page s'il n'est pas trop gros ?
 
Merci.
 
EDIT : Vache ... le temps d'ecrire un message, il y en a 200 qui s'intercalent ...

Fais pas cette tete j'essaye de faire mon travail au mieux.

Par curiosité, tu reproches quoi au checksum ?

Que si on parle bien de la même chose, alors n'importe qui est capable de passer le checksum de 10 au lieu de 1000 dans l'URL
Et par curiosité, tu reproches quoi à la méthode de ne passer que le panier et de calculer le prix dans le script ?

c'est la guerre des reproches par ici. J'ai résolu mon probleme. En fait j'ai rajouté un champ centimes.
Comme ça j'envoies les euros et les centimes et j'ai plus de probleme.

Je parle de ceci :
 
Un internaute va sur un site marchand, il fait son shopping. Il finit par aller sur la page de confirmation de commande qui le redirige vers un module de paiement bancaire.
 
C'est de cette redirection dont je parle
Dans l'url tu as un truc dans le genre par exemple (j'ai simplifié à l'extrême les paramètres) :
url_banque?prix=15&transaction_id=878975&checksum=511e33b4b0fe4bf75aa3bbac63311e5a
 
Le processus de génération d'un checksum valide n'est réalisable que par le marchand et la banque. Par exemple : md5(informations + secret). Sans connaître le secret tu peux pas changer changer le prix dans l'url et mettre le checksum associé.

Et fallait mettre le montant en centimes d'euros dans l'url m'a répondu monsieur kadishop. Je pouvais la chercher longtemps la division par 100

 
et les keygens pour pirater les jeux je suppose que ca existe pas non plus ?
 
j'y connais pas grand chose en securité, mais il me semble qu'une regle de bon sens est tout simplement d'en cacher le plus possible. Les trucs qui se baladent en clair, bof.

Je t'avais donné la solution
T'as pas du la voir

Salut
 
Justement c'est le contraire
Ca sert à rien de cacher
Avec la méthode du secret partagé que j'ai exposée, tu peux passer tous les paramètres que tu veux tu n'auras jamais aucun problème, du moment que les différentes entités qui dialoguent vérifient le checksum à chaque fois.

C'est parfaitement crackable, ne serait-ce que parce que MD5 est un algo de hashage, ce qui signifie qu'il est possible de trouver le bon "secret" correspondant à l'info que tu veux passer pour obtenir un MD5 voulu. Il existe d'ailleurs des softs pas très légaux qui font ça...
Ce que je veux dire, surtout, c'est pourquoi ouvrir un trou de sécu alors qu'une méthode toute con comme faire une requête en base de données s'avère bien moins risquée ?

je doute
 

Si je ne sais pas ou t'habite, je ne peux pas venir tout casser chez toi
 
 

 
si j'ai bien tout suivi, ton truc n'est valable que tant que la methode de checksum reste inconnue, apres, bonjour les degats (et j'aime pas les "il faut que" et "il suffit que", generalement ca se barre tot ou tard en coyons). Ce qui fait que ton algo de checksum doit
 
->avoir peu de collision (deja ca c'est tout un boulot)
->etre inconnu du vaste monde  
 
ca me fait un peu peur

Bon courage si tu veux faire du brute-force sur un hash en sha1 par exemple
 
La chaine dont tu fais le hash fait plusieurs dizaines de caractères c'est impossible à brute-forcer dans un temps "humainement acceptable".

Si je te dis que ma méthode de hash c'est md5 ou sha1, tu vas faire quoi ?

Je suis d'accord mais ça répond pas, pour la deuxième fois, à ma question qui est : pourquoi utiliser cette méthode soi-disant incrackable alors qu'une bête requête en base serait déjà bien moins dangereuse ?
Et puis les trucs qui peuvent pas être crackés en mars 2005 seront-ils toujours aussi fiables en octobre 2007 ? Enfin quoi, combien de fois faudra-t-il que les gens tombent dans le panneau "mon système est incrackable, donc je m'en fous" avant de commencer à envisager d'autres possibilités d'implémentation ?

Imaginons que la chaine dont je fais le hash fasse 20 caractères alpha-numérique (soit 36 caractères). L'espace de recherche est donc 36^20 soit 13 367 494 538 843 734 067 838 845 976 576 combinaisons à tester.
 
Supposons que tu arrives à calculer 10^12 hash par seconde.
 
Il te faut 423 880 471 171 années pour tout calculer
 
C'est plus que l'âge de l'univers

Le système de paiement est toujours décorrellé du système du marchand. La banque est juste là pour dire "Merci de regler le montant de X euros pour le compte du marchand Y". La banque renvoie l'info du résultat du paiement au marchand sur une url définie (avec le même principe de checksum).

Oui ... sauf que si en 2012 ils découvrent qu'on peut faire des PC qui décodent 36^20 combinaisons en 1 semaine ?
 
Il faudrait peut etre penser à voir sur le moyen/long terme non ?
 
Chez moi j'ai un systeme d'alarme, c'est pas pour ça que je donne mon adresse à tout le monde ...

Te dire que MD5 a déjà implosé et que la communauté crypto attend actuellement le papier d'une équipe chinoise qui affirme avoir cassé le SHA-1
(je ne parle pas de brute force ici, mais bien d'algos de hash cassés)
 
Actuellement, il est recommandé d'abandonner au plus vite MD5 et SHA-1 et de passer à SHA-256 ou SHA-512

Tu réalises vraiment pas (c'est pas une critique juste un constat) combien ça fait 36^20

J'pige pas ta réponse en rapport avec ma question de base : pourquoi la requête SQL c'est mal ?

 
sachant qu'y a deja des algos de collision pour le md5 et que recemment qqun a trouver comment diminuer le nombre de possibilité a tester pour le SHA-1, jferais ptet pas autant le fanfarron

Comme je l'ai dit ci-dessus, en plus de la réduction de champ sur SHA-1 une équipe chinoise affirme avoir trouvé des algos de collision dessus...

 
Soit, selon la loi de Moore, la moitié dans 6 mois, le 1/4 dans 1 an etc.
A supposer que d'ici quelques années on ne fasse pas de découverte majeure dans le domaine de l'architecture des procs.
Attention à ce genre de considérations... rappelle toi dans les années 80 les ptits futés de 14 ans qui crackaient des sites secret-défense avec leur Alice ou leur C64. Même si c'est statistiquement peu probable, ça n'en reste pas moins réalisable.

Seul le marchand connait le prix de ses produits.
La banque (et son sytème de paiement) n'ont pas accès à cette base de données => pas de requete SQL.
 
Si le marchand propose au client de saisir ses infos bancaires sur son site (et d'appeler la banque en interface directe et donc de manière transparente pour le client), alors bien sûr il faut faire comme ça

En 20 ans tu divises par 10^6 la durée "seulement".

Un excellent article : http://www.schneier.com/blog/archi [...] sis_o.html