Pregunta:
Cómo abordar la sustitución de md5 para transportar datos de juegos de Unity a un servidor remoto
Martin
2017-01-03 03:30:07 UTC
view on stackexchange narkive permalink

Estoy trabajando en un sistema de juegos que usa UnityScript y C # en el cliente y PHP en el servidor. Se utiliza un hash MD5 de los datos más un secreto compartido para verificar que los datos no se hayan modificado en tránsito. ¿MD5 es lo suficientemente bueno para esto? ¿Qué otro algoritmo hash podría usar que funcione en los tres idiomas?

El problema con más detalle

Me he encontrado con un código en un sitio web de la comunidad sobre la popular plataforma de desarrollo de juegos Unity, y ahora estoy trabajando para mejorar MySQL, PHP y la seguridad de ese código.

El código utiliza un valor de "clave secreta" que se comparte entre el cliente y el servidor. Todos los mensajes del cliente incluyen un hash de los datos (por ejemplo, nombre y puntuación) más la clave secreta, que el servidor verifica antes de aceptar los datos. Esto es básicamente una autenticación que los datos pasados ​​no han sido alterados.

Sin embargo, debido a que es MD5, creo que alguien que esté escuchando el tráfico de la red podría encontrar fácilmente la clave secreta y luego publicar los datos que quiero al servidor.

Entonces, mis preguntas son:

  • ¿Esta situación actual justifica una mejora? ¿O es este el uso actual previsto de MD5 (a partir de enero de 2017)?
  • ¿Existe otro algoritmo de hash que podría mejorar / autenticar aún más esta actividad de comunicación? Tenga en cuenta que el algoritmo debería funcionar en PHP, UnityScript y C #.

El código

  • En UnityScript (lado del cliente): 

      var hash = Md5.Md5Sum (nombre + puntuación + clave secreta);

  • En C # (lado del cliente): 

      string hash = MD5Test.Md5Sum (nombre + puntuación + clave secreta);

  • En PHP ( lado del servidor): 

      $ secretKey = "mySecretKey"; // Cambie este valor para que coincida con el valor // almacenado en el javascript del cliente debajo de $ realHash = md5 ($ _ GET ['nombre']. $ _GET ['puntaje']. $ SecretKey); if ($ realHash == $ hash) {
// interactuar con la base de datos}

Más criterios

  • Algunos programadores de Unity use UnityScript (un lenguaje similar a Python con una sintaxis similar a JavaScript en la API .NET) pero no se puede asumir que ninguna biblioteca esté instalada.

  • Los desarrolladores de juegos son no programadores PHP / MySQL tan complejos o el código PHP / C # / Js de terceros probablemente no sería útil.

  • BCrypt es aparentemente imprudente de usar con C #

  • BCrypt necesita una estática salt en este caso (¿quizás derivado de la clave secreta?) pero está destinado a funcionar con una sal aleatoria.

  • PBKDF2 parece preferirse a BCrypt, pero puede ser muy lento, especialmente en dispositivos móviles sin mucha memoria.

  • No se puede esperar lidiar con un servidor seguro (aunque solo sea ...).

  • No sé lo suficiente acerca de la biblioteca de seguridad C # para elegir las mejores opciones de las que se enumeran.

  • Si bien el código descrito tiene que ver simplemente con actualizaciones de puntuación más alta, este código se ha tomado en el pasado, y se usará en el futuro, para transportar todo tipo de datos. , público y privado para varias bases de datos.

  • Tratar con la interoperabilidad del algoritmo hash entre PHP, UnityScript, C # es un obstáculo mayor de lo que había anticipado. Si fuera solo PHP, usaría password_hash.

Algunos pensamientos y antecedentes a esta pregunta:

Actualicé el título porque el título editado parecía sugerir que no estaba seguro de cambiar MD5, mientras que saber que debería cambiar MD5 fue una de las razones principales para preguntar la pregunta aquí en primer lugar.

La pregunta original era que quería actualizar las terribles sugerencias de código que se dan en (entre otros lugares) aquí sobre cómo manejar las interacciones entre un juego en una máquina cliente y el almacenamiento de datos en un servidor remoto. . Ten en cuenta que se trata de sugerencias de código para programadores principiantes en Unity y este sitio [ahora] lo gestionan las propias tecnologías de Unity.
Si miras, la pregunta original (enlazada arriba) estaba usando PHP Mysql_ funciones (así como una forma inválida bastante cutre de PDO). Sentí que esto se beneficiaría de una reescritura. Vi que el código original también había usado una rutina md5 para codificar los datos deseados. En lo que respecta al reemplazo de MD5, no me había dado cuenta de la vulnerabilidad de los archivos de proyecto compilados o del tamaño / escala del trabajo necesario para que este bloque de código sea más seguro (ya sea en la interacción con el servidor o en el lado del cliente datos). Mi búsqueda original era encontrar un reemplazo adecuado para el MD5 que pudiera funcionar en los diferentes lenguajes requeridos (UnityScript, C #, PHP), ya que era consciente de sus deficiencias. No me había dado cuenta (a juzgar por los comentarios aquí) lo tediosamente fácil que es entrar en archivos exe y obtener datos codificados.

Esta pregunta NO se trata de un juego que ' Estoy haciendo, no se trata de Mi proyecto y el código citado que tengo la intención de reemplazar no fue escrito por mí . Leí muchos de los comentarios de que de alguna manera la gente está probando el mensajero, pero esta pregunta surgió de mi propio deseo de mejorar una deficiencia existente en un sitio web de enseñanza wiki. Tengo el mayor respeto por el conocimiento compartido al responder esta pregunta, pero soy consciente de que desde los últimos 6 meses explorando la documentación de Unity y los sitios de aprendizaje, existe una brecha significativa en la seguridad de las aplicaciones locales y el modo multijugador u otras interacciones remotas.

Veo muchos encuestados en los comentarios que afirman que la respuesta dada por George es una mala respuesta, pero responde a la pregunta específica que hice en ese momento. Gracias.

Nota final:
Esta publicación de Blob de los comentarios de Luke Briggs subrayó lo fácil que es un proceso a simple vista para manipular los datos de la aplicación de juegos Unity local. No comprendí en absoluto cómo los archivos locales vulnerables son ...

Los comentarios no son para una discusión extensa;esta conversación se ha [movido al chat] (http://chat.stackexchange.com/rooms/51112/discussion-on-question-by-martin-is-md5-a-good-option-for-verifying-game-puntuaciones).
Ahora, deje de dejar comentarios aquí; déjelos en el chat según sea necesario.Y se eliminará moe aquí.
No está muy claro a partir de la pregunta, pero ¿estás usando Unity?Cabe señalar que Unity ** no es compatible con JavaScript **.Más bien, admite UnityScript _ (un lenguaje derivado de Python con una sintaxis similar a C / JS en .NET) _, que Unity Technologies anuncia falsamente como "JavaScript".Esto hace una diferencia significativa sobre cómo responder a su pregunta porque las bibliotecas estándar de JS _no_ están disponibles en UnityScript.
escribiendo en Unity uso `C #` y conozco los lenguajes "javascript" y "Boo" sólo por referencia, en el contexto de Unity.@SlippD.Thompson
Lo que está implementando es un (H) MAC, es posible que desee ver más información al respecto -> https://en.wikipedia.org/wiki/Hash-based_message_authentication_code En 2011 se aprobó una RFC 6151 informativa para actualizar las consideraciones de seguridad en MD5 y HMAC-MD5.Para HMAC-MD5, la RFC resume que, aunque la seguridad de la función hash MD5 en sí está gravemente comprometida, los "ataques a HMAC-MD5 actualmente conocidos no parecen indicar una vulnerabilidad práctica cuando se utilizan como código de autenticación de mensajes".
Gracias por los comentarios, @GroundZero.Después de publicar esta pregunta, pensé que lo que estaba buscando era un HMAC, pero mi problema era encontrar un algoritmo que se adaptara a todos los lenguajes nessecary.Con las respuestas a esta pregunta, encuentro que el problema más amplio es que tanto los datos como el hash pueden manipularse fácilmente del lado del cliente, por lo que el alcance del problema de seguridad es mucho más amplio de lo que había anticipado originalmente (más amplio de lo que cualquier HMAC puede resolver,Yo creo que).
@Martin el problema con cualquier cosa del lado del cliente es que el cliente casi siempre puede manipular las cosas.Si miras CheatEngine, etc., a menudo trabajan con la manipulación de datos en la RAM, etc., antes de que se realicen las comprobaciones / cifrados / hashes / ... del juego, evitando efectivamente el efecto de tu HMAC.El HMAC lo protegerá de la manipulación de datos mientras esté entre el cliente y su servidor, pero ahora de la manipulación de datos por parte del cliente.Tendría que implementar 'comprobaciones de cordura' del lado del servidor para confirmar que los datos del cliente se ajustan a lo que se espera
Cuatro respuestas:
Polynomial
2017-01-03 04:26:42 UTC
view on stackexchange narkive permalink

Este enfoque es fundamentalmente defectuoso. Cualquier cosa del lado del cliente puede ser manipulada por los jugadores. Es el mismo problema que hace que DRM sea insostenible: el usuario es propietario de la máquina y de todos los datos que contiene, incluidos los ejecutables, los datos en la memoria, etc. Mantener los algoritmos en secreto no funciona (consulte el principio de Kerckhoffs ) porque solo se necesita una pequeña cantidad de trabajo de ingeniería inversa para averiguar qué está haciendo su código.

Por ejemplo, digamos que tiene una rutina en su cliente de juego que publica la puntuación de nivel hasta el servidor, utilizando alguna criptografía de cualquier forma para asegurarse de que no se manipule a través de la red. Hay un montón de formas de evitar esto:

  • Utilice una herramienta de edición de memoria como Cheat Engine para buscar la puntuación actual (pausar, buscar la puntuación, reanudar la pausa, esperar a que la puntuación cambiar, buscar de nuevo, repetir hasta encontrar la dirección de memoria que contiene el valor) y editarlo. Cuando el nivel se complete, el valor de la puntuación será felizmente tratado como legítimo por tu código y subido al servidor.
  • Modifica el ejecutable del juego en el disco para que tu código de "nivel completo" ignore el valor real de la puntuación y elige uno diferente.
  • Modifica el ejecutable del juego en el disco para que cosas simples (por ejemplo, matar a un monstruo) aumente tu puntuación en 1000 veces más de lo que debería.
  • Modifica el ejecutable del juego en el disco para que nunca puedas morir, o tener potenciadores infinitos, o asesinatos de un solo golpe, o cualquier otra cantidad de cosas de ayuda, para que puedas alcanzar fácilmente una puntuación muy alta.
  • Realiza cualquiera de esos modificaciones en la memoria después de que se cargue el juego para que el ejecutable original permanezca intacto (útil para casos en los que hay controles de integridad molestos)
  • Simplemente exponga el código "terminamos un nivel, ahora cargue la puntuación" externamente desde el proceso para que cualquier programa pueda llamarlo. En código nativo, puede inyectar un pequeño código auxiliar y agregar una entrada a la tabla de exportación, o simplemente copiar directamente el código en su propio ejecutable. En .NET es trivial simplemente modificar los indicadores de visibilidad de la clase y el método e importarlos a un nuevo programa. Ahora puede enviar los valores de puntuación que desee sin ni siquiera ejecutar el juego.
  • Realice ingeniería inversa del juego, obtenga la clave "secreta" y escriba su propia aplicación para enviar el valor de puntuación al servidor.

Esto es solo la punta del iceberg. Para juegos más complejos, hay todo tipo de soluciones para los problemas anti-trampa y otros, pero independientemente de los trucos de defensa utilizados, siempre habrá una forma de meterse con los valores del lado del cliente.

La característica crítica de un enfoque seguro es que no se debe confiar en nada en la computadora del reproductor . Cuando el código de su servidor recibe un paquete de un jugador, asuma que su juego puede que ni siquiera se esté ejecutando; podría ser un código totalmente casero que miente sobre todo.

Asegurar los juegos multijugador (o cualquier tipo de juego donde verificar el estado del juego es un requisito) no es fácil. El problema ni siquiera es de seguridad, es de usabilidad y rendimiento. La forma más sencilla de asegurar un juego multijugador es mantener todo el estado del juego en el lado del servidor, hacer que toda la lógica del juego se ejecute y se mantenga allí, y que el cliente no haga nada más que enviar la entrada del jugador al servidor ("el usuario hizo clic con el mouse , el usuario mantiene presionada la tecla W ") y presenta el audio y el video al reproductor. El problema de hacer esto es que no es un juego muy divertido debido a la latencia de la red, y es bastante difícil escalar en el lado del servidor. En cambio, debe encontrar un equilibrio entre mantener las cosas del lado del cliente y del lado del servidor. Por ejemplo, la lógica de "¿el jugador tiene una llave para abrir esta puerta?" debe comprobarse en el lado del servidor, pero la lógica de cuándo mostrar el icono de contexto para "puerta abierta" permanece en el lado del cliente. Nuevamente, cosas como la salud y la posición del enemigo deben mantenerse en el lado del servidor, y la capacidad del jugador para infligir daño a ese enemigo también debe verificarse (¿está lo suficientemente cerca?), Lo que significa que la IA no puede mantenerse en el lado del cliente, pero cosas como la elección de qué animación inactiva está mostrando el enemigo probablemente será una cosa del lado del cliente.

Tenemos algunas preguntas aquí sobre la seguridad del juego, así que sugiero leerlas:

También recomiendo estas preguntas en GameDev SE:

También hay un excelente documento sobre seguridad multijugador de BlackHat EU 2013, y un artículo sobre no autoritativo Redes P2P, que pueden resultar útiles.

Esta es una lectura realmente interesante, no había entendido lo fácil que se puede abusar de las direcciones de memoria para devolver valores editados.Encuentro esto realmente interesante ya que al trabajar con PHP hay innumerables temas al día sobre seguridad y seguridad general de Internet, pero todo el aspecto de la seguridad es algo de un trabajo de años en Unity que encontré ... escaso en el desarrollo de juegos, en tutoriales enenseñanzas, preguntas y respuestas, etc. La gente en general no parece considerarlo, a diferencia de la tecnología de material web, parece ser un tema candente constante (¿y mejor por eso?).Salud
Es una simple cuestión de economía.Hasta hace poco, no se podía ganar mucho dinero haciendo trampas en los juegos.O, para verlo desde el otro lado: no había mucho dinero que perder al ser estafado, así que ¿por qué molestarse en gastar dinero para evitar las trampas?No ocurre lo mismo con la web, desde que el comercio electrónico y luego la banca electrónica se convirtieron en algo.
@JörgWMittag Ni siquiera es eso.En general, la gente está más familiarizada con cómo hacer trampa en los juegos multijugador en estos días, y las herramientas disponibles facilitan las cosas.El aspecto de la economía financiera sigue siendo importante en algunas áreas (particularmente en los bots MMO), pero más que nada es la barrera de entrada la que se redujo.En estos días, puede crear un entrenador de juegos independiente que realice parches de código y edición de memoria sin tener que escribir una sola línea de código usted mismo, o incluso comprender realmente los conceptos subyacentes de lo que está haciendo.
Diablos, los juegos solían incluir códigos de trucos, por lo que no era necesario explotarlos.No fue hasta que la gente compitió en Internet que a nadie le importó evitar las trampas.
Estaba a punto de publicar un comentario en la respuesta, pero afortunadamente verifiqué otras respuestas.ESTA es la respuesta que debe marcarse como la correcta.La única forma de asegurarse de que el jugador no ha hecho trampa es que el juego envíe la secuencia de entrada al servidor y el servidor la vuelva a reproducir; se hace de esta manera en DROD, la demostración consiste en movimientos del jugador, la demostración se envía al servidorcomo una puntuación y solo cuando Spider lo reproduce y confirma que el estado final es exactamente el mismo, se marca como una puntuación válida.
`Cuando el código de su servidor recibe un paquete de un jugador, asuma que su juego puede que ni siquiera se esté ejecutando, podría ser un código totalmente casero que miente sobre todo. Muy cierto.Cuando teníamos Internet dial-up, llamábamos al número a mano y hacíamos ruidos de módem (la versión geek del beatboxing, supongo).Si bien no sabíamos qué estaba pasando, por lo general agregamos varios segundos al tiempo antes de que el lado remoto colgara.Siempre me pregunté si alguien podría pasar el tiempo suficiente para poder jugar un juego de forma remota o algo así, solo con su voz.
Hacerlo del lado del servidor en realidad no es tan poco práctico, con algunas modificaciones.En lugar de mantener el estado _completamente_ del lado del servidor, solo mantiene algunos estados relevantes del lado del servidor y realiza comprobaciones básicas de cordura en las actualizaciones ("ticks") del cliente.Por ejemplo, mantener la posición de los jugadores en el servidor y realizar comprobaciones para asegurarse de que ningún jugador se haya movido más rápido de lo posible o de formas imposibles, o se haya movido a través de límites como muros o escudos.Eso no evita las trampas triviales, pero rompe todas las trampas de la "salud infinita".
Después de todo, si el cliente informa que un jugador tiene el mismo HP incluso después de que un proyectil cruzó su hitbox, debe estar mintiendo.No es necesario hacer todos los cálculos complejos necesarios para ver exactamente cuánto daño se hace (teniendo en cuenta los disparos a la cabeza, las mejoras de daño, el tipo de arma, etc.), solo controles básicos de cordura.Esta es la técnica utilizada por varios juegos en línea para limitar la habilidad de un tramposo para que solo pueda obtener una ventaja moderada (bots de puntería limitados, mejores armas, ver a través de las paredes) en lugar de crear un modo dios (munición infinita o salud, uno-golpear tiros muertos, elementos infinitos).
Nathaniel J. Smith
2017-01-03 06:56:42 UTC
view on stackexchange narkive permalink

Aquí hay tres problemas:

  • Lo que está tratando de hacer está fundamentalmente equivocado de varias maneras, como se describe en la respuesta de Polynomial.

  • Si insiste en hacerlo de todos modos, ¡ni siquiera está utilizando la primitiva correcta! La autenticación de mensajes requiere una MAC, no un hash. Es posible construir una MAC a partir de un hash, esto es lo que hace HMAC, pero no es tan trivial como parece. Lo que está haciendo el código que pegó es intentar construir ingenuamente un MAC a partir de un hash, y este tipo de construcciones ingenuas generalmente se rompen.

  • También sí, MD5 es un mal hash función. Pero esta es realmente la menor de tus preocupaciones ... MD5 no es el punto débil de este diseño. Está pidiendo consejo sobre cómo reemplazar las rejas sobre las ventanas con placas de acero de 2 pulgadas de espesor, pero la puerta de entrada está abierta de par en par. Justificar esto como una "mejor seguridad" no tiene sentido.

Bryan Field
2017-01-03 04:24:32 UTC
view on stackexchange narkive permalink

Editar: Para aclarar, no puedo hablar de la seguridad de su enfoque, solo de la parte hash. Aquí hay algunos comentarios fuertes que desalientan su enfoque. (es decir, un buen hash puede ser parte de un enfoque seguro o inseguro, al igual que una buena cerradura se puede usar en una buena puerta / marco o en una puerta / marco endeble)

En respuesta a su TL; DR Puedo decir con bastante seguridad que SHA-2 es la función hash de reemplazo recomendada.

Si la longitud es un problema, es mejor usar un SHA-2 truncado que MD5.

SHA-2 viene en 4 tamaños: 224, 256, 384 o 512; siendo 256 y 512 los más comunes.

Tenga en cuenta que este es un hash de uso general (rápido) y no es adecuado para el almacenamiento de contraseñas, sin embargo, es adecuado para garantizar la integridad de los datos como su TL; DR sugiere.

BCrypt es un Hash de contraseña lento y se usa si necesita una especie de cifrado unidireccional. (es decir, la contraseña nunca se almacena, solo su hash, y es difícil de usar la fuerza bruta)

Gracias por su respuesta.Examinaré SHA-2, supongo que * lo recomendaría * como reemplazo de Md5.
Si bien esto es cierto, vale la pena señalar la advertencia de que ninguna de estas son opciones de autenticación sensatas en comparación con los esquemas adecuados de [SRP] (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol), y no ayudarán con los esquemas realesproblema al que se enfrenta OP (usuarios falsificando valores).
La familia @Martin SHA2 sería el reemplazo ideal para MD5 en casi cualquier caso en que se encuentre con MD5.Eso no cambia el hecho de que su enfoque no funciona, y cambiar el hash no mejora la seguridad, pero MD5 está en desuso y los hash de la familia SHA2 son de hecho el reemplazo recomendado para la mayoría de los casos de uso, sin incluir el hash de contraseñas.
Si bien Polynomial ha dado algunos consejos / críticas muy valiosos y de amplio alcance, George proporcionó la respuesta que estaba buscando.Gracias a los dos.
@Martin Como desarrollador de Unity que vende en la Asset Store, espero sinceramente que no use esta respuesta.Escuche Polynomial.Muchos desarrolladores de Unity * sí * entienden cómo funcionan las trampas;su esquema es ** completamente defectuoso **: enseñarlo / venderlo a otras personas difundirá información errónea.
@Martin para su referencia, acabo de reunir dos imágenes simples.Vea [esto] (http://i.imgur.com/fHKuMOE.png) y también [esto] (http://i.imgur.com/mL48jgO.png).Los juegos son diferentes de la web porque es el cliente el que intenta explotar su sistema (para hacer trampa).A diferencia de la web, donde normalmente es un tercero que intenta explotar el * cliente * (para robarle).
Si bien estoy de acuerdo en que la respuesta Polynomial a continuación sería mejor, probablemente sea mejor usar HMAC (para obtener más detalles, consulte la [sección de seguridad de la página de Wikipedia] (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security)).
Siento que tengo que rechazar esto sobre la base de que está completamente fuera de tema.El hash se realiza en el lado del cliente, por lo que es absolutamente trivial para cualquier persona con habilidad técnica modificar los valores que están hash.La "clave secreta" no puede mantenerse secreta porque se le da al cliente.Todo el asunto del hash en la publicación es bastante absurdo.La respuesta de @Polynomial's ilustra mucho mejor cómo el OP está abordando el problema de una manera muy defectuosa y que el hash aquí simplemente no tiene sentido.Como no tiene sentido, no hay razón para elaborarlo.
¿Debería borrar mi respuesta?jajaja
Recomiendo encarecidamente que marque para que un moderador lo elimine.(No puede eliminarlo usted mismo, ya que está aceptado).
@Kat la respuesta responde a mi requisito específico de algo que reemplaza a MD5, para el hash en el lado del cliente.De todos los comentarios y excelentes respuestas a esta pregunta, ahora me doy cuenta de que idealmente todo el enfoque necesitaría un replanteamiento completo, y lo dije en comentarios más arriba, pero como dije, si bien Polynomial de hecho da una respuesta más completa y amplia,La respuesta de George cubrió lo que estaba * originalmente * buscando.
@Martin He reunido [una publicación de blog] (https://futrworld.blogspot.co.uk/2017/01/breaking-verified-game-scores-in-unity.html) que muestra lo fácil que es este tipo deLa técnica es romper, independientemente de la función hash utilizada.También hay archivos de proyecto para que se pueda seguir.
@LukeBriggs eso es realmente interesante para mí, gracias por pasar por eso.Nunca me había dado cuenta de lo fácil / simple que es abrir datos de [juegos] como este.He agregado un enlace a este blog en el pie de página de la pregunta.
"Si la longitud es un problema, es mejor utilizar un SHA-2 truncado que un MD5".No podría recomendar más en contra de este enfoque.Esto aumenta las posibilidades de colusión, ya que varios hash podrían compartir el contenido del hash truncado.Por ejemplo, si estuviera utilizando este método para las contraseñas, pasará de una posible coincidencia a miles de contraseñas que podrían acceder a esa cuenta.Lo mismo se aplica a los activos.
@baconface, Collision es [no es un problema práctico en 128 bits] (https://www.google.com/search?q=how+many+millennia+in+2^128+nanoseconds%3F), aunque es mejor no hacerlotruncar.
"Si la longitud es un problema, es mejor utilizar un SHA-2 truncado que un MD5".Si bien truncar cualquier tipo de hash de hecho aumenta el riesgo de colisión, creo que a lo que esta declaración estaba tratando de llegar es al hecho de que si, por alguna razón, solo puede transmitir 128 bits, un hash SHA-256 truncado a128 bits sigue siendo mucho más seguro que un hash MD5.
Sin embargo, en esta situación, MD5 está perfectamente bien.Todo lo que Polynomial dijo a continuación es cierto;cualquier cosa en el cliente puede ser atacada.Sin embargo, en esta situación, la seguridad por oscuridad es realmente su única opción, al menos hace que sea un poco más difícil para los niños de script manipular sus puntuaciones más altas.Si bien MD5 no es un pollo de primavera, todavía está lejos de ser reversible: aún necesitaría un ataque de fuerza bruta.En este caso, su implementación de seguridad por oscuridad se romperá mucho antes que la propia criptografía (MD5).
Si bien truncar SHA-1 a 128 bits puede aumentar la oscuridad del hash en el tráfico olfateado, incluso iría tan lejos como para decir que sería mejor que implementara su propio algoritmo criptográfico no tan inteligente basado en XOR enesta situación, con la esperanza de que dificulte la ingeniería inversa de su código.(No pierda el tiempo en esto, su algoritmo / será / se romperá eventualmente). Además, yo diría que su enlace sobre la implementación de C # bcrypt sin verificar no importa aquí por las mismas razones, no importaqué tan fuerte y probada es su cerradura cuando hay un agujero gigante en la pared justo al lado de la puerta.
@GeorgeBailey I tihnk, al menos deberías agregar el hecho de que el hasing debe realizarse en el lado del servidor, un lado del cliente de BCrypt es menos seguro que un lado del servidor de Caesar :)
Luc
2017-01-03 21:16:26 UTC
view on stackexchange narkive permalink

Un amigo mío hizo una vez un juego flash (sí, hace tanto tiempo) y usó el mismo esquema: md5 (datos autenticados + clave secreta) , luego valídelo en el servidor.

Hice ingeniería inversa con alguna herramienta y encontré el valor secreto que estaba usando en unos 30 minutos. Se acabó el juego.

Pero sí, es la segunda mejor opción posible. Independientemente de usar sha2 en lugar de md5 e independientemente de usar hmac en lugar de un algoritmo hash, nunca se debe confiar en la entrada del usuario. Si los usuarios ejecutan su juego en su máquina (es decir, está bajo su control) y pueden enviar una puntuación alta, siempre podrán utilizar herramientas para mejorar las puntuaciones.

Lo mejor que puede hacer es cargar una repetición (por ejemplo, pulsaciones de teclas grabadas) y volver a ejecutarla en el servidor, luego validar el tiempo resultante. Es mucho trabajo codificar, requiere más recursos del servidor y necesitará tener física determinista si usa flotadores en cualquier lugar ... pero eso es lo único mejor que lo que está haciendo, y la gente aún puede escribir el script juego si quieren hacer trampa.

Para los juegos por turnos que permiten jugadas repetidas con la misma semilla, y que son lo suficientemente complicados como para que desarrollar un algoritmo para encontrar buenas soluciones sea en sí mismo un logro, creo que uno podría hacer que el concepto de "trampa" sea discutible.Sin embargo, para los juegos de acción, no habría una forma práctica de determinar si alguien realmente jugó el juego en tiempo real.


ⓘ
Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...