2010-12-13 29 views
8

mi aplicación PHP usa URLs como estas:fácil Cifrado y descifrado con PHP

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

Las llaves y el final de la URL son básicamente la clave primaria de la tabla de base de datos MySQL.

No quiero que este número cada vez mayor sea público y tampoco quiero que alguien pueda rastrear los perfiles de usuario con solo analizar el Id.

Por lo tanto, quiero encriptar este Id para que se muestre de forma que pueda descifrarlo fácilmente. La cuerda no debería durar mucho más.

¿Cuál es el mejor método de encriptación para esto?

+2

Sugeriría utilizar el nombre de usuario en la url, como http://domain.com/user/jsmith. Es más web 2.0, mantiene su clave principal en secreto y no sobrecarga el servidor cifrando/descifrando la clave principal – aletzo

+0

Estoy tratando de resistir el impulso de decir * que lo está haciendo mal *. En primer lugar, ¿a quién le importa si los perfiles de usuario pueden rastrearse? De todos modos, Google los encontrará de todos modos, por lo que no hay una forma real de detenerlo, salvo dejarlos detrás de un inicio de sesión (y aun así, alguien que quiera la información lo obtendrá). En segundo lugar, ¿por qué usar la identificación en la url? ¿Por qué no utilizar el nombre de usuario único (el nombre de usuario es único, ¿no?)? Le da más significado semántico que el número, y no debería ser mucho menos eficiente (suponiendo que tiene 'UNIQUE' establecido en la columna de nombre de usuario) ... – ircmaxell

Respuesta

0

Obscurecer la URL nunca lo protegerá. Hace que sea más difícil de leer, pero no mucho más difícil de manipular. Puede usar una representación numérica hexadecimal o algo así para ocultarlo. Aquellos que pueden leer hexagonal puede cambiar su dirección URL en unos pocos segundos, de todos modos:

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

Un mejor enfoque (desde una perspectiva de usabilidad y SEO) sería utilizar una única frase en lugar de una identificación oculta. En este caso, el nombre de usuario del usuario parecería una solución ideal, y también sería imposible de adivinar.

Dicho esto, si no desea utilizar este enfoque, puede utilizar un hash (quizás md5) del nombre de usuario del usuario que almacenaría en la base de datos junto con sus otros detalles. Como tal, puedes hacer una búsqueda directa en ese campo. (Es decir: Tener cifrar y descifrar parte de la URL es algo excesivo.)

-1

generar una cadena única para cada usuario y utilizarlo en sus URL

http://domain.com/user/ofisdoifsdlfkjsdlfkj en lugar de http://domain.com/userid/121

7

oscureciendo simple: Base64 los codifica utilizando base64_encode.
Ahora, su http://domain.com/userid/121 pasa a ser: http://domain.com/userid/MTIx
Quiere más, hágalo de nuevo, agregue algunas letras a su alrededor.

Obscurecimiento Difícil: Utilice cualquier método de encriptación usando la biblioteca MCrypt.

+0

¿cómo distinguiría entre un cifrado simple y difícil? –

+0

@Sandeepan, Simple sería fácil de descifrar y no utiliza una clave, pero difícil es descifrar. – shamittomar

+0

¿cómo distinguirías entre fácil de descifrar y difícil de descifrar? ;-) –

1

Método de cifrado más simple pero potente: XOR con una clave secreta. http://en.wikipedia.org/wiki/XOR_cipher Sin degradación práctica del rendimiento.

¡La representación de Base64 no es una encriptación! Es otra manera de decir lo mismo.

Espero que esto ayude.

+0

Gracias por el comentario de base64 que no es un cifrado. ¡Eso tenía que decirse! –

-1

puede utilizar base64_encode y base64_decode función para cifrar y descifrar sus URL

+0

+1 para equilibrar a quien le dio el voto negativo. Tu respuesta no es mala –

+1

El voto a favor no fue mío, pero el código de base64_ (en | de) no es (en | de) cryption. Oscurecería ligeramente el número de identificación, pero de una manera predecible. – Aether

+0

base64 no hace encriptación, cualquier desarrollador reconocerá fácilmente y podrá descifrar el valor y, por lo tanto, podrá rastrear las páginas. – JohnSmith

3

Usted tiene una variedad de opciones aquí:

  • generar y almacenar un identificador en la base de datos. Es bueno porque puede tener claves legibles que garanticen que son únicas.Es malo porque causa un cambio en el esquema de la base de datos, y usted tiene que consultar esa tabla cada vez que quiera generar un enlace.

  • Ejecute un cifrado real basado en claves, por ejemplo, basado en MCrypt de PHP. Usted tiene acceso a potentes algoritmos criptográficos, pero la mayoría de los algoritmos seguros tienden a producir cadenas mucho más largas de lo que espera. XOR hace lo que quiere, pero no impide el acceso a valores secuenciales (y la clave es bastante simple de determinar, dado el conocimiento a priori sobre los números).

  • Ejecutar una verificación basado en hash: en lugar de utilizar 121 como su identificador, utilice 121-a34df6 donde a34df6 son los seis primeros caracteres del md5 (u otro HMAC) de 121 y una clave secreta. En lugar de decodificar, extrae el 121 y vuelve a calcular los seis caracteres para ver si coinciden con lo que el usuario envió. Esto no oculta el 121 (todavía está allí antes del guión), pero sin conocer la clave secreta, el visitante no podrá generar los seis caracteres para ver realmente el documento numerado 121.

  • Utilice XOR con arrastrar de página: mezcle los bits en el identificador de 30 bits, luego aplique el XOR. Esto hace que el XOR sea más difícil de identificar porque el patrón de mezcla también está oculto.

  • Uso XOR con claves a la carta: fb37cde4-37b3 utilizar como clave, donde la primera parte es el XOR de 121 y md5('37b3'.SECRET) (u otra forma de generar una clave XOR basado en 37b3 y un secreto).

No utilice base 64, que es fácil de realizar ingeniería inversa: si MTIx es 121, entonces es MTIy122 ...

En última instancia, tendrá que aceptar que su solución no será segura: no solo es posible que los usuarios filtren URL válidas (a través de su historial de navegador, referenciador HTTP o publicarlas en Twitter), sino que su requisito de que el identificador se ajuste a una pequeña cantidad de caracteres significa que es posible un ataque de fuerza bruta (y se vuelve más fácil a medida que comienzas a tener más documentos).

0

Probablemente diría que es mejor crear una cadena aleatoria para cada usuario y almacenarla en su base de datos que obtener una mediante hash. Si usa un hash común, todavía es muy fácil iterar en todas las páginas ;-)

Escribo esto en los comentarios, pero no tengo el representante para eso (¿todavía?).

0

Cuando el usuario hace clic en un enlace, no debe usar la clave principal. Puede usar la clave en una sesión y obtenerla de esa sesión. Por favor, no use cadena de consulta ....

Cuestiones relacionadas