Problema de seguridad de autenticación de cliente-servidor

Question

Problema de seguridad de autenticación de cliente-servidor

#1 de ThoriumBR (2 votos)
#2 de 0x01Noodle (0 votos)

4

Esta es una nueva publicación, ya que accidentalmente he publicado en stackoverflow primero

Me preguntaba cómo podría lograr un alto nivel de seguridad, usando la autenticación cliente-servidor. A continuación se muestra un borrador de lo que pensé:

Déjameexplicarlounpocomás:

ElejecutabledeC++seestáejecutandoenunaconsoladejuegosquetieneunIDúnicoqueelusuarioutilizapararegistrarseenmisitioweb
Cuandoseinicieelejecutable,obtendráelhashdemódulo/archivoactualdelejecutableylaIDúnica("Clave" en el boceto) y realizará una solicitud web a mi sitio web (ejemplo en azul en el boceto)
El auth.php en mi sitio web luego verificará si el hash del archivo es el mismo que el archivo que se entregó (detectando si el archivo fue modificado). También comprobará si la "Clave" está conectada a un usuario
Luego, enviará información individual de ese usuario y también algunos datos / desplazamientos necesarios para que el ejecutable se ejecute correctamente más tarde (Esto evitaría que el atacante teóricamente solo interrumpa la conexión a Internet, por lo que tiene que hacer una llamada a mi sitio web para obtener los datos necesarios para ejecutar el ejecutable correctamente)

Me sonó bien al principio, pero luego noté algunas fallas:

Aunque estoy confundiendo y cifrando el archivo, un pirata informático aún podrá desarmarlo. Eso significa que podría sacar mi cheque si la clave está falsificada y simplemente enviar la clave de un usuario registrado (también puede editar el hash que se envía para evitar el chequeo completo si se modificó el archivo, lo que lo hace un poco redundante)
También puede leer los datos que se envían después de una autenticación exitosa y luego interrumpir la conexión a Internet, por lo que ya no hay llamadas a mi sitio web e insertar los datos que ingresó en el ejecutable para que funcione.

No importa la seguridad en el ejecutable, un hacker siempre podrá desmontarlo / descompilarlo en algún momento. Por eso creo que la autenticación cliente-servidor debe ser para que, incluso si el cliente es secuestrado, no podrá autenticarse. Realmente no sé si eso es posible o si es solo el enfoque equivocado.

Realmente apreciaría si pudieras dejar algunos pensamientos o ideas abajo. Gracias por su tiempo y que tenga un buen día :)

php c++ mysql license-enforcement

pregunta ZZ_James 05.05.2017 - 19:18

fuente

2 respuestas

Lea otras preguntas en las etiquetas php c++ mysql license-enforcement

OAuth: ¿Qué sucede si se roba el token de actualización? ¿Qué pasos adicionales se pueden tomar en una prueba de penetración de la red inalámbrica después de adquirir el pin WPS?

score 2 · Answer 1

No puede confiar en el cliente, y la autenticación del cliente-servidor no puede funcionar.

Cualquier hacker puede ejecutar una versión no modificada de su software, capturar todos los datos que necesita y cambiar el archivo ejecutable del cliente más adelante. El uso de un proxy de intercepción le permitirá cambiar la solicitud y utilizar el hash original del archivo.

O puede usar una clave válida, descargar las partes faltantes, parchear el archivo ejecutable para incluir esas partes y omitir la autenticación.

El uso de TLS no ayuda, ni siquiera el empeño del certificado. Como él tiene el control de la conexión, incluso puede cambiar el ejecutable del cliente para permitir que su propio certificado pase los cheques.

Él podrá autenticarse sin importar qué. Sus protecciones son solo golpes de velocidad, no bloqueos de carreteras. La lista de esquemas DRM rotos incluye Sim City, Diablo, Battle Field, Doom, Assassin's Creed, Dishonored, lo tienes.

Si incluso Ubisoft, EA, Sony, Microsoft, Konami y otros no pueden disuadir a los atacantes, es probable que tampoco puedas disuadirlos.

score 0 · Answer 2

Veo un par de posibles amenazas:

Vulnerabilidad para los ataques Man-in-the-Middle. ¿Qué sucede si un atacante obtiene un hash válido, cambia el archivo posteriormente y luego realiza un Ataque MitM para reemplazar el archivo malicioso generado por el que calculó en primer lugar? En su configuración esto debería tener éxito, aunque manipuló el archivo.
La autenticación a través del parámetro de consulta HTTP URI no es una buena idea, ya que se pueden encontrar en varios archivos de registro o en el historial del navegador.
Como ya ha señalado, no se puede confiar en todo lo que almacena en un cliente como los archivos del lado del servidor, ya que los atacantes pueden modificarlos de cualquier manera y pueden extraer material clave. Esto puede ser trivial o no, pero debes asumir que es posible.

Para mitigar esas amenazas, debes:

Usar encabezado de autenticación HTTP

En lugar de enviar información de autenticación a través del parámetro de consulta HTTP, páselos usando el encabezado de autenticación HTTP. Me gusta:

GET example.com Authorization: Basic base64(userid:userpass)

En lugar de GET example.com?auth=xxx&hash=xxx

Ya que ya tienes algún tipo de clave API (¿parámetro de autenticación, supongo?) que está vinculado a un usuario, deberías echar un vistazo a OAuth2.0. Es un enfoque bien establecido para autorizar a los clientes a actuar en nombre de un usuario.

Usar TLS

La seguridad de la capa de transporte es necesaria para garantizar la confidencialidad de la conexión. De esta manera, puede estar seguro de que el cliente habla con su servidor utilizando el cifrado. Si necesita más seguridad, también habilite la autenticación TLS mutua (es decir, el cliente también debe autenticar).

Firma los archivos

La única forma de detectar archivos manipulados en el cliente es firmarlos en el servidor antes de enviarlos al usuario. Su aplicación de C ++ debe verificar si la firma es válida antes de ejecutar el archivo. Si ha habilitado una conexión TLS, ya debería estar en posesión de las claves requeridas.