Mejores prácticas para la autenticación / seguridad de aplicaciones web (cualquier plataforma)


12

Hoy recibí una pregunta de mi gerente preguntándome qué se considera un diseño aceptable para la autenticación de una aplicación de formulario web, especialmente con respecto a la naturaleza de muchos navegadores populares para "Recordar contraseña" para los campos de inicio de sesión de contraseña de nombre de usuario típico .

Tengo problemas para encontrar una respuesta que considero aceptable. A la luz de las vergonzosas fallas de seguridad de Sony, realmente quiero tener cuidado, a pesar de que los datos que se almacenan en las personas son de menor sensibilidad. No estamos almacenando números de seguridad social o incluso direcciones, sin embargo, estamos almacenando números de teléfono, direcciones de correo electrónico y una foto de un visitante.

Le preocupa que un usuario pueda simplemente Recordar contraseña en un terminal público, luego alguien puede simplemente saltar a este terminal y comenzar a ver o modificar datos de una manera no autorizada. Sin embargo, estoy bastante seguro de que al menos en las estaciones de trabajo de Windows el navegador no "recordará la contraseña" en las cuentas de usuario de Windows.

Más allá de esto, estoy implementando un cifrado de contraseña unidireccional en el lado del servidor (almacene la contraseña cifrada en la base de datos, cifre la contraseña proporcionada por el usuario en el servidor, compárela con la cadena cifrada de la base de datos). No hay planes inmediatos para incorporar el cifrado SSL, sin embargo, esta sigue siendo una opción.

¿Hay alguna falla de seguridad importante con este enfoque? ¿Tienes alguna sugerencia mejor?


Cuando almacene la contraseña encriptada unidireccional (es decir, hash), asegúrese de usar un hash fuerte (es decir, no MD5) o sal la contraseña (consulte stackoverflow.com/questions/420843/… ) o ambos.
Jordan Reiter

Visite el sitio web de OWASP ( owasp.org ). Tienen mucha información de seguridad muy útil, incluidas "hojas de trucos" para varios protocolos.
Ralph

Aquí hay algunas pautas para la autenticación de sitios web basada en formularios stackoverflow.com/a/477578/463478
Solo tú el

Respuestas:


13

Algunos consejos de alto nivel:

  1. Almacene solo los datos que necesita
  2. Siempre encripte datos confidenciales (SSN, contraseña, número de tarjeta de crédito, etc.) cuando los almacene
  3. Siempre encripte el tráfico utilizando SSL cuando transmita / reciba datos confidenciales
  4. Si tiene dudas sobre la sensibilidad de la información, encripte
  5. No confíes en la entrada del usuario (alguien intentará ingresar algo malo)
  6. No confíe en sus datos (alguien puede cambiarlos en la base de datos, inyectando secuencias de comandos maliciosas, por ejemplo)
  7. No enrolles tu propia encriptación
  8. Asegure los servidores que alojan las aplicaciones / bases de datos
  9. Aumente la carga para los usuarios finales por razones de seguridad (restricciones de contraseña, nunca exponga las contraseñas, no envíe URL en el correo electrónico, reduzca el tiempo de sesión, etc.)

Mi sugerencia para usted sería obtener un libro sobre cómo proteger las aplicaciones web. Hay demasiada información para transmitir en una sola respuesta / blog / artículo. El tema del cifrado solo es sustancial.


¿Cuál es el razonamiento detrás del uso de SSL en lugar de rodar el propio cifrado? ¿Consideraría usar algo como WS-Security para su propio cifrado? Configurar SSL puede ser una molestia.
Sr. Jefferson

Esta es una buena lista de verificación. Me sorprende que no haya más votos positivos.
Kristofer Hoch

2
@ Mr.Jefferson, diría que el 99.999999% de las veces NUNCA quiere "rodar su propio cifrado".
Zach Leighton


1

Yo diría que deberías estar bien.

La mayoría de los usuarios serán lo suficientemente brillantes como para no guardar su contraseña en un terminal público, y las contraseñas se almacenarán por perfil. Tenga en cuenta que podrían escribirlo fácilmente en una nota adhesiva o usar una contraseña débil.

Si la página de inicio de sesión no está encriptada a través de SSL, no sería demasiado difícil para un atacante detectar esa contraseña mientras viaja por la red. Sin embargo, un buen trabajo al cifrar la contraseña en la base de datos, evitará que un atacante potencial vea las contraseñas de todos (que podrían usar con la dirección de correo electrónico para intentar iniciar sesión en otros sitios en los que el usuario podría estar).

Si aún así lo desea, hay formas de deshabilitar el comportamiento del navegador, como lo señaló Chad. Solo lo he visto en el sitio web de mi banco y en el sistema Live de Microsoft.


Gran publicación, olvidé agregar que el nombre de usuario no será la dirección de correo electrónico, sin embargo, un usuario tendrá una dirección de correo electrónico almacenada en el sistema. Sin embargo, es gracioso que mencione esto porque incluso los sitios populares como Facebook son susceptibles de rastrear paquetes para agregar correos electrónicos y contraseñas.
maple_shaft

También quiero agregar que no estoy señalando las fallas de seguridad en Facebook como una "excusa" necesariamente para un modelo de seguridad deficiente en mi aplicación. El hecho de que la madre de Joey le permita ver películas clasificadas R no lo hace correcto :)
maple_shaft

1

En cierto punto, no puede (y no está legalmente obligado) proteger a un usuario de sí mismo. La funcionalidad "Recordar contraseña" puede ser arriesgada, pero es un riesgo asumido por el usuario. Del mismo modo, si el usuario decide reutilizar su contraseña para múltiples servicios, también asume ese riesgo. Tampoco está obligado a advertirles que no escriban su contraseña en una nota adhesiva y la peguen en su monitor, aunque los usuarios a menudo también lo hacen.

Es decir, hasta que alguien litiga con éxito y cambia las reglas. Consulte también: "Advertencia: el contenido puede estar caliente".


0

No creo que pueda controlar de manera confiable si el navegador recuerda o no una contraseña. Simplemente está fuera de tus manos si el navegador hace eso o no. Tampoco es necesariamente un gran riesgo de seguridad para usted . Siempre debe suponer que los ataques pueden realizarse desde inicios de sesión válidos. No asuma porque alguien tiene un usuario / pase de inicio de sesión válido que no hará nada malo. Después de todo, hay muchas formas en que las contraseñas pueden caer en las manos equivocadas.

Supongo que lo que podría hacer es aleatorizar los nombres de campo en su formulario de inicio de sesión cada vez. En lugar de <input name="username"usar algo como <input name="user658667587". Eso haría que los nombres de usuario en caché sean bastante inútiles. Pero no sé si los gastos generales valdrían la pena. Sin mencionar incomodar a los usuarios que no están en máquinas públicas.

Si se encuentra en una situación extremadamente sensible a la seguridad (banca, inversión), simplemente puede preguntar a las personas durante el inicio de sesión si se trata de una máquina pública. También puede almacenar en caché las direcciones IP conocidas cuando las personas inician sesión, y si inician sesión desde una ubicación diferente requieren un número pin no tecleable (por ejemplo, haga clic en las imágenes) además del usuario / pase normal. Mi banco hace algo similar a eso.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.