Almacenamiento de contraseña Hash texto sin formato

3

He estado investigando sobre el hashing / salado de contraseñas. Tengo entendido que la sal no necesita ser secreta. Pero no he leído nada sobre el hash que necesita ser secreto.

¿Qué tan oculto debe ser el hash real?

Diga que tengo esta sencilla tabla de base de datos:

Usuario
- nombre de usuario
- sal
- hash

Escenario
Tengo una base de datos en línea, bien asegurada / oculta. Puedo almacenar la sal y el hash sin ningún cifrado adicional, etc. Pero, ¿qué ocurre si ciertos usuarios de esta base de datos se almacenan en una base de datos local de SQLite de Android para el acceso sin conexión? La tabla tiene el mismo aspecto, pero ahora la sal y el hash solo están protegidos por un dispositivo no rooteado ( enlace ). La base de datos real de SQLite se puede leer fácilmente si alguien hizo una copia del archivo oculto. ¿Sigue siendo seguro almacenar la sal / hash del usuario en esta base de datos SQLite tal como está (cada usuario tiene una sal diferente)?

    
pregunta Programmer001 25.07.2016 - 21:34
fuente

2 respuestas

2

George tiene una buena respuesta con gran información sobre esto, sin embargo, hay una cosa en la que debes pensar Todo esto es tu experiencia de usuario, y el teatro de ataque. Si está en el teléfono de alguien, ¿quién sería el que obtendría esos datos?

  • Local: una persona con acceso físico a ese dispositivo. Con acceso físico al dispositivo, pueden esperar a ver la memoria para cargar cualquier tipo de cifrado en la memoria y extraer el hash de esa manera. En ese caso tienen el hash. Ese es uno de los problemas con el acceso al dispositivo físico.

  • Explotación de datos remotos: si todo lo que tienen es una copia del archivo que contiene el hash (posiblemente a través de un volcado de base de datos), siempre y cuando esté bien cifrado. Pasará mucho tiempo antes de que puedan descifrar el hash y comenzar a intentar sacar la contraseña de ese hash.

Debería haber varias formas de hacer esto. Elija la que mejor se adapte a los escenarios de ataque que le preocupan y buena suerte manteniéndolos (los secretos de cifrado y el hash) a salvo.

    
respondido por el Robert Mennell 25.07.2016 - 22:11
fuente
1

Supondré que está utilizando un Hash de contraseña fuerte (lento) como BCrypt con un factor de trabajo suficientemente alto. Si está utilizando un hash de propósito general (rápido), el beneficio de seguridad es muy bajo.

En la mayoría de los casos, el hash debe mantenerse en secreto.

  • Puede haber una vulnerabilidad descubierta en algún momento en el futuro.
  • El hash es un multiplicador de la fuerza de la contraseña. Si la contraseña es débil, el hash resultante se romperá fácilmente poco después de que el valor del hash sea robado.

Sin embargo, si tiene Requisitos de seguridad de contraseñas lo suficientemente bien orquestados, hay algunos casos en los que tiene sentido almacenar una contraseña localmente.

Por ejemplo, el Chromebook de Google utiliza esta técnica, lo que permite que un usuario use la misma contraseña para desbloquear un Chromebook como la cuenta de Google en línea.

Sin embargo, sería más seguro utilizar una contraseña diferente para este propósito. De esta manera, si la contraseña del dispositivo móvil se ve comprometida, la cuenta en línea sigue siendo segura y viceversa.

Para los Chromebooks, Google debe haber decidido que la proporción de seguridad frente a la conveniencia era aceptable para su audiencia.

Si decide almacenar el hash en un dispositivo móvil con Android, debe seguir adelante y comenzar una nueva pregunta para asegurarse de almacenarlo en la ubicación más segura disponible. Android tiene múltiples ubicaciones de almacenamiento posibles y configuraciones de seguridad de aplicaciones disponibles.

Y lo más importante, almacene el menor número de hashes posible en el dispositivo móvil. Preferiblemente, solo debe almacenar el hash que corresponde a la contraseña del propietario del dispositivo.

    
respondido por el George Bailey 25.07.2016 - 21:56
fuente

Lea otras preguntas en las etiquetas