En una época en la que las violaciones de las contraseñas son muy comunes, es fácil preocuparse por lo que hacen las empresas con las contraseñas de los usuarios. Por desgracia, en la mayoría de los casos se trata de un escenario de caja negra en el que sólo podemos adivinar lo que está pasando bajo el capó basándonos en pistas como las restricciones de caracteres o de longitud. A veces está claro cuando hay un problema (como cuando «se ha olvidado la contraseña» te envía por correo electrónico tu contraseña), pero otras veces no hay ninguna manera de saberlo con seguridad.
Por eso queremos abrir el telón y explicar cómo se manejan las contraseñas, sobre todo porque en el pasado hemos dado a la gente motivos para cuestionar nuestra seguridad.
Señales de advertencia
Sería poco sincero escribir este post sin reconocer nuestros errores. El más grande fue que solíamos enviar por correo electrónico las contraseñas en texto plano a algunos de nuestros nuevos usuarios. Era sólo para los usuarios que creaban su cuenta canjeando un código de oferta, y tratamos de crear contraseñas aleatorias fuertes… pero enviar por correo electrónico la contraseña en lugar de un enlace para restablecerla estaba mal. Así que lo arreglamos.
La otra cosa que causó preocupación fue que algunas contraseñas harían que nuestro sitio arrojara un error «hardcore» de 500.Naturalmente esto llevó a la gente a preguntarse, «¿No permite contraseñas fuertes?» El problema subyacente fue que el framework .NET por defecto arroja una excepción para ciertas entradas (como cuando contiene el carácter <) porque son "valores potencialmente peligrosos" que podrían ser de inyección de HTML. Desde entonces hemos agregado las exenciones apropiadas del framework para los campos de contraseña para que estos tipos de contraseñas ya no sean un problema.
Mirando desde afuera, estas señales de advertencia causaron que algunas personas se preguntaran sobre el resto de nuestra seguridad. ¿Qué está pasando realmente bajo el capó?
Cómo manejamos las contraseñas
Nunca hemos almacenado los datos de las contraseñas en texto plano. Originalmente usábamos hashes SHA-256 con sales por usuario. Luego, el verano pasado, pasamos a bcrypt como nuestro algoritmo predeterminado, y actualizamos las contraseñas antiguas cuando los usuarios se registran (porque es la única vez que tenemos la contraseña en texto plano para volver a pasar al nuevo algoritmo). Si más adelante aparece un algoritmo mejor, también podemos actualizar nuestros usuarios a ese.
Como no podemos recuperar las contraseñas, enviamos enlaces de restablecimiento de contraseñas con fichas de una sola vez que expiran después de un corto período.
En cuanto a las restricciones, requerimos que las contraseñas tengan al menos 8 caracteres de longitud, y no más de 128. ¿Por qué 128? Porque es un número arbitrario (y una potencia de 2) que nos pareció lo suficientemente grande como para crear contraseñas fuertes sin ser tan grande que empiece a impactar cosas como la memoria del servidor o el ancho de banda de la red. Siempre hay limitaciones y compensaciones. Después de todo, ¿alguien necesita realmente el texto completo de Moby Dick como su contraseña?
No tenemos ningún requisito en cuanto a caracteres especiales, contraseñas usadas anteriormente o algo así. Es posible que eventualmente agreguemos algunas restricciones adicionales, pero también reconocemos que algunas políticas de contraseñas tienen el efecto de reducir la seguridad en vez de aumentarla.
Mejoras
A medida que ha ido creciendo, hemos añadido más desarrolladores y hemos desglosado nuestra base de código original del monolito en contextos más pequeños y delimitados, propiedad de equipos separados.
En el caso de las aplicaciones para móviles, se espera que una vez que inicie sesión, permanezca conectado. Para nuestras aplicaciones, ahora utilizamos un token de autorización de larga duración para este escenario, de modo que no es necesario almacenar las contraseñas en el dispositivo. Y si escribir la contraseña es incómodo en el móvil, también tenemos una opción de autorización fuera de banda. Cuando pierda o actualice su dispositivo, puede revocar el acceso del antiguo desde la página de configuración de su cuenta.
También tenemos algunas otras ideas. Añadir un medidor de fuerza de la contraseña a nuestro sitio podría ser una buena manera de animar a los usuarios a crear contraseñas más fuertes sin arriesgar las políticas que reducen involuntariamente el espacio de ataque. También estamos considerando la posibilidad de poner en una lista negra las contraseñas malas comunes, como «contraseña» o «12345678». La autenticación de dos factores se ha planteado varias veces. Pero no todas las ideas se implementan.
La seguridad es un gradiente
A menudo la gente piensa que la seguridad es binaria: o se está seguro o no se está seguro. Pero la verdad es que hay grados de seguridad, y no todo tiene que ser el equivalente digital de Fort Knox. Algunos sitios, como los bancos, necesitan una alta seguridad debido al valor de lo que necesitan proteger. Otros sitios, como los simples foros, pueden tener muy poco valor y no necesitan una autenticación multifactorial, preguntas de seguridad y similares.
Del mismo modo, hay que tener en cuenta las compensaciones de uso. ¿Cómo podemos hacer que sea más seguro sin perjudicar la experiencia de aprendizaje?
definitivamente tiene datos valiosos que proteger para nuestros usuarios: información personal identificable (PII), suscripciones, datos de aprendizaje, puntajes de evaluación, etc.Así que queremos que nuestra seguridad sea alta.
Categorías: technicalTags: security, getting started