Por Ian Maddox, arquitecto de GCP Solutions

La administración de cuentas, autorizaciones y contraseñas puede ser complicada. Para muchos programadores, la administración de cuentas es un punto ciego al que no se le presta suficiente atención. Para los gerentes de producto y los clientes, la experiencia resultante generalmente no cumple con las expectativas.
Por Ian Maddox, arquitecto de GCP Solutions

La administración de cuentas, autorizaciones y contraseñas puede ser complicada. Para muchos programadores, la administración de cuentas es un punto ciego al que no se le presta suficiente atención. Para los gerentes de producto y los clientes, la experiencia resultante generalmente no cumple con las expectativas.

Por suerte, Google Cloud Platform (GCP) incluye varias herramientas que te ayudarán a tomar buenas decisiones respecto de la creación, administración segura y autenticación de cuentas de usuarios (en este contexto, cualquiera que se identifique con tu sistema,  clientes o usuarios internos). Si eres responsable de un sitio web alojado en Google Kubernetes Engine, una API en Apigee, una app que usa Firebase u otro servicio con usuarios autenticados, en esta entrada se abarcarán las prácticas recomendadas para garantizar que cuentes con un sistema de autenticación de cuentas seguro, escalable y utilizable.

1. Guarda las contraseñas


Mi regla más importante para la administración de cuentas es guardar de forma segura la información confidencial del usuario, incluidas sus contraseñas. Debes tratar esos datos como si fueran sagrados y manipularlos correctamente.

No guardes contraseñas en texto sin formato bajo ninguna circunstancia. Tu servicio debe, como alternativa, almacenar un hash criptográficamente seguro de la contraseña que no pueda revertirse ; creado, por ejemplo, con PBKDF2, SHA3, Scrypt o Bcrypt. Se debe aplicar sal a ese hash con un valor exclusivo para esa credencial de acceso específica. No uses tecnologías de hashing obsoletas, como MD5, SHA1. Tampoco debes usar bajo ninguna circunstancia encriptación reversible ni intentar revertir tu algoritmo de hashing.

Debes diseñar tu sistema asumiendo que presentará fisuras en algún momento. Pregúntate esto: “si mi base de datos quedara expuesta hoy, ¿estaría en riesgo la seguridad de mis usuarios en mi servicio o en otros que utilizan? ¿Qué se puede hacer para reducir las probabilidades de daños en caso de una fuga?”

Otro punto: si pudieras producir una contraseña de usuario en texto sin formato en cualquier momento, salvo inmediatamente después de que ellos te la proporcionen, habrá un problema en tu implementación.

2. Si es posible, permite el uso de proveedores de identidad externos


Los proveedores de identidad externos te permiten consultar un servicio externo confiable para autenticar la identidad de un usuario. Google, Facebook y Twitter son proveedores que se utilizan con frecuencia.

Puedes implementar proveedores de identidad externos junto con tu sistema de autenticación interno actual usando una plataforma como Firebase Auth. Firebase Auth ofrece una serie de beneficios, en los que se incluyen una administración simplificada, una menor superficie de ataque y un SDK multiplataforma. Abordaremos más beneficios a lo largo de esta lista. Consulta nuestros estudios de casos sobre compañías que pudieron integrar Firebase Auth en un solo día.

3. Separa el concepto de identidad del usuario y cuenta del usuario


Tus usuarios no son una dirección de correo electrónico. No son un número de teléfono. No son un ID único proporcionado por una respuesta de OAUTH. Tus usuarios son la culminación de sus datos exclusivos y personalizados, y sus experiencias con tu servicio. Un sistema de administración de usuarios bien diseñado ofrece poca vinculación y gran cohesión entre las diferentes partes del perfil de un usuario.

Mantener separados los conceptos de cuenta de usuario y credenciales simplificará notablemente el proceso de implementación de proveedores de identidad externos, lo que permitirá a los usuarios cambiar sus nombres de usuario y vincular varias identidades a una sola cuenta de usuario. En términos prácticos, puede ser útil tener un identificador global interno para cada usuario y vincular su perfil y autenticación a través de ese ID en lugar de amontonarlos a todos en un solo registro.

4. Permite la vinculación de varias identidades con una sola cuenta de usuario


Un usuario que se autentica en tu servicio usando su nombre de usuario y contraseña durante una semana podría elegir Google Sign-In a la semana siguiente sin saber que esto podría crear una cuenta duplicada. De igual manera, un usuario podría tener una muy buena razón para vincular varias direcciones de correo electrónico a tu servicio. Si separaste correctamente la identidad y la autenticación del usuario, el proceso de vincular varias identidades con un solo usuario será más simple.

En tu back-end deberá contemplarse la posibilidad de que un usuario realice el proceso de acceso de forma parcial o total antes de darse cuenta de que usa una nueva identidad externa no vinculada a su cuenta en tu sistema. Esto se logra con mayor facilidad si se solicita al usuario proporcionar un detalle identificatorio común, como la dirección de correo electrónico, el teléfono o el nombre de usuario. Si los datos coinciden con un usuario existente de tu sistema, solicítale también autenticarse con un proveedor de identidad conocido y vincular el nuevo ID con su cuenta existente.

5. No bloquees contraseñas extensas o complejas


Recientemente, NIST ha actualizado las pautas sobre complejidad y seguridad de las contraseñas. Gracias a que usas (o usarás muy pronto) un hash criptográfico seguro para el almacenamiento de contraseñas, ya tienes muchos problemas resueltos. Los hash siempre producirán un código de extensión fija, independientemente de la extensión de la contraseña ingresada, de modo que tus usuarios podrán usar sus contraseñas durante el tiempo que quieran. Si necesitaras reducir la extensión de las contraseñas, solo hazlo teniendo en cuenta el tamaño de POST máximo permitido por tus servidores. Normalmente, es bastante superior a 1 MB. De verdad.

Tus contraseñas con hash constarán de una pequeña selección de caracteres ASCII conocidos. De lo contrario, puedes convertir fácilmente un hash binario a Base64. Considerando esto, deberías permitir que tus usuarios usen, literalmente, los caracteres que deseen en sus contraseñas. Si alguien desea que su contraseña contenga Klingon, Emoji y caracteres de control con espacios en blanco en ambos extremos, no deberías tener razones técnicas para impedirlo.

6. No impongas reglas disparatadas para los nombres de usuario


No es disparatado que un sitio o servicio solicite nombres de usuario de más de dos o tres caracteres, que bloquee los caracteres ocultos y que evite la presencia de espacios en blanco al comienzo y al final de un nombre de usuario. No obstante, algunos sitios se exceden con los requisitos, como una extensión mínima de ocho caracteres o el bloqueo de caracteres que no sean letras y números en ASCII de 7 bits.

Un sitio con restricciones rígidas para los nombres de usuario puede ofrecer algunas ventajas a los programadores, pero la carga recaerá sobre los usuarios. A su vez, en casos extremos, algunos usuarios se alejarán del sitio.

En algunos casos, la mejor estrategia es asignar los nombres de usuario. Si esto se aplica a tu servicio, asegúrate de que el nombre de usuario asignado sea simple para que el usuario pueda recordarlo y comunicarlo. Para los ID alfanuméricos deben evitarse símbolos visualmente ambiguos, como “Il1O0”. También se te recomienda buscar en el diccionario algunas cadenas generadas al azar para asegurarte de que no haya mensajes inadvertidos en el nombre de usuario. Estas mismas pautas se aplican para las contraseñas generadas automáticamente.

7. Permite que los usuarios cambien su nombre de usuario


Es muy común que en los sistemas heredados, o en algunas plataformas que proporcionan cuentas de correo electrónico, se prohíba a los usuarios cambiar su nombre de usuario. Existen muy buenas razones para no liberar automáticamente nombres de usuario con el propósito de que vuelvan a usarse, pero quienes emplean tu sistema hace mucho tendrán, con el tiempo, un buen motivo para usar un nombre de usuario diferente y probablemente no deseen crear una cuenta nueva.

Puedes cumplir el deseo de tus usuarios de cambiar sus nombres de usuario habilitando el uso de alias y permitiéndoles elegir el alias principal. Puedes aplicar las reglas empresariales que necesites sobre la base de esta funcionalidad. Algunas organizaciones solo permiten un cambio de nombre de usuario por año o exigen al usuario mostrar solo su nombre de usuario principal. Los proveedores de correo electrónico podrían garantizar que los usuarios reciban la información necesaria sobre los riesgos antes de desvincular un nombre de usuario en desuso de sus cuentas, o quizá prohibir por completo la desvinculación de nombres de usuario en desuso.

Escoge las reglas adecuadas para tu plataforma, pero asegúrate de permitir a tus usuarios desarrollarse y realizar cambios a medida que pase el tiempo.


8. Permite que tus usuarios borren sus cuentas


Un número sorprendente de servicios no tienen opciones de autoservicio para que un usuario borre su cuenta y los datos asociados. Existen varias buenas razones por las que un usuario puede cerrar una cuenta de forma permanente y borrar todos los datos personales. Esas inquietudes deben considerarse sin perder de vista tu seguridad y tus necesidades de cumplimiento, pero los entornos más reglamentados proporcionan pautas específicas sobre la retención de datos. Una solución común para evitar preocupaciones en relación con el cumplimiento y posibles intrusiones es permitir que los usuarios programen sus cuentas para la eliminación automática en el futuro.

En algunas circunstancias, es posible que se te exija, por medios legales, acceder a la solicitud de un usuario que desee borrar sus datos de forma oportuna. A su vez, tu exposición también aumentará notablemente si ocurre una filtración de datos en la que se revelen datos de cuentas “cerradas”.

9. Toma una decisión consciente con respecto a la duración de las sesiones


Un aspecto de seguridad y autenticación generalmente omitido es la duración de las sesiones. Google se esfuerza mucho por garantizar que los usuarios sean quienes dicen ser y lo corroborará en función de conductas o eventos determinados. Los usuarios pueden tomar medidas para aumentar aún más su seguridad.

Tu servicio puede tener un buen motivo para mantener una sesión abierta indefinidamente con fines de análisis no crítico, pero debe haber umbrales que deben superarse para que solicites la verificación de usuarios mediante de contraseña, segundo factor u otro elemento.

Piensa en cuánto tiempo un usuario debe estar inactivo antes de tener que volver a autenticarse. Si alguien restablece la contraseña, verifica la identidad del usuario en todas las sesiones activas. Solicita la autenticación o un segundo factor si un usuario cambia aspectos centrales de su perfil o cuando realice una acción confidencial. Evalúa si tiene sentido deshabilitar el acceso desde más de un dispositivo o lugar a la vez.

Cuando tu servicio finalice una sesión de usuario o solicite repetir la autenticación, informa al usuario en tiempo real o proporciona un mecanismo que preserve la actividad que no guardó desde su última autenticación. Resulta frustrante para un usuario llenar un formulario extenso, enviarlo un tiempo después y descubrir que todo lo que ingresó se perdió y debe acceder nuevamente.

10. Usa verificación en dos pasos


Piensa en el impacto que tiene, en términos prácticos, sobre un usuario el robo de su cuenta al elegir un método de verificación en dos pasos (también conocida como autorización de dos factores o simplemente 2FA). NIST ha dejado de usar la autorización 2FA por SMS debido a varios puntos débiles; no obstante, quizá sea la opción más segura que tus usuarios aceptarán para lo que consideren un servicio de poca importancia. Ofrece el método de autorización 2FA más seguro que puedas. Permitir el uso de proveedores de identidad externos y realizar “piggyback” en sus 2FA es un modo sencillo de aumentar tu seguridad sin grandes gastos ni esfuerzos.

11. Haz que no se distingan mayúsculas y minúsculas para los ID de usuario


A tus usuarios no les importa y quizá ni siquiera recuerden la forma exacta en la que escribieron su nombre de usuario. No deben distinguirse mayúsculas y minúsculas para los nombres de usuario. No es eficaz almacenar nombres de usuario y direcciones de correo electrónico en minúsculas y transformar las entradas en minúsculas antes de la comparación.

Los smartphones representan un porcentaje cada vez mayor de los dispositivos de usuarios. La mayoría ofrecen autocorrección y cambio automático a mayúsculas de campos con texto sin formato. Evitar esta conducta a nivel de la IU podría no ser lo mejor ni completamente eficaz, y tu servicio debe ser suficientemente sólido como para administrar una dirección de correo electrónico o un nombre de usuario que se haya ingresado en mayúsculas por error.

12. Crea un sistema de autenticación seguro


Si usas un servicio como Firebase Auth, muchas cuestiones de seguridad se abordan por ti automáticamente. Sin embargo, siempre deberás diseñar tu servicio correctamente para evitar abusos. Entre las consideraciones más importantes se incluyen la implementación de un restablecimiento de contraseña en lugar de la recuperación de esta, el registro detallado de la actividad de la cuenta, una cantidad límite de intentos de acceso, el bloqueo de cuentas después de demasiados intentos sin éxito y la solicitud de autenticación de 2 factores para cuentas o dispositivos desconocidos que hayan permanecido inactivos durante un tiempo prolongado. Hay muchos más aspectos importantes para un sistema de autenticación seguro, por lo que te recomiendo leer la siguiente sección, donde encontrarás vínculos a más información.


Consultas adicionales


Hay disponibles varios recursos excelentes que te guiarán en el proceso de desarrollo, actualización o migración de tu sistema de administración de cuentas y autenticación. Te recomiendo lo siguiente como punto de partida:

Publicado por Tara N. Sainath, científica investigadora, equipo de voz, y Yonghui Wu, ingeniero de software, equipo de ideas de Google
Publicado por Tara N. Sainath, científica investigadora, equipo de voz, y Yonghui Wu, ingeniero de software, equipo de ideas de Google

Los sistemas de reconocimiento de voz automáticos (ASR) tradicionales, que se usan para diferentes aplicaciones de búsqueda por voz en Google, constan de un modelo acústico (AM), un modelo de pronunciación (PM) y un modelo de idioma (LM), que se preparan individualmente y, por lo general, se diseñan manualmente, en diferentes conjuntos de datos [1]. Los AM toman funciones acústicas y predicen un conjunto de unidades de subpalabras; normalmente, fonemas dependientes e independientes del contexto. Luego, un léxico diseñado manualmente (el PM) asigna una secuencia de fonemas, producida por el modelo acústico, a palabras. Por último, el LM asigna probabilidades a secuencias de palabras. La preparación de componentes independientes crea otras complejidades y no es óptimo cuando se compara con la preparación de todos los componentes de forma conjunta. Durante los últimos años, se ha vuelto cada vez más popular el desarrollo de sistemas integrales, cuyo propósito es aprender esos componentes independientes de forma conjunta como un solo sistema. Si bien esos modelos integrales han mostrado resultados prometedores en la literatura [2, 3], aún no está claro si esos enfoques pueden mejorar en los sistemas convencionales de vanguardia actuales.

Hoy compartimos con entusiasmo “Reconocimiento de voz innovador con modelos secuenciales [4]”, que describe un nuevo modelo integral que supera el rendimiento de un sistema de producción convencional [1]. Mostramos que nuestro sistema integral alcanza un índice de error de palabras (WER) del 5,6%, que corresponde a una mejora relativa del 16% en comparación con un sistema convencional sólido, que alcanza un WER del 6,7%. Además, el modelo integral usado para generar la hipótesis de palabras inicial, antes de realizar una nueva puntuación de cualquier hipótesis, es 18 veces más pequeño que el modelo convencional, ya que no contiene LM ni PM independientes.

Nuestro sistema se basa en la arquitectura integral escuchar-asistir-deletrear (LAS), que se presentó por primera vez en [2]. La arquitectura LAS consta de 3 componentes. El componente codificador de escucha, similar a un AM estándar, toma una representación de frecuencia de tiempo de la señal de voz de entrada, x, y usa un conjunto de capas de red neurales para asignar los datos de entrada a una representación de función de nivel superior, henc. Los datos de salida del codificador se pasan a un mecanismo de atención, que usa henc para determinar una alineación entre las funciones de entrada x y las unidades de subpalabra previstas {yn, … y0}, donde cada subpalabra generalmente es un grafema o una parte de una palabra. Por último, el resultado del módulo de atención se pasa al deletreador (es decir, el decodificador), similar a un LM, que produce una distribución de probabilidad entre un conjunto de palabras supuestas.
Componentes del modelo integral LAS.
Todos los componentes del modelo LAS se preparan de forma conjunta como una sola red neural integral, no como módulos independientes propios de los sistemas convencionales, lo cual hace mucho más simple el proceso.
Además, debido a que el modelo LAS es completamente neural, no se requieren componentes externos diseñados manualmente, como transductores de estado limitados, un léxico o módulos de normalización de texto. Por último, a diferencia de lo que sucede con los modelos convencionales, para la preparación de modelos integrales no se necesitan arranques desde árboles de decisión ni alineaciones de tiempo generadas por un sistema independiente; esta se puede lograr a partir de pares de transcripciones de texto y de la acústica correspondiente.

En [4], presentamos diferentes mejoras estructurales nuevas, que incluyen la optimización de los vectores de atención que se pasan al decodificador y la preparación con unidades de subpalabras más extensas (es decir, partes de palabras). A su vez, también presentamos varias mejoras de optimización para la preparación, entre las que se incluyen el uso de preparación con un índice de error de palabras mínimo [5]. Estas mejoras estructurales y de optimización son las que permiten alcanzar la mejora relativa del 16% en comparación con el modelo convencional.

Otro campo de aplicación potencial que genera entusiasmo para esta investigación es el de los sistemas multidialecto y multilingüe, en el cual la facilidad de optimización de una red neural individual hace que el modelo sea muy atractivo. Aquí, los datos para todos los dialectos e idiomas se pueden combinar para preparar una red sin la necesidad de un AM, PM y LM independientes para cada dialecto o idioma. Estos modelos funcionan bien en 7 dialectos del inglés [6] y 9 idiomas de la India [7], y su rendimiento supera al de un modelo preparado de forma independiente para cada idioma o dialecto por separado.

Si bien estamos entusiasmados con los resultados, nuestro trabajo no ha terminado. Actualmente, estos modelos no pueden procesar voz en tiempo real [8, 9 y 10], que es un requisito importante para las aplicaciones sensibles a la latencia, como la búsqueda por voz. Además, la comparación de estos modelos con la producción aún es negativa cuando se evalúan en los datos de producción en tiempo real. Además, nuestro modelo integral incorpora 22 millones de enunciados en pares de audio-texto en comparación con un sistema convencional, que generalmente se prepara con elementos mucho más extensos. A esto se suma que nuestro modelo propuesto no puede aprender a deletrear de forma correcta palabras de uso poco frecuente, como nombres propios, algo que generalmente se logra con un PM diseñado manualmente. Nuestros esfuerzos continuos se centran en la manera de abordar esos desafíos.

Agradecimientos
Este trabajo se realizó en un gran esfuerzo colaborativo entre los equipos de ideas y voz de Google. Entre los colaboradores se incluyen Tara Sainath, Rohit Prabhavalkar, Bo Li, Kanishka Rao, Shankar Kumar, Shubham Toshniwal, Michiel Bacchiani y Johan Schalkwyk, del equipo de voz, y Yonghui Wu, Patrick Nguyen, Zhifeng Chen, Chung-cheng Chiu, Anjuli Kannan, Ron Weiss, Navdeep Jaitly, William Chan, Yu Zhang y Jan Chorowski, del equipo de ideas de Google. El trabajo se describe de forma más detallada en los documentos [4-12].

Referencias
[1] G. Pundak and T. N. Sainath, “Lower Frame Rate Neural Network Acoustic Models," in Proc. Interspeech, 2016.

[2] W. Chan, N. Jaitly, Q. V. Le y O. Vinyals, “Listen, attend and spell”, CoRR, vol. abs/1508.01211, 2015

[3] R. Prabhavalkar, K. Rao, T. N. Sainath, B. Li, L. Johnson y N. Jaitly, “A Comparison of Sequence-to-sequence Models for Speech Recognition”, en Proc. Interspeech, 2017.

[4] C.C. Chiu, T.N. Sainath, Y. Wu, R. Prabhavalkar, P. Nguyen, Z. Chen, A. Kannan, R.J. Weiss, K. Rao, K. Gonina, N. Jaitly, B. Li, J. Chorowski y M. Bacchiani, “State-of-the-art Speech Recognition With Sequence-to-Sequence Models”, presentado en ICASSP 2018.

[5] R. Prabhavalkar, T.N. Sainath, Y. Wu, P. Nguyen, Z. Chen, C.C. Chiu y A. Kannan, “Minimum Word Error Rate Training for Attention-based Sequence-to-Sequence Models”, presentado en ICASSP 2018.

[6] B. Li, T.N. Sainath, K. Sim, M. Bacchiani, E. Weinstein, P. Nguyen, Z. Chen, Y. Wu y K. Rao, “Multi-Dialect Speech Recognition With a Single Sequence-to-Sequence Model”, presentado en ICASSP 2018.

[7] S. Toshniwal, T.N. Sainath, R.J. Weiss, B. Li, P. Moreno, E. Weinstein y K. Rao, “End-to-End Multilingual Speech Recognition using Encoder-Decoder Models”, presentado en ICASSP 2018.

[8] T.N. Sainath, C.C. Chiu, R. Prabhavalkar, A. Kannan, Y. Wu, P. Nguyen y Z. Chen, “Improving the Performance of Online Neural Transducer Models”, presentado en ICASSP 2018.

[9] C.C. Chiu* y C. Raffel*, “Monotonic Chunkwise Attention”, presentado en ICLR 2018.

[10] D. Lawson*, C.C. Chiu*, G. Tucker*, C. Raffel, K. Swersky, N. Jaitly. “Learning Hard Alignments with Variational Inference”, presentado en ICASSP 2018.

[11] T.N. Sainath, R. Prabhavalkar, S. Kumar, S. Lee, A. Kannan, D. Rybach, V. Schogol, P. Nguyen, B. Li, Y. Wu, Z. Chen y C.C. Chiu, “No Need for a Lexicon? Evaluating the Value of the Pronunciation Lexica in End-to-End Models”, presentado en ICASSP 2018.

[12] A. Kannan, Y. Wu, P. Nguyen, T.N. Sainath, Z. Chen y R. Prabhavalkar. “An Analysis of Incorporating an External Language Model into a Sequence-to-Sequence Model”, presentado en ICASSP 2018.




Por Andrew Hoying, experto en Seguridad de Google Cloud.


El mes pasado, Project Zero divulgó detalles sobre las vulnerabilidades de CPU que se han denominado “Meltdown” y “Spectre”, y te informamos que Google Cloud se actualizó para brindar protección contra todas las vulnerabilidades conocidas.

Los clientes que poseen equipos virtuales (VM) en los servicios de Google Cloud deben continuar siguiendo las prácticas recomendadas de seguridad y aplicar periódicamente todas las actualizaciones de seguridad, tal como lo harían con cualquier otra vulnerabilidad del sistema operativo. Proporcionamos una lista completa de medidas recomendadas para que los clientes de GCP puedan protegerse contra estas vulnerabilidades.

Una medida recomendada es actualizar todos los clústeres de Google Kubernetes Engine para garantizar que se revise por completo la imagen del VM subyacente. Puedes hacerlo automáticamente habilitando la actualización automática en tus grupos de nodos de Kubernetes. ¿Quieres asegurarte de que todos tus clústeres tengan una versión revisada que contemple estas vulnerabilidades de CPU? El equipo de seguridad de Google Cloud desarrolló un escáner que puede resultar útil.

Este se encuentra en Forseti Security, un conjunto de herramientas de código abierto para GCP que te permite identificar rápidamente clústeres de Kubernetes Engine aún no revisados.

Si ya instalaste Forseti, debes actualizarlo a la versión 1.1.10 y habilitar el escáner. Si aún no lo has hecho, instala Forseti Security en un nuevo proyecto de tu organización en GCP. El escáner comprobará, una vez por hora, la versión de los grupos de nodos de todos los clústeres de Kubernetes Engine que se ejecuten en todos tus proyectos de GCP. Forseti registra las infracciones que detecta en su tabla de infracciones y, opcionalmente, envía un correo electrónico a tus administradores de GCP para ayudarte a identificar cualquier exposición persistente a Meltdown.
El conjunto de herramientas Forseti se puede usar de muchas formas diferentes para ayudarte a preservar la seguridad. Para obtener más información sobre la comunidad Forseti, lee esta entrada del blog. Si tienes preguntas sobre esta herramienta, envía un mensaje a discuss@forsetisecurity.org.