chiffrement facile et avec PHP Decryption

Question

Mon application PHP utilise des URL comme celles-ci:

http://domain.com/userid/120 
http://domain.com/userid/121 

Les touches et la fin de l'URL sont essentiellement la clé primaire de la table de base de données MySQL.

Je ne veux pas que ce nombre croissant soit public et je ne veux pas non plus que quelqu'un soit capable d'explorer les profils utilisateur juste en interagissant avec l'ID. Donc, je veux crypter cet Id pour l'affichage d'une manière que je puisse facilement décrypter à nouveau. La chaîne ne devrait pas durer plus longtemps.

Quelle est la meilleure méthode de chiffrement pour cela?

Answer 1

L'obstruction de l'URL ne le sécurisera jamais. Cela rend la lecture plus difficile, mais pas beaucoup plus difficile à manipuler. Vous pourriez utiliser une représentation en nombre hexadécimal ou quelque chose comme ça pour l'obscurcir. Ceux qui peuvent lire hex peuvent changer votre URL en quelques secondes, de toute façon:

$hexId = dechex($id); // to hex 
$id = hexdec($hexId); // from hex 

Answer 2

Une meilleure approche (d'une facilité d'utilisation et de la perspective SEO) serait d'utiliser une expression unique, plutôt que d'un ID obscurci. Dans ce cas, le nom d'utilisateur de l'utilisateur semblerait une solution idéale, et serait également impossible à deviner. Cela dit, si vous ne voulez pas utiliser cette approche, vous pouvez simplement utiliser un hash (peut-être md5) du nom d'utilisateur de l'utilisateur que vous stockez dans la base de données avec leurs autres détails. En tant que tel, vous pouvez simplement faire une recherche directe sur ce champ. (Ex: Avoir Chiffrer et déchiffrer une partie de l'URL est probablement excessif.)

Answer 3

générer une chaîne unique pour chaque utilisateur et l'utiliser dans vos urls

http://domain.com/user/ofisdoifsdlfkjsdlfkj au lieu de http://domain.com/userid/121

Answer 4

simple obscurcissement: Base64 les coder en utilisant base64_encode.
Maintenant, votre http://domain.com/userid/121 devient: http://domain.com/userid/MTIx
Vous voulez plus, faites-le à nouveau, ajoutez quelques lettres autour de lui.

Tough Obscuring: Utilisez une méthode de cryptage à l'aide de la bibliothèque MCrypt.

Answer 5

Méthode de chiffrement simple mais puissante: XOR avec une clé secrète. http://en.wikipedia.org/wiki/XOR_cipher Aucune dégradation des performances pratique.

La représentation de Base64 n'est pas un cryptage! C'est une autre façon de dire la même chose.

Espérons que cela aide.

Answer 6

vous pouvez utiliser base64_encode et base64_decode fonction pour chiffrent et déchiffrent vos URLS

Answer 7

Vous avez une variété de choix ici:

• Génération et stockage d'un identifiant dans la base de données. C'est bien parce que vous pouvez alors avoir des clés lisibles qui sont garanties d'être unique.C'est mauvais car cela provoque un changement de schéma de base de données, et vous devez en fait interroger cette table chaque fois que vous voulez générer un lien.

• Exécutez un chiffrement basé sur les clés, basé par exemple sur MCrypt de PHP. Vous avez accès à de puissants algorithmes cryptographiques, mais la plupart des algorithmes sécurisés ont tendance à produire des chaînes beaucoup plus longues que ce à quoi vous vous attendez. XOR fait ce que vous voulez, mais cela n'empêche pas d'accéder à des valeurs séquentielles (et la clé est assez simple à déterminer, étant donné la connaissance a priori des nombres).

• Exécuter une vérification par hachage: au lieu d'utiliser votre identifiant 121 comme, utilisez 121-a34df6 où a34df6 sont les six premiers caractères du md5 (ou tout autre HMAC) de 121 et une clé secrète. Au lieu de décoder, vous devez extraire le 121 et recalculer les six caractères, pour voir s'ils correspondent à ce que l'utilisateur a envoyé. Cela ne cache pas le 121 (il est toujours là avant le trait d'union) mais sans connaître la clé secrète, le visiteur ne pourra pas générer les six caractères pour voir réellement le document numéroté 121.

• Utiliser XOR avec shuffling: mélanger les bits dans l'identificateur 30 bits, puis appliquer le XOR. Cela rend le XOR plus difficile à identifier car le motif aléatoire est également masqué.

• Utilisation XOR avec la demande clés: utiliser fb37cde4-37b3 comme clé, où la première partie est le XOR de 121 et md5('37b3'.SECRET) (ou d'une autre façon de générer une clé XOR basée sur 37b3 et un secret).

Ne pas utiliser base64, il est facile de désosser: si MTIx est 121, puis MTIy est 122 ...

En fin de compte, vous devrez accepter que votre solution ne sera pas sécurisée: non seulement les utilisateurs peuvent-ils divulguer des URL valides (via l'historique de leur navigateur, le referer HTTP ou les publier sur Twitter), mais votre exigence selon laquelle l'identifiant doit figurer dans un petit nombre de caractères signifie une attaque par force brute (et devient plus facile lorsque vous commencez à avoir plus de documents).

Answer 8

Je dirais probablement qu'il vaut mieux créer une chaîne aléatoire pour chaque utilisateur et la stocker dans votre base de données plutôt que d'en utiliser une en utilisant le hachage. Si vous utilisez un hachage commun, il est toujours très facile d'itérer sur toutes les pages ;-)

Je l'écrirais dans les commentaires, mais je n'ai pas le représentant (encore?).

Answer 9

Lorsque l'utilisateur clique sur un lien, vous ne devez pas utiliser la clé primaire. Vous pouvez utiliser la touche p dans une session et l'obtenir à partir de cette session. S'il vous plaît ne pas utiliser la chaîne de requête ....