Respuesta genérica: si la autenticación basada en contraseña se puede realizar fuera de línea, entonces la aplicación necesariamente contiene todo lo necesario para decidir si una contraseña determinada es la correcta o no. Esto implica inevitablemente que al descargar el código completo de la aplicación y el contenido, el atacante puede "emular" el servidor sin conexión en su propia máquina y probar las contraseñas en su tiempo libre, limitado solo por el poder de cómputo que puede reunir (cuántas PC comprará o renta) y el costo computacional inherente de verificar cada contraseña. Esto se conoce como una situación de diccionario sin conexión .
En el mejor de los casos , en tal caso, puede aumentar el costo utilizando el hash lento (muchas iteraciones de una función de hash subyacente, o algo similar) y sales (para evitar ataques paralelos, costos compartidos , tablas precomputadas ...). Consulte esta respuesta para un tratamiento completo.
Los ataques de diccionario sin conexión son una preocupación. Estar en tal situación no es cómodo. Si los usuarios aceptan una espera de 1 segundo para la autenticación en su teléfono inteligente, entonces la CPU del teléfono inteligente debe necesariamente poder verificar una contraseña dentro de un segundo. Un atacante con algunas PC buenas podrá "intentar" al menos unas docenas de contraseñas por segundo; haga que unos pocos cientos, si el algoritmo hash se asigna bien a lo que puede hacer la GPU, unos cuantos miles es que el atacante es laborioso y fue directo a algunos FPGA implementación. Además, el atacante suele ser paciente y puede permitirse esperar una o dos semanas antes de obtener una contraseña de usuario. Esto se suma, muy aproximadamente, a mil millones de intentos de contraseña para el atacante.
Capacitar a los usuarios promedio para elegir contraseñas que resistan un ataque de fuerza bruta de mil millones de contraseñas potenciales, es difícil. Consulte esta pregunta para una discusión sobre el tema. Por otro lado, si usted elige la contraseña (no el usuario), seleccione una secuencia de 15 letras aleatorias: eso es 70 bits de entropía, y esto resistirá el tiempo suficiente para disuadir a los atacantes ( un espacio de contraseña de tamaño 2 70 es enorme ).
Tenga en cuenta que las sales no deben ser secretas, y son efectivas incluso cuando son conocidas por el atacante. Una sal secreta no es una sal, sino una clave . No puede tener eso en su situación: uno debe suponer que el atacante volcó y realizó la ingeniería inversa del código completo de la aplicación. En gran medida, su contexto es similar al del cifrado basado en contraseña: protege la confidencialidad de un dato, con respecto a una contraseña secreta, sin hardware específico.