¿Debo restringir el acceso al nombre de usuario y las contraseñas en una aplicación web?

8

Estoy empezando a escribir mi primera aplicación web seria y estoy pensando en cómo almacenar información de nombre de usuario y contraseña. Hay una gran cantidad de artículos que detallan cómo almacenar contraseñas de texto sin formato es una muy mala idea, y las contraseñas cifradas con sal son el camino a seguir. Sin embargo, puedo encontrar muy poco sobre la restricción del acceso a los datos del usuario en sí.

Estoy pensando en una situación en la que mi aplicación web está en peligro y un atacante puede leer cualquier información de mi base de datos. Incluso si almaceno nombres de usuario con contraseñas cifradas, el atacante podría eliminar todos los nombres de usuario de la base de datos (pero al menos no obtendrían las contraseñas). Sin embargo, podría restringir el acceso, por lo que incluso mi aplicación no tuvo acceso a estos datos. Estaba pensando en evitar que el usuario de mi base de datos vea la tabla con nombres de usuario y contraseñas. A continuación, puede dar acceso a través de un procedimiento almacenado que toma el nombre de usuario y la contraseña, devolviendo verdadero si se encuentra un nombre de usuario con la contraseña, o presentando una vista de los nombres de usuario y las contraseñas con hash, por lo que incluso si no se encuentran comprometidos, no se pueden encontrar los nombres de usuario reales .

Dado que soy nuevo en esto, y no he podido encontrar ningún artículo que recomiende algo similar, supongo que me he perdido algo simple que hace que las ideas anteriores sean inseguras.

Gracias.

    
pregunta 21.06.2011 - 01:43
fuente

3 respuestas

9

Desde el punto de vista de la seguridad, la amenaza es lo que sucede cuando el almacenamiento subyacente se expone en de cualquier manera , no solo una declaración select * from users; inyectada en SQL. ¿Confías en tus administradores? ¿Incluso el que acabas de dejar ir? ¿Quién más tiene acceso a la caja? ¿Es una máquina virtual en una empresa de terceros? ¿En las nubes? Esa es la razón por la cual el hashing correcto a menudo se enfatiza ante todo, para que las contraseñas de los usuarios tengan alguna defensa incluso contra un usuario autorizado.

Dicho esto, creo que controlar el acceso a través de las vistas sería beneficioso, ya que solo se pueden ejecutar las pseudo-instrucciones "insertar usuario", "eliminar usuario", "existe el usuario" y "¿son válidas estas credenciales" desde la perspectiva? de su aplicación web. Esto evita la enumeración, excepto mediante llamadas repetidas a la base de datos con un identificador de usuario conocido, que es mejor que permitir que el atacante tome la base de datos completa. Está reduciendo la facilidad con la que un atacante puede tomar esa mesa en caso de que exista un posible compromiso / vulnerabilidad imprevista en su código o marco. La única pregunta es la compatibilidad con los marcos existentes, aunque muchos ofrecen la capacidad de extender o implementar backends de autenticación personalizados.

Sobre el tema del hashing, use PBKDF2 o bcrypt o una función de derivación de clave hash lenta equivalente con sal, no solo un hash con sal. Un artículo decente sobre el tema explicará esta etapa (a veces recomiendan repetir un hash para varios miles de iteraciones; es esencialmente la misma idea).

    
respondido por el diagprov 21.06.2011 - 02:08
fuente
6

¿Puedo ser frívolo y arriesgar los votos diciendo que no?

La mejor manera de evitar que sus nombres de usuario y contraseñas sean hackeados. No los guarde en primer lugar.

Utilice una autenticación federada como Facebook Connect (oAuth) o Google Open-ID. Escribo más sobre los beneficios aquí .

    
respondido por el Rakkhi 21.06.2011 - 15:09
fuente
2

Consulte Devise . Ayuda enormemente con la gestión de usuarios.

También Railscast de Ryan Bates:

Introducing Devise

Personalización del diseño

    
respondido por el ardavis 21.06.2011 - 01:53
fuente

Lea otras preguntas en las etiquetas