Identificadores aleatorios

[0123]

Buenas a todos,

Estoy haciendo una red social. Cuando los usuarios publican algo... se crea una URL de esta forma:

miweb.com/publicacion/4573/

Ese 4573 es el ID en la tabla de la base de datos. Discutiendolo con un amigo hemos decidido por seguridad crear como practicamente todos los servicios de Internet un identificador propio, por seguridad.

He pensado usar el uniqid... pero no estaba nada seguro.

¿Como lo hariais vosotros?. Creo que lo importante es:

-Tenga parametro aleatorio.
-Tenga parametro unico (que no tenga que comprobar si otra publicacion tiene ese mismo identificador generado, ya que esa validacion puede ser un bucle muy largo).
-Que sea corto
-Que pueda escalar sin modificar el concepto

¿Sabeis como empezar?. Es que es un tema muy importante. Podria hacer "algo" y que me solucione el problema. Pero siendo una cosa importante queria saber vuestra opinion.

[Triby]

Si de cualquier forma se va a mostrar en la URL esa ID, qué beneficios tiene evitar el uso de un campo auto incrementable?

Lo único que se me ocurre es evitar que los usuarios naveguen incrementando/decrementando ese número, pero si tienes un buen sistema de verificación de sesiones/roles/permisos, no le veo mayor problema.

Un campo auto incrementable cumple con tus requerimientos, excepto que no es aleatorio.

Veamos algunos ejemplos:
- ForosDelWeb muestra ID de foros, temas y mensajes en la URL (igual que vBulletin, aún en versiones recientes)
- PhpBB muestra ID de foros, temas y mensajes en la URL
- InvisionPowerBoard muestra ID de foros, temas y mensajes en la URL
- Wordpress sin URL amigable muestra ID de publicaciones en la URL
- OpenCart muestra ID en la URL
- MercadoLibre muestra ID en la URL

A menos que me equivoque, todos esos sistemas usan campos auto incrementables y relativamente fáciles de rastrear.

Cuéntanos un poco más de lo que hablaste con tu amigo respecto a la seguridad y entonces podríamos tratar de sugerir algo.

[Italico76]

Sino quieres que sepan el ID real......pues genera al azar un "ID falso" unique y lo guardas como un campo mas en tu tabla.... pero accederas a tus datos usando ese ID asi que en definitiva se comporta como el ID autoincrementable o sea que siempre podran referenciar ese registro.

No hay forma de ocultar por completo la DB si vas hacer busquedas para recuperar esos registros... siempre sera posible saber a que registros haces referencia.

Si no permites que el sitio sea navegable.. o sea.. si desconectas por completo el sitio de los datos... algo absurdo.. pues claro... tus datos quedan mas protegidos pero seran inutiles

Te la complicas demasiado jeje

[0123]

Buenas Triby e Italico76,

El caso es que la red social tiene datos privados y publicos. Y si el ID fuese un autoincrement puedo pensar casos donde es peligroso:

-Araña que copie los datos de los usuarios.
-Cuando un usuario publica algo, aunque sea publico, tiene "un minimo control sobre la URL", me explico. Creo que una red social no es igual que un foro donde todo es publico. En una red social aunque sea publico la información no debe ser rastreable tan facilmente. Basicamente para evitar curiosos o gente con malas intenciones. ¿No creeis?.

Llevo toda la mañana pensando en ello... y aun no lo tengo claro... mirando FB se me quitan las ganas... pero les comprendo.

Un saludo,

:D

Gracias por vuestros consejos

[Italico76]

No afirmo que sea un buen diseño... pero igual te lo dare:

Creas dos (2) tipos distintos de tablas de usuarios: 'usuarios' y 'usuarios_pv'. Vale... cuando muestras perfiles publicos, accedes a 'usuarios' y cuando accedes a los datos privados del propio usuario lo haces a 'usuarios_pv'

El ID de la tabla 'usuarios' es AUTOINC pero el de la tabla 'usuarios_pv' es generado aleatorio y obviamente es UNIQUE.

Como cuando muestras datos privados (link para cambiar contraseña, etc) los paginas se recorren por $_POST e inclusive valores de campos pueden guardarse en varialbes de $_SESSION, no tendras problema de que nadie pueda interceptar eso! O sea....

No haras http://mi_red.com/usuarios/6564656SD/edit/contrasena

sino

http://mi_red.com/admin

Ves la diferencia ? cuando manejas datos privados no muestras NADA en la URL, a excepcion como mucho del nombre del controlador y/o la accion pero no muestras IDs ni nada

[webankenovi]

Iniciado por Italico76

No hay forma de ocultar por completo la DB si vas hacer busquedas para recuperar esos registros... siempre sera posible saber a que registros haces referncia

yo no lo creo asi, por ejemplo

$ID // imaginemos que es la id ahora creamos la url

mired.com/publicaciones/base64_encode($ID)

para recuperarlo

$ID = base64_decode($_GET['ID'])

base64 no es que sea seguro pero ya no lo enviamos literalmente el ID

otro ejemplo es usar mcrypt_encrypt y mcrypt_decrypt , enviando el id encriptado y para recuperarlo desencriptamos y obtenemos el id,esto es mucho mas seguro que usar base64 ,esta es la opción que te recomiendo para lo que quieres hacer .

un saludo

[Italico76]

@webankenovi: tu sabes bien que la solucion que estas dando es "reversible" con cierto trabajo..... siempre se puede recuperar la referencia al registro o el propio ID,... el compañero creo quiere algo mas "extremo" ... a mi entender, algo que creo a pocos se nos ocurre plantear... tanto que es paranoico o esta haciendo un portal para el NSA y nos dice que una "red social" jejeje

Iniciado por webankenovi

yo no lo creo asi,

(...)

base64 no es que sea seguro pero ya no lo enviamos literalmente el ID

[webankenovi]

si claro que son reversibles, pero mas seguro una id encriptada no?ante una que no lo este

id = base64_encode(mcrypt_encrypt(data)) por ejemplo, hay muchas formas mas ,no se si servira para la pagina de la NSA jeje

[0123]

Jeje NSA... jeje...

Es que soy muy paranóico. Hace poco cree una araña para copiar una web guardando la información en una base de datos, y me costo tan poco que me entra la paranoia de que me lo puedan hacer a mi.

La idea de webankenovi me mola cantidad. Pero realmente no es seguro, alguien malintencionado puede ser realmente mal intencionado. Podria encontrar la forma de encriptacion y darme en toda la boca.

Actualmente tengo las URLS como dice Italico76. Salvo por que cuando uso URLS publicas se muestran ID's.

...

Ahora me doy cuenta de que mi pregunta tenia que haberla hecho de este modo, creo que es en realidad donde se reduce mi problema:

¿Es posible generar una cadena aleatoria sin repetición?.

Y me contesto... solo existe la posiblidad de usar un parametro de tiempo, en otros casos siempre tendria que comprobar si existe ese mismo ID. Y si tuviese que comprobar si existe ese mismo ID... igual entro en un bucle.

Muchas gracias a todos... voy a investigar y os comento con que solucion acabe.

:D

[Triby]

Repito (burp!):

Iniciado por Mi mismo

si tienes un buen sistema de verificación de sesiones/roles/permisos...

Entonces, si se puede rastrear una URL, no importa si incluye la ID de publicación o no, se podrá acceder a ella, cierto?, no del todo, por ejemplo: en facebook, te serviría de algo tener la ID y/o URL de una publicación privada si el autor no está entre tus contactos?... paréceme que no.

[0123]

Joo... me estoy dando cuenta de que no se puede generar una cadena aleatoria... con alguna influencia que le haga ser unica.

Ups... me parece que voy a tener que generar un bucle para validar la existencia de esa cadena en la bbdd... lo cual no creo que haga... Jo!...

Continuo investigando...

[0123]

Buenas Triby,

No es problema de sesiones/roles/permisos... el sistema esta bien programado. El usuario solo puede ver a lo que tiene permisos. Con eso no tengo ningun problema.

Mi problema, es que aunque el contenido pueda ser visible el usuario que lo ha publicado no tiene la intencion de mostrartelo.

Y si fuese un numero consecutivo, seria tan simple como ir añadiendo un 1 al id y verte toda la información de la web.

:P, creo que muchas grandes webs funcionan de este modo. Simplemente ofuscan sus URLs para evitar ese comportamiento.

El problema es que yo nunca lo he hecho... y estoy pensando en como hacerlo. Y veo que realmente es un tema con muchos recovecos.

[Triby]

Bueno, a modo de ejemplo:

Desarrollé una red de negocios para un cliente donde los usuarios pueden ver/descargar documentos, aunque hay varios niveles de acceso:

1- Invitados
2- Usuarios registrados
3- Contactos de la empresa
4- Empleados

Cada empresa publica documentos y selecciona quien puede ver/descargar. Aún sabiendo que la ID es secuencial, si un invitado/bot/lo que sea intenta acceder a documentos de nivel 2 en adelante, obtendrá un mensaje de error.

Lo mismo si un usuario registrado intenta descargar documentos de una empresa que no forma parte de sus contactos o documentos exclusivos para empleados de otra empresa.

Entonces, el mayor riesgo de esto es ataque por fuerza bruta, pero este puede hacerse independientemente de que uses campos auto incrementables y debes adecuar sistemas de protección tanto en tu script como en el servidor (o nube).

[webankenovi]

Iniciado por 0123

Mi problema, es que aunque el contenido pueda ser visible el usuario que lo ha publicado no tiene la intencion de mostrartelo.

Y si fuese un numero consecutivo, seria tan simple como ir añadiendo un 1 al id y verte toda la información de la web.

Esto sucede por una mala verificacion, no por que un usuario añada 1 al id se le van a mostrar los datos.... por lo cual es indiferente usar numeros consecutivos o no dan lugar al mismo resultado si no existe ninguna verificacion y tu en este caso deseas hacer invisible(no adivinable) dicho id para que no suceda lo dicho pero no creo que sea esa la solucion .