¿Debo ocultar las claves primarias (ID) de la base de datos en el extremo frontal de la aplicación?

La única información que puede esperar "ocultar" es la secuencia : dado que una base de datos asignará los valores de la clave primaria con un contador, las personas que la vean pueden hacer una conjetura para cuando se creó la cuenta de usuario correspondiente. Aparte de eso, no hay otra información que cualquier esquema de ocultación pueda ocultar. El atacante ya sabe que se hace referencia a usuarios distintos mediante claves distintas, y esa es la extensión de la semántica de la base de datos "clave principal".

Por lo tanto, a menos que considere que el orden de creación de la cuenta es información privada que debe ocultarse, yo diría que su esquema de ocultación no tiene sentido.

Una forma fácil sería utilizar el método que usan youtube y otros sitios web. Se trata de hashids ( enlace ).

Con este método, puede proporcionar enlaces como: enlace mientras que fce7db sería igual a un número, por ejemplo: 12

Esto tiene la ventaja de que el rendimiento es contrario a generar otro hash aleatorio en la base de datos, ya que solo tienes que traducirlo una vez y luego puedes buscar en la base de datos con la clave principal original como hiciste antes.

Para que a los usuarios les resulte más difícil encontrar otras ID de forma aleatoria, puede usar una sal secreta por una longitud mínima y así evitar que las "forzen con fuerza".

Al tener una sal secreta, las personas aún pueden intercambiar las URL en casos como enlace .

No. De una forma u otra, debe identificar el registro específico con un identificador único en la URL. Esa puede ser la clave principal o algo más. Si necesita ocultar el orden o la secuencia, puede usar una segunda columna con una cadena aleatoria y única como Z2wDKo0ubb1D2VngFh4N.

Si quieres más seguridad, usa SSL. Sin embargo, esto no impide que el usuario vea la URL y los parámetros, como se observó en @eggyal.

Usando SSL, los parámetros de URL están encriptados y evitan las escuchas ilegales. Y sí, ya sabemos que SSL es defectuoso, en realidad no es tan seguro, pero brinda más seguridad que no usarlo. ¡Pero no use la URL para las contraseñas! Use POST para iniciar sesión y enviar datos, GET para recuperar información, como siempre.

Consulte enlace

Razones para no usar información secreta en una URL: las solicitudes de DNS probablemente no están cifradas (pero como se nota en @tgies en los comentarios, la parte de la solicitud no se incluye, por lo que aquí no hay ID), el historial del navegador y los registros del servidor.

He creado algunos sistemas que usan o no la clave principal (u otro identificador) en la URL. Lo que usamos depende totalmente del factor de daño: por ejemplo, para un sitio que solo funciona con datos, usamos la clave principal en la URL; no nos importa si alguien pasa por los productos de forma secuencial.

Para los sistemas que tienen requisitos de seguridad, en lugar de usar una identificación predecible secuencial, hemos usado uno de dos esquemas:

1. Mantenemos la información clave de la sesión del navegador. Simple, directo y si nuestro servidor no es seguro, tenemos problemas más grandes.
2. Hemos generado un número aleatorio (y hemos comprobado su exclusividad) cuando se crea el registro O solo para la sesión; y usé ese número aleatorio dentro de la URL.

Buena suerte,

Larry

Sí, debes ofuscar esas ID, ya que estás filtrando información.

Si su aplicación es perfectamente segura, la única información que (ab) pueden aprender es una estimación del número de usuarios mediante el uso de algo llamado Argumento de Doomsday ^‡ . Además, si aprenden los ID de varios usuarios, sabrán quién se inscribió primero y podrán adivinar qué tan lejos sucedió. Y también pueden hacer conjeturas informadas de las ID de otros usuarios.

Si su aplicación es perfectamente segura.

Si no lo es, y siempre debe asumir que puede que no lo sea, ha proporcionado información útil. Si una ID de usuario era solo un número aleatorio, un atacante no podría averiguar fácilmente otra ID válida. Con los números (en su mayoría consecutivos) que usualmente se dan mediante una clave primaria automática, es trivial.

Puede cambiar la clave principal o agregar una clave secundaria si desea conservar la facilidad de uso de números pequeños para uso interno. Esta nueva clave normalmente debe ser un GUID .

^{‡: Por supuesto es un enlace xkcd.}

No proporciona suficiente información sobre la aplicación para saber si debe ocultarla o no. Como tal, esta parte de tu pregunta no es respondible. Sin embargo, si tiene que preguntar, entonces la respuesta es probablemente sí, e incluso si no es así, ir más allá de la llamada del deber proporciona más protección que la alternativa.

En lugar de ocultar u ocultar la clave principal, considere cambiarla. No hay necesidad de que sea secuencial. Cuando cree un nuevo usuario, cree un número aleatorio de 32 bits, haga una selección rápida para asegurarse de que no esté en uso y utilícelo como su clave principal.

Si alguien está editando un usuario, no podrá obtener ninguna información del número de usuario, y es probable que los números de prueba inmediatamente adyacentes al número al que tienen acceso actualmente produzcan un registro no existente.

La sobrecarga / carga de este sistema es mínima. Requiere una selección adicional durante la creación de la cuenta, lo que probablemente sea poco frecuente, y no impone ninguna sobrecarga adicional; sigue proporcionando la clave principal en la URL, por lo que las búsquedas de base de datos aún son rápidas, pero la clave no tiene información.