¿Es fundamentalmente posible validar que una versión no modificada de su cliente se conecta a su servidor?

Es fundamentalmente imposible validar un cliente en un sistema que no controlas.

Eso no significa que no se pueda hacer en un grado suficiente. Los lectores de libros electrónicos, por ejemplo, generalmente intentan asegurarse de que el cliente sea auténtico. Ellos (parecen) hacerlo de una manera que sea lo suficientemente segura como para defenderse contra su amenaza. ¿Lo suficientemente bueno para proteger los secretos nucleares? No. Pero lo suficientemente bueno para su entorno de amenaza.

Averigüe qué tan importante es el control para su aplicación, y determine los controles de compensación que pondrá en práctica para limitar el daño cuando alguien sufra el problema de rasgar y luego imitar su aplicación. No pienses en términos de blanco / negro, posible / imposible; pensar en términos de seguridad aceptable y alcanzable.

Es fundamentalmente imposible validar que una versión no modificada de su cliente se conecta a su servidor.

... a menos que hagas lo que sea necesario para garantizarlo. Esto significa hardware resistente a la manipulación del lado del cliente.

Cuando su código se ejecuta en la computadora del cliente, el propietario de la computadora puede ejecutar un depurador y modificar el código del cliente en cualquier punto con valores arbitrarios. El "depurador" puede ser una máquina virtual en toda regla. Si desea evitar eso, puede intentar participar en un juego de búsqueda y ocultación elaborado en el que puede imaginar sistemas de detección adicionales, y los atacantes los contrarrestan con variantes de sus propias herramientas. Este es el problema de las personas que intentan diseñar soluciones de software anti-trampas (por ejemplo, PunkBuster ); Este es también el problema de las personas que desean vender servicios de video a pedido mientras evitan que los clientes guarden los videos localmente y luego los publiquen en varias plataformas para compartir archivos.

Para resumir, estas protecciones no funcionan bien, incluso cuando los datos a proteger son tan triviales como las vidas extra en algunos juegos.

Para evitar esto, debe hacer que su código se ejecute en hardware protegido, que se defenderá de una inspección profunda de su presunto propietario. Este es el modelo de consolas de juego, terminales de pago y tarjetas inteligentes.

Un TPM es un intento de compromiso: un módulo resistente a la manipulación indebida que funciona dentro de lo que normalmente es una PC; La suposición aquí es que a un usuario normal le resultará demasiado difícil modificar el hardware para, por ejemplo, leer y escribir toda la RAM sin pasar por las piezas que están bajo la supervisión del módulo TPM (por ejemplo, la CPU).

Sin dicho hardware en el lado del cliente, lo que está tratando de hacer no funcionará. A menos que la modificación del código del cliente sea tan inútil que nadie lo intente. Todo depende del valor de lo que está en juego aquí.

Puede probar Ofuscación criptográfica cuando exista

La ofuscación criptográfica es, en ciertos sentidos, que hace que un código fuente de programas sea ilegible. Lo que puede hacer es codificar una clave cyrptographic en el programa. También desearía que el servidor proporcione un valor inicial aleatorio a su programa, ya que no se puede confiar en la computadora. El único problema con este enfoque es la ofuscación criptográfica es que aún no se ha implementado, y también que solo es posible tener ciertos sentidos.

Yo también he abordado un problema como este con la empresa para la que trabajo. Después de semanas de elaborarlo, la respuesta es que no es realmente posible.

Y aquí es por qué:

Básicamente te encuentras con un problema de "Cliente de confianza". El código del cliente se ejecuta en la PC del usuario, y el usuario tiene control total sobre la PC desde la que se origina. El usuario puede cambiar los bytes del programa en el disco, o incluso en la memoria en algunos casos. Si intentara realizar un hash o una suma de comprobación contra el código, él simplemente podría cambiar el código que hizo esa verificación y hacer que se devuelva "sin modificar". Es una táctica de humo y espejos.

Puedes intentar hacer que las cosas sean un poco más difíciles para un usuario malintencionado, pero no hay una forma práctica de lograr lo que esperas. No sin que se convierta en un gran dolor de cabeza.

Puede usar HTTPS junto con la autenticación de certificado de cliente. Entonces puede asegurarse de que solo los clientes con un certificado válido puedan usar su sitio.

El certificado del cliente reemplazará la contraseña que mencionaste y el usuario no notará la magia realizada en segundo plano.

Si desea identificar de forma única al usuario , las claves de API funcionarán bien para usted. Para utilizar API de Facebook , o API API de Stack (etc., etc.), deberá obtener una clave API para identificarse como un usuario particular de la API y enviar esa clave API con cada solicitud. Por lo tanto, cada solicitud que llega a la API puede rastrearse hasta un usuario originario. Esto también permite al propietario de la API controlar quién accede a la API restringiendo a quién se le permite el acceso a una clave de API.

Sin embargo, eso solo identificará de forma única al usuario . No verificará que el usuario esté usando su software original (en lugar de, por ejemplo, un clon escrito desde cero). Verificar que el usuario está usando su software original es prácticamente imposible, ya que se basa en el supuesto de que el usuario no tiene control sobre su propia computadora y no puede, por ejemplo, ejecutar el programa en un depurador y cambiar las instrucciones del software a voluntad. .