Discussion :

[Florent08800]

Bonjour je voudrai savoir comment faire pour modifier un créer à partir d'un entier simple (12, 25, 49, ...) une chaine alpha-numérique pour éviter de repérer mon entier (j'utilise un auto-incrément). De plus je voudrai que cette fonction soit bijective, donc pas d'utilisation de md5() car. Merci de votre aide

[Maxoo]

si elle est bijective, elle est cassable donc ...

juste pour comprendre, tu t'en sers dans quoi ?

[Florent08800]

Cela me dérange pas que cela soit cassable, je veux juste masquer l'entier qui est issu de ma base par auto-incrément à l'utilisateur par exemple comme par-exemple pour masquer le numéro d'un ticket, etc... afin d'éviter d'avoir ticket n°1.

ce traitement est juste au niveau de l'affichage, je ne veux pas stocker l'entier crypter dans ma base.

[Maxoo]

ce traitement est juste au niveau de l'affichage, je ne veux pas stocker l'entier crypter dans ma base.

affichage ?
ou passage en GET ?

c'est vraiment grave si le mec voit ticket 1 ? ca rend ton site cassable ?

[Florent08800]

non en affichage, j'ai pas envie de lui montrer si mon site est réactif ou pas, donc juste un petit algo de cryptage bijectif me suffirait

[Maxoo]

pourquoi bijectif alors ? si c'est juste pour afficher, pourquoi ne pas afficher un md5() de cela ?

[Florent08800]

par exemple dans le cas d'un numéro de commande, si un client appele et dit j'ai un soucis sur ma commande ea12b568 je pourrai pas retrouver sa commande

[Maxoo]

oki en gros tu veux un chiffre, mais tu veux pas qu'il voit que c'est le premier mec à venir sur ton site ?

[Florent08800]

oui voilà exactement pour masquer l'activité de mon site

[Maxoo]

oui mais le truc, il faut que ton chiffre grand soit unique ...
et ca c'est pas facile ...

P.S : tu peux toujours partir de 148373 et voila comme ça t'es content.

Allez ++

[SuperCed]

Le problème d'un grand nombre, c'est que si quelqu'un vient un dimanche et reviens le dimanche d'après, il verra le nombre de commandes passées entre les deux dates. Il lui suffira de faire une soustraction des 2 nombres pour avoir le nombre de commande pendant une semaine.
Ce n'est donc pas la solution.

Le problème est le suivant. Sur le site de e-commerce, on a une base de données avec un numéro de commande auto-incrémenté.

Donc une personne qui passe 2 commandes pendant un certain délai peut connaître exactement le nombre de commandes passées dans cet intervalle.

Il faut donc qu'on génère un nombre qui n'indique pas le nombre de commandes passées entre 2 dates de commandes.
Le MD5 ne convient pas, car si le client appelle et donne son numéro MD5, nous ne pourrons pas retrouver son vrai numéro de commande.
MD5 est très bien pour stocker des mots de passe, mais c'est mauvais dans notre cas.

Un cryptage serait bon dans notre cas, le problème, c'est qu'il faudrait que la version cryptée du numéro de commande soit simple. Il faut pas que le numéro de commande fasse 64 chiffres et que le client nous donne ça.
Il nous faudrait simplement une chaine d'à peu près 6 à 10 chiffres seulement.

Connaissez-vous un algo de cryptage qui puisse fonctionner dans notre cas?

Merci!

[Maxoo]

pourquoi ne pas faire un champ id et champ id_fake dans votre table
et dans id_fake vous mettez ce que vous voulez pour le client
vous pouvez prendre les 10 premier chiffre du md5, faire un randid. etc ...

Sinon pour les scripts il doit en avoir sur internet, suffit de chercher.

Moi je trouve stupide de vouloir cacher cela ...
ou alors vous faites des commande avec le nom du mec suivit d'un numéro
et ca sera sa premiere commande, et sa deuxieme commande, il saura pas si les autres en ont fait ...

[SuperCed]

Le md5 ne me plait pas.
Je vais tenter d'expliquer.
En fait, même en utisant le md5 avec une valeur aléatoire et de le stocker dans un champ, rien ne prouve qu'on ne tombera pas deux fois sur le même nombre.
Et là, si on essaye de retrouver la commande, on va tomber sur 2 commandes!!!
Laquelle prendre, là c'est un peu hasardeux.
Je suis d'accord que cela ne devrait arriver que rarement, mais je n'ai pas envie qu'on ait ensuite des problèmes à cause de ça.

Quand à la stupidité de cacher le nombre de commandes, elle n'est pas mienne. De plus, je ne pense pas que cela soit si stupide.
En effet, il existe de la concurrence sur certains marchés, et le fait de donner le nombre de commandes passées sur un site peut donner une information de valeur.
Le but est de donner le minimum d'information à la concurrence. Pour nous, si nous pouvions avoir le nombre de commandes de nos concurrents, cela nous aiderait bien à évaluer le nombre de produits à commander chez nos fournisseurs.
Il est donc préférable, même dans le doute, d'éviter de donner cette information.

Ta deuxième idée est par contre très intéressante. Le fait de donner un numéro de commande avec le nom et le nombre de commande par utilisateur est très bonne.
Nous allons réfléchir à cette solution. Peut être allosn nous simplement concaténer le numéro de client avec son nombre de commande.

Merci beaucoup pour l'idée, c'est "stupide" de notre part de ne pas y avoir pensé avant ;-)

[berceker united]

Personnellement, je comprend parfaitement son inquiétude car je suis dans le e-commerce et je me retrouve dans le même cas que lui. Moi j'ai opté pour une numéro de commande généré par divers critères.
Dans ma table commande il y aura bien un id utilisable uniquement pour l'usage interne mais il y aura un autre champs "num commande" qui lui est généré par un script que tu devras reflechire. Par sécurité il ne faut pas associé l'identifiant unique de la table commande au numéro de la commande car c'est trop dangereux. Pas besoin de MD5() car comme il le souligne il faut que ça reste compréhensible pour le client.
un numéro de commande de la sorte : xxx-xxx-xxx-xxx ouvre beaucoup de possibilité. Via ce script il ne sera pas possible de remonter les informations.

[guitou12]

Pour reprendre l'idée de Maxoo le mieux est de prendre le nom du client (pas forcément unique) concaténé à la date de la commande (pas unique non plus) et tu peux rajouter l'heure+minutes+secondes+milisecondes (si tu arrives à avoir 2 fois la même chapeau

DUPOND1007061543251 ça me semble pas mal non ?

[Sylvain71]

Pourquoi pas un truc tout simple ?
Genre pour chaque chiffre du numéro de commande, tu remplaces par la lettre correspondante (A=1,B=2 ...).
Et après histoire d'embrouiller un peu tu décalles ces lettres, un truc comme avec la fonction str_rot13() par exemple.

Comme ça ta chaine est "pseudo cryptée", et tu peux facilement retrouver le numero d'origine.
J'ai bon ou jsuis à coté de la plaque ?

[Florent08800]

Merci pour toutes ses idées aussi intéressantes les unes que les autres. Finalement on a opté pour un système efficace mais surement complexe pour l'utilisation que l'on veut en faire.

D'abord on crypte le numero de commande issu d'un auto-incrément avec la fonction mcrypt_encrypt en utilisant l'algo xtea en mode ecb. Ensuite on code le resultat crypté en hexa-décimal pour avoir un numéro de commande de 16 charactère hexa-decimal.

Et pour retrouver le numéro de commande (entier issu d'un auto-incrément) on décode la chaine hexa-decimale puis on décrypte avec mcrypt_decrypt. Voilà le tour est joué.

Merci de toutes vos remarques avisées.

[Maxoo]

Merci pour toutes ses idées aussi intéressantes les unes que les autres. Finalement on a opté pour un système efficace mais surement complexe pour l'utilisation que l'on veut en faire.

D'abord on crypte le numero de commande issu d'un auto-incrément avec la fonction mcrypt_encrypt en utilisant l'algo xtea en mode ecb. Ensuite on code le resultat crypté en hexa-décimal pour avoir un numéro de commande de 16 charactère hexa-decimal.

Et pour retrouver le numéro de commande (entier issu d'un auto-incrément) on décode la chaine hexa-decimale puis on décrypte avec mcrypt_decrypt. Voilà le tour est joué.

Merci de toutes vos remarques avisées.

et donc votre client, il doit vous dire un numéro de commande hyper compliqué.

[guitou12]

Plus c'est compliqué plus ça fait sérieux

[Florent08800]

Effectivement, il doit nous dire une chaine assez compliqué mais cependant il ne nous contactera pas si souvent que cela, c'est surtout au niveau d'un retour d'un produit qu'il devra le préciser.

C'est vrai que cela est compliqué, au moins la concurrence n'est pas prêt de voir l'evolution de commandes.