Pregunta:
¿Debería preocuparme por los ataques de tiempo remoto en la comparación de cadenas?
George Powell
2016-01-18 23:29:24 UTC
view on stackexchange narkive permalink

Digamos que tenemos una aplicación web Java que usa un secreto compartido para verificar la identidad del cliente. El secreto se almacena en el servidor y el cliente transmite el secreto a través de SSL donde se verifica:

  String SECRET_ON_SERVER = "SomeLongRandomValue"; if (secretFromClient.equals (SECRET_ON_SERVER)) {// solicitud verificada - el cliente conoce el secreto} else {// solicitud no verificada - generar respuesta fallida}  

String.equals (String) devuelve tan pronto como un el personaje no coincide. Esto significa que un atacante, si puede rastrear con precisión el tiempo que tarda en responder, debería saber en teoría cuántos caracteres de su intento ( secretFromClient ) coinciden con el secreto del servidor, lo que lleva a un ataque de fuerza bruta plausible.

Pero la diferencia en los tiempos parece ser minúscula . Una investigación rápida sugiere que las diferencias están fácilmente en el rango de menos de milisegundos.

  • ¿Puedo ignorar con seguridad este tipo de ataques de tiempo debido a su insignificancia en comparación con el ruido de la red?
  • ¿Hay ejemplos de ataques de tiempo exitosos de < 1ms en Internet?
Antes de hacer esta comparación, obtenga la hora actual, agregue una constante y guarde el resultado en una variable. Después de la comparación, reste la nueva hora actual de ese valor guardado y duerma durante el intervalo resultante. Por lo tanto, todas las invocaciones de esta rutina siempre tomarán la misma cantidad de tiempo.
Para empezar una línea de comentarios: lo que influye en si tales ataques serán posibles no es el tiempo de ida y vuelta, sino la cantidad de * variación * en los tiempos de ida y vuelta. Si el tiempo de ida y vuelta es siempre de 800 ms más o menos 10 nanosegundos, un ataque de tiempo es trivial. Si el tiempo de ida y vuelta es 800 ms +/- 100 ms, un ataque de tiempo es más difícil. Tenga en cuenta, sin embargo, que existen técnicas en la literatura para tratar incluso una cantidad de variación no trivial, promediando el ruido o repitiendo la consulta varias veces y tomando el mínimo; estos pueden ser más efectivos de lo que cabría esperar.
Sí, puede ignorar con seguridad * este * ataque de tiempo debido a la complejidad y el interminismo de las muchas capas involucradas. Red física, implementaciones de protocolos de red con varios búferes, controladores de protocolos de aplicación, etc. Los datos se barajan tanto entre el remitente y su aplicación Java que este tiempo no es factible de explotar.
Ocho respuestas:
#1
+33
sethmlarson
2016-01-18 23:41:26 UTC
view on stackexchange narkive permalink

Se han publicado éxitos con ataques de sincronización remota. Del documento: "... podemos distinguir de manera confiable diferencias de sincronización remota tan bajas como 20 µs". Entonces sí , debería preocuparse por la implementación subyacente de .equals () (spoiler: no seguro). Implemente .equals () usando una suma de XOR de caracteres para comparar de forma independiente del tiempo.

Aquí hay una implementación de Python como ejemplo de una comparación de bytes independiente del tiempo.

  def es igual a (bytes1, bytes2): si len (bytes1)! = len (bytes2): devuelve False else: diferencias = 0 para a, b en zip (bytes1, bytes2): diferencias | = a ^ b devuelve diferencias == 0  
No sé mucho sobre seguridad, pero ¿no podrías averiguar la longitud de la contraseña con esto? Si la respuesta tarda un poco más que una contraseña más corta / más larga, entonces sabe que tiene la longitud correcta, lo que puede reducir significativamente los diferentes casos de prueba a la fuerza bruta.
@SirPython Su contraseña debe ser lo suficientemente larga (y lo suficientemente compleja) como para que no pueda ser forzada incluso si conoce la longitud.
@SirPython Security rara vez oculta la longitud de la carga útil porque los mensajes deben enviarse a través de redes que se tratan como no confiables. Debido a que la información debe enviarse a través de alguna red, la criptografía moderna rara vez se trata de ocultar la longitud del mensaje, sino más bien el contenido real del mensaje.
Pero [esta respuesta] (http://security.stackexchange.com/a/92238/52798) dice que conocer la longitud de la contraseña puede ayudarlo a descifrar una contraseña más fácilmente.
@SirPython Una vez que el espacio posible es lo suficientemente grande para una contraseña, incluso sabiendo la longitud exacta de la contraseña no se dará suficiente información al atacante para forzarla. Saber que una contraseña tiene 32 bytes de longitud en lugar de cualquier valor menor a 32 significa que todavía hay 2 ^ 128 posibles contraseñas, que es aún más de lo que nadie podría usar sin información adicional sobre la contraseña.
@SirPython: Revelar la longitud elimina un máximo de opciones `1 / (caracteres permitidos en la contraseña)` del número total de opciones, donde `caracteres permitidos` es 10 para contraseñas numéricas, 62 para caracteres alfanuméricos que distinguen entre mayúsculas y minúsculas y más si permite símbolos .
@SirPython sí, pero normalmente * no * compararías las contraseñas sino sus hashes (ya que ¿por qué almacenarías una copia de texto plano de la contraseña en cualquier lugar?), Y los hashes tendrían la misma longitud predeterminada sin importar si la contraseña tiene 6 o 60 caracteres.
@Peteris Esto es cierto para las contraseñas, pero estaba usando la frase "contraseña" como lo mismo que cualquier texto que desea que sea secreto para todos excepto para usted y un par. Suponiendo que el par usa este texto en forma de texto sin formato, hash no es factible. Pero sí, las contraseñas siempre deben tener un hash antes de compararlas con un hash almacenado.
Esa es una gran referencia. Una lectura fascinante y aterradora me obligó a cambiar mi propia respuesta a mitad de la escritura de "jaja, por supuesto que no" a "wow, sí, un riesgo totalmente factible". Y ahora tengo que ir a comprobar que mi propio código no es vulnerable a ese tipo de cosas ...
Ser capaz de distinguir 20 µs de diferencia horaria no ayudará a un atacante que intente comparar el tiempo de un secreto. Calculé las comparaciones de cadenas en Python en una computadora moderna, y es capaz de comparar 100000 caracteres dentro de ese tiempo. Teniendo en cuenta que es probable que el secreto a comparar tenga menos de 100 caracteres, significa que el ataque debe mejorarse en 3 órdenes de magnitud para incluso distinguir la diferencia entre una falta de coincidencia en el primer carácter y una falta de coincidencia en el último carácter.
@kasperd Exactamente eso: si su servidor tarda 20 µs para comparar dos caracteres, felicidades, ¡logró instalar Java en Arduino con una frecuencia de inactividad! Pero "ataque de tiempo" suena un poco genial y aterrador, por lo que la gente votará a favor, ignorando por completo órdenes de magnitud.
@dmitrygrigoryev Estos no son un tipo de ataque de ejecución única, se necesitan muchas pruebas antes de que surja alguna significación estadística. Obtener una gran cantidad de datos siempre mostrará tendencias y esas tendencias que surgen a medida que el conjunto de datos aumenta es el problema que nos preocupa, no si una sola ejecución de la comparación es igual o no a otra ejecución.
@Oasiscircle Eso ya lo sé. ¿Cual es tu punto? La mía es que no se puede mejorar la precisión infinitamente aumentando el tamaño del conjunto, y 20 µs es lo mejor.
+1 para `XOR` (muy útil contra ataques de tiempo) y comprobación de doble longitud.
@DmitryGrigoryev Ese es probablemente un buen límite inferior por ahora, pero a medida que la brecha entre la velocidad de la red y la velocidad del procesador se vuelve más estrecha debido a las restricciones cuánticas en los tamaños de hardware, yo diría que el número de 20 microsegundos solo se reducirá con el tiempo.
#2
+25
Damon
2016-01-19 20:36:36 UTC
view on stackexchange narkive permalink

En teoría, esto es un posible exploit, y si estás en modo superparanoia, debes asumir que la respuesta es "Sí". En cualquier otro caso, la respuesta será: "No." 0000-.

Aunque hay artículos publicados (uno está vinculado en la respuesta por @Oasiscircle) que afirman que son capaz de ejecutar ataques de tiempo exitosos, también hay que leer cuidadosamente las condiciones previas. Estos ataques "prácticos" publicados funcionan en algunos algoritmos en una LAN con uno, como máximo dos , cambia entre. Lo que implica un tiempo de ida y vuelta constante y casi perfectamente fiable. Para ese escenario, es realmente práctico atacar ciertos algoritmos a través del tiempo, pero esto no tiene sentido en el contexto de la pregunta.
De hecho, considero estos ataques remotos como "trampas" . El hecho de que un ataque sea remoto es irrelevante si diseña cuidadosamente el experimento para que el retraso sea, sin embargo, casi exactamente predecible.

Al atacar cualquier servidor en Internet, esta condición previa no hold (ni siquiera remotamente, juego de palabras ), incluso en un servidor que está geográfica y topológicamente cerca.

Además, atacar una comparación de cadenas a través del tiempo no es en absoluto lo mismo que atacar un cálculo RSA. Es mucho más difícil porque toda la operación, así como la diferencia medible, es mucho más pequeña.

Una comparación de cadenas de una contraseña (asumiendo que sus contraseñas tienen un tamaño "razonable") toma unos cientos de ciclos o menos , de los cuales la posible falla inicial de caché / TLB es, con mucho, el factor dominante más grande, seguido por la rama de predicción errónea del terminal (que ocurre tanto para una coincidencia como para una no coincidencia). La diferencia entre una coincidencia y una no coincidencia es quizás una o dos docenas de nanosegundos.

Un cambio de contexto tarda varios cientos de nanosegundos, al igual que una pérdida de caché. Los programadores generalmente operan a una resolución de micro o milisegundos y realizan un trabajo muy no trivial (en cientos / miles de nanosegundos) en momentos intermedios que son difíciles de predecir, por decir lo menos.

Medición confiable diferencias en la escala de nanosegundos en absoluto tampoco es del todo trivial. Los temporizadores programables ordinarios no tienen la resolución requerida. Se garantiza que HPET en hardware básico ofrece una resolución de 100 ns (por especificación) y, en la práctica, se reduce a 1 ns en muchas implementaciones. Sin embargo, funciona generando una interrupción . Esto significa que puede programar un temporizador para algún punto en el tiempo con una precisión de nanosegundos, pero realmente no puede usarlo para medir nanosegundos individuales. Además, la interrupción agrega una sobrecarga e incertidumbre de una docena de nanosegundos (... a algunas docenas de nanosegundos que desea medir). Los contadores de ciclos deben serializarse para ser precisos. Lo cual, también, los vuelve bastante inútiles para medir con precisión un evento externo a una resolución de nanosegundos, ya que su precisión depende de cómo se vea la tubería.
Hay más cosas a considerar que agregan ruido impredecible, como los usuarios legítimos (sí, esos ¡existen también!) e interrumpen la fusión.

Intentando adivinar algo-nano de muestras que incluyen varios algo-diferente-nano así como em> algo-micro y varios algo-mili es una tarea hercúlea. Eso es ruido de varias fuentes independientes en todas las escalas.

Por último, considere la mención de "Java", lo que significa que, por ejemplo, un recolector de basura puede estar ejecutándose en un momento impredecible (en cualquier caso, impredecible para un atacante remoto), causando un jitter impredecible en una escala desconocida (¿micro, mili?).

En teoría, por supuesto, podría recopilar una gran cantidad de muestras, incluso a una resolución más baja, digamos una escala de microsegundos, y eliminar estadísticamente las diversas fuentes de ruido. Nunca podrá saber con absoluta certeza si una contraseña es correcta, pero eventualmente podrá saberlo con una probabilidad suficientemente alta (digamos 85% o 90%, o incluso 99%), y luego podrá verificarlos manualmente pocos candidatos. ¡Eso es bastante bueno!

Esto es posible , al menos en teoría, pero se necesitarían una enorme cantidad de muestras incluso para adivinar una sola contraseña. Y decir "enorme" es realmente un eufemismo de proporciones galácticas. La cantidad de muestras necesarias prácticamente implica que debe paralelizar el ataque, o tomará una eternidad.

Ahora, paralelizar tal ataque de sincronización en un grado serio no es fácilmente posible porque está sujeto al efecto del observador (en el mismo sentido que en la mecánica cuántica).
Hacer un par de sondas (tal vez 5-8) en paralelo debería funcionar, suponiendo que el servidor tiene suficientes núcleos inactivos, pero a medida que aumenta la escala, eventualmente una sonda inevitablemente afectar el resultado de otra investigación de una manera impredecible y desproporcionada. No hay nada que pueda hacer para evitar que eso suceda, por lo que la paralelización no funciona realmente bien (ni siquiera estoy tomando en cuenta el hecho de que las interrupciones generalmente pasan por un solo núcleo y que solo hay un solo cable de cobre físico cuyos datos debe pasar, por lo que incluso si el servidor todavía tiene núcleos inactivos restantes, puede muy posiblemente ser el caso de que una sonda afecte a otra).

Por otro lado, ejecutar un El ataque no masivamente paralelo está destinado a fallar porque morirá de vejez antes de encontrar una sola contraseña.

Si bien estoy de acuerdo en que probablemente no sea la ruta de ataque preferida por un atacante, la simplicidad de evitar cualquier posibilidad de ataque vale el riesgo mitigado.
Vaya, esta respuesta es peligrosa y catastróficamente incorrecta.Los ataques de tiempo de comparación de cadenas remotas son prácticos y se han realizado varias veces en la práctica en sistemas del mundo real.Véase, por ejemplo, la charla ekoparty de Paul McMillan, "Prácticos ataques de tiempo de comparación de cadenas" https://vimeo.com/112575034.HPET no importa (los atacantes pueden comprar una tarjeta de red con soporte de marca de tiempo de nanosegundos);GC no importa (simplemente tome más medidas --- y los intentos de dónde se ejecutó el GC podrían ser fáciles de detectar porque el tiempo estará demasiado lejos);y los ataques no tienen por qué suceder en paralelo.
@dlitz: McMillan demuestra un ataque a un microcontrolador lento de potencia ultrabaja conectado a la NIC mediante un cable cruzado de 0,5 m de largo.Eso es algo ridículo para ser tomado en serio en el contexto de "Internet" o "servidor".Seriamente.No hay "red", ni jitter, ni programación, ni RAM, ni cachés, nada de ese tipo.Además, las comparaciones de cadenas son muy, muy, muy lentas en comparación con un servidor.Claro, puede construir un caso artificial donde tal ataque sea posible, en su escritorio.¿Pero a quién le importa, prácticamente?
#3
+14
Ben
2016-01-19 00:26:25 UTC
view on stackexchange narkive permalink

Almacene un buen hash criptográfico del secreto en el servidor (es decir, trátelo como una contraseña). Entonces, su comparación sería tomar el hash de la cadena que el cliente le envía y comparar los hash.

Si el secreto tiene una entropía lo suficientemente alta, esto debería eliminar los ataques de tiempo y evitar la filtración de la cadena secreta real, ya que debería ser prácticamente imposible recuperar el secreto del hash.

Por otro lado, si la cantidad de entropía en el secreto no es suficiente para evitar ataques de diccionario, esto solo no es suficiente. Una comparación de salida temprana todavía puede permitir que el atacante aprenda los primeros bytes del hash; luego, un ataque de diccionario posterior podría recuperar el secreto de su hash. (Consulte también Ataques de tiempo a hashes de contraseñas para obtener más información sobre la posibilidad de tales ataques de tiempo). Esto se puede evitar comparando los dos hashes mediante un método de comparación de tiempo constante.

Entonces, la solución más sólida sería almacenar un hash del secreto, hash de la cadena que el cliente le envía y comparar los dos hashes usando un método de comparación seguro de tiempo constante. Usar un hachís salado tampoco estaría de más.

Esto no es necesariamente cierto, complica el proceso pero no alivia por completo el problema. Esto aún puede filtrar partes del hash utilizando la comparación de bytes de salida anticipada. Ejemplo: el atacante calcula toneladas de hashes y los almacena buscando un hash que comience con 0x00. Al encontrar un texto sin formato con ese valor, envíe ese texto sin formato, escuche el tiempo de respuesta. Haga esto para 255 valores más hasta que un valor tarde un poco más. Ese es el primer valor de byte del hash creado a partir del texto sin formato. Obviamente, se filtra menos información, pero se debe evitar la filtración de información.
De [esta respuesta] (http://security.stackexchange.com/a/9193/93625), creo que estaría seguro con solo el hash (pero probablemente no hay ningún daño en ser paranoico y usar la comparación de tiempo constante como sugeriste).
#4
+5
Dewi Morgan
2016-01-19 02:22:04 UTC
view on stackexchange narkive permalink

La respuesta de @ Ben para comparar hashes en lugar de claves directamente parece el enfoque de mejor práctica para la tarea , y de paso también se convierte en una solución parcial al problema .

Sin embargo, sigue siendo vulnerable a algún nivel de árbol de hash con tablas de arcoíris: pruebe las claves que resulten en un hash que comience con cada letra, luego las que comiencen con la letra encontrada y la segunda en ciclo, y así sucesivamente. La sal y la pimienta ayudarían de alguna manera a abordar esto, tal vez, pero si se trata de un problema de tiempo, entonces una mejor solución al problema sería prevenir por completo el ataque de tiempo, durmiendo después de la comparación hasta el próximo múltiplo de 100 ms (o lo que sea el tiempo es claramente mayor de lo que puede ser strcmp).

Sin embargo, para responder la pregunta , necesitamos calcular qué tan grande es el riesgo.

En una máquina de 1 GHz, un ciclo de reloj es un nanosegundo. Un solo carácter de una comparación de cadenas debe estar en ese orden, al igual que cualquier caché de CPU que llegue (~ 1ns para L1 a ~ 30ns para L3). Según tengo entendido, la mayoría de las funciones de comparación de cadenas no obtienen letras de la memoria una por una, sino que las obtienen en el tamaño de bloque de compensación más eficiente. Incluso si lo hicieran, una falla de caché que requiera acceso a DRAM seguirá siendo, en el peor de los casos, solo alrededor de 100 ns / carácter.

@Oasiscircle enlaza a un artículo, citando su tiempo WAN de 20us.

Sin embargo, es trivial establecer dónde está alojada una máquina. Alguien que alquile una máquina en el mismo NOC o granja de servidores, sabrá la configuración exacta de su hardware y quizás solo tenga uno o dos conmutadores entre ustedes. Si alquilan dos servidores, incluso pueden configurar un sistema de prueba para probar los tiempos de medición a través de ese NOC para obtener los resultados lo más cerca posible.

Entonces, quizás lo más interesante de ese artículo sea su sincronización LAN de 100 ns con 2000 mediciones con una tasa de error del 5% de < (o 200 ns con 1000 mediciones: más mediciones darían una resolución aún mejor). No describieron el hardware de su red, pero es posible que si hay tarjetas gigabit tanto en las máquinas de ataque como en las de destino, podrían obtener una resolución aún mejor.

En ese momento, un atacante podría distingue la longitud en algún lugar entre los 1 a 100 caracteres más cercanos (dependiendo de qué tan bien vayan sus aciertos de caché, cuántas pruebas ejecuten, la velocidad de su red y una gran cantidad de puntos finos de hardware).

Dado que Debe asumirse que hay ataques que garantizarían fallos de caché, que pueden ejecutar un número arbitrario de pruebas, que seleccionarán el hardware más adecuado para atacar el suyo y que la resolución de su ataque solo mejorará a lo largo de la vida. de su aplicación y servidor ... eso les da efectivamente 1 carácter de resolución y, por lo tanto, su clave completa.

Entonces, si es probable que su sistema tenga atacantes técnicamente avanzados dispuestos a gastar dinero en apuntar específicamente a su máquina , entonces este es un riesgo claro, ya que h tenga una certeza cercana de éxito con este enfoque.

De la misma manera, si alquila espacio en un NOC, incluso los ataques desde vehículos de otros ocupantes del NOC son un riesgo, al menos si esta comparación se realiza utilizando un protocolo que un ataque drive-by podría descubrir.

Respuesta corta: sí, es un riesgo; evitar que el tiempo de la operación se vea afectado por el strcmp es trivial; mejor hacerlo.

Solo quería aclarar que mi cita es detectable a 20 ** microsegundos **, no a 20 milisegundos. µs = micro
#5
+3
Filip Haglund
2016-01-20 03:07:53 UTC
view on stackexchange narkive permalink

No se trata de la practicidad del ataque, se trata del hábito de hacer las cosas de forma segura. Es muy común que aparezcan errores porque alguien pensó en escapar de esa cadena o no, porque "son solo números, así que puedo ignorar la validación". Entonces alguien descubre cómo explotar eso.

Usar una comparación de cadenas criptográficamente segura es tan fácil y económico que no hay razón para pensar en cuándo realmente lo necesita y cuándo no. Siempre que se trate de contraseñas, tokens de autenticación o similares, utilice un algoritmo de comparación de cadenas de tiempo constante.

  if a.length! = b.length return falsex = 0for i = 0; i < a.length; i ++ {x | = a [i] ^ b [i]} return x == 0  
solo por curiosidad: ¿los compiladores son lo suficientemente inteligentes / alguna vez lo serán para salir temprano del ciclo cuando x == 256?Sé que la seguridad a menudo está en guerra con los optimizadores.
@dn3s para salir temprano del bucle requiere verificar esa condición en cada iteración, lo que significa que es mucho más difícil optimizar / vectorizar el bucle.Probablemente será notablemente más rápido recorrer todo el bucle que salir temprano, debido a la predicción y vectorización de ramas.Además, supongo que mencionaste `x = 255` :)
#6
+2
Jason Higgins
2016-01-18 23:42:19 UTC
view on stackexchange narkive permalink

¿Hay ejemplos de ataques de tiempo de 1ms exitosos de < a través de Internet?

Lo que quizás quieras pensar es si alguien estaba intentando descubre el secreto internamente. La sincronización podría juzgarse en un nivel más preciso desde una perspectiva interna. Si está preocupado por tal situación, ¿por qué no cambiar la función para evaluar todos los caracteres enviados en lugar de salir en el primero incorrecto? De esa forma, el tiempo será uniforme.

Sería útil tener una referencia que diga que es insignificante. Ya hay una gran cantidad de estudios publicados sobre cómo no es insignificante.
Gracias por vincular un estudio. Eliminaré esa parte de mi respuesta.
#7
+2
Steve Sether
2016-01-19 20:59:08 UTC
view on stackexchange narkive permalink

Estás haciendo la pregunta incorrecta. La preocupación es una emoción, y las emociones deben alertar a nuestra mente sobre las amenazas, pero una vez alertados, debemos pensar más profundamente sobre cuál es la amenaza. A menudo es útil medir un riesgo en comparación con otros riesgos. Los ataques de tiempo en el método de iguales son reales y potencialmente explotables, pero es posible que tenga amenazas mucho mayores con las que lidiar. Entonces la pregunta es cuál debería ser su respuesta a esto. Depende en gran medida de su contexto.

Si lee la letanía de respuestas aquí, verá una enorme cantidad de cálculos, suposiciones y factores atenuantes. El resultado final es que este no es un exploit muy fácil de lograr.

En última instancia, la seguridad se trata de equilibrar el riesgo y el costo. Nunca tenemos recursos infinitos para lidiar con todos los problemas, por lo que siempre nos vemos obligados a elegir aquellos con los que tenemos que lidiar.

Avise a los desarrolladores que este es un exploit potencial real y comparación de cadenas debe hacerse utilizando algoritmos seguros en lugar de hacerlo directamente. Los costos aquí son realmente mínimos para cualquier código nuevo y elimina la posibilidad de riesgos.

Para cualquier código existente, considere solucionar el problema si no hay circunstancias atenuantes. Por ejemplo, estos ataques requieren miles y miles de intentos. Si su exploit se basa en una contraseña y limita los intentos a solo 3 intentos, será casi imposible revelar algo (digamos el hash) con este exploit. Por otro lado, si tiene un mecanismo de seguridad para un objetivo de alto valor que no tiene una tasa limitada de ninguna manera, debería considerar corregir este código.

#8
+1
Cort Ammon
2016-01-20 01:51:12 UTC
view on stackexchange narkive permalink

No se puede determinar fuera de contexto.

Una comparación de cadenas como esta sería difícil de atacar, como se describe en la respuesta aceptada. Los plazos son simplemente demasiado cortos. Sin embargo, el contexto es fundamental. Si un hacker inteligente puede moldear el resto del código alrededor de este bloque para amplificar los tiempos, es posible que pueda llegar a alguna parte.

Por ejemplo, si hubiera una forma inteligente para que un hacker provocara esta función para que te llamen 10,000,000 veces seguidas antes de enviar algo al cliente, podrías meterte en problemas. De repente, su problema de rango de menos de milisegundos se ha convertido en un problema de varios segundos y claramente visible contra el ruido de la red.

Este es un caso en el que recomendaría cambiar a una comparación de tiempo constante si su modelo de amenaza incluye ataques de tiempo. Usted podría sentarse y analizar toda su base de código para demostrar que ningún atacante puede utilizar trucos de repetición tan inteligentes y luego incluir un paso de garantía de calidad para asegurarse de que ningún cambio futuro interrumpa este análisis. O simplemente podría cambiar a una comparación de tiempo constante. Potencialmente, ponga un comentario que diga: "La comparación de tiempo constante probablemente sea excesiva, pero fue más fácil hacer que esta pequeña sección de código fuera segura contra ataques de tiempo que analizar todo el programa para garantizar que este código nunca se use incorrectamente de una manera que podría dar lugar a un ataque de tiempo ".

Habrá algunos problemas menores de legibilidad del código, y es posible que deba realizar un paso de control de calidad para demostrar que la comparación realmente funciona tan bien como String.equals. Probablemente no habrá costos de desempeño. Si la mayoría de sus usuarios son legítimos y tienen el secreto, tendrán que comparar toda la cadena de todos modos.



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...