Últimamente es raro el sitio que no permite identificarse con nuestra cuenta de Google, Facebook, Twitter u otras. La ventaja para el desarrollador está clara: desde un punto de vista de usuarios que re-utilizan contraseñas y que no son muy fiables a la hora de gestionar correctamente sus credenciales, delegamos ese trabajo en empresas más pontentes y que seguramente lo harán mejor que nosotros. Aunque puede que no sea una ventaja completa porque queramos tener un sistema de acceso para todas aquellas personas que no quieran utilizar este tipo de mezclas. Desde el punto de vista del usuario también está clara la ventaja: no tenemos que andar dándonos de alta en montones de sitios, con contraseñas (idealmente) diferentes y cofiando en administradores de plataformas que apenas conocemos.

Del tema de delegar la gestión de cuentas en otros se hablaba en Introducing the “Secure Account Management Fundamentals” course on Pluralsight que enlazamos en su momento desde Fundamentos de gestión de cuentas.

Para estas cosas se utiliza, entre otros OAuth que es un protocolo bastante completo y que permite cosas más sofisticadas. Nosotros lo hemos visto de pasada cuando hemos hablado de Publicar en Facebook las entradas de este sitio usando Python, Publicar en Twitter las entradas de este sitio usando Python, porque estos sitios no permiten que utilicemos la contraseña directamente, sino que prefieren que nos identifiquemos a través de OAuth.

Esencialmente se basa en que nos autentificamos una vez en el sitio proveedor (o más, si fuera necesario en el tiempo) y este nos proporciona unos tokens de acceso que permiten realizar ciertas operaciones en el propio sitio o, simplemenete nos reconoce como usuarios y eso le basta al sitio de origen como identificación.

El historial de seguridad de este protocolo ha tenido sus incidentes y por eso me gustó encontrar OAuth Security Cheatsheet que nos da las ideas principales sobre el flujo de datos y las precacuciones que debemos tomar a la hora de implementarlo/utilizarlo.

Una fuente frecuente de problemas de seguridad son los nombres: cuando esperamos que algo se llame de una determinada forma y también se puede referenciar con nombres alternativos (que no tuvimos en cuenta) es posible que se produzcan problemas: eso incluye la utilización de paths, diversas codificaciones, …

En la propia historia dicen que es un rumor (o algo que se dice) pero sirve como un ejemplo de lo que podría haber pasado (sin saber si es cierto o no): Windows 9 Reportedly Skipped as Name Would Have Created Code Bugs: la idea sería que en algunos casos se habrían utilizado búsquedas del nombre para identificar el sistema Operativo del estilo de ‘if(version,startswith(“windows 9”) que inevitablemente producirían confusiones en el caso de que se hubiera lanzado un hipotético Windows 9.

Sea cierta o no, una buena historia para un sábado. Y un recordatorio para los casos en que, efectivamente, los nombres han sido un problema.

El principio del mínimo privilegio consiste esencialmente en conceder a las aplicaciones y usuarios los permisos necesarios para realizar las acciones que tengan que llevar a cabo, pero no más. Esto durante el tiempo necesario.

En Improving security through least-privilege practices hablan del tema introduciendo las ideas generales y la motivación.

Me quedo con esta frase:

A tip I often give my clients is to not see accounts as privilege but see privilege as accounts. What I mean by this is an account that is used for backup administration, or an account that is used to create users on a domain should be used as such and not for anything else. If your user’s accounts have these privileges then you have lost control of your network, data and systems and any malicious user or application will eventually exploit this vulnerability.

En Teaching Code in 2014 algo que ya llevamos tiempo diciendo: se sigue enseñando a programar (no a nivel básico, sino incluso después) sin tener en cuenta la seguridad.

Los consejos que da tienen que ver con:

• No hay excusa para utilizar ejemplos inseguros
• La seguridad debería estar integrada, no añadida
• Usando Node.js también hay que tener en cuenta la seguridad
• Hay que cambiar la forma de enfrentarse a este problema

En definitiva, hay que enseñar buenas prácticas, incluir ejemplos no sólo correctos desde el punto de vista de la funcionalidad sino también pensando en la seguridad.

Aunque de vez en cuando se anuncia la sustitución de las contraseñas con diversas tecnologías, lo cierto es que parece que vamos a convivir con ellas durante una buena temporada. En Passwords: Real-world issues, tips and alternatives se entrevista a Per Thorsheim y hablan sobre el tema. Se habla de las contraseñas, algunas alternativas, mejorar la facilidad de uso. Thorsheim es el organizador de la PasswordsCon, un encuentro centrado en estas cuestiones.

Da la casualidad de que tengo por una de las pestañas de mi navegador el resumen sobre gestores de contraseñas que hacían recientemente en Lifehacker Faceoff: The Best Password Managers, Compared. Hace un poco más leíamos Top password managers compared.

También podíamos leer el otro día un texto generalista y orientado a audiencias más amplias, con consejos que incluso algunos que deberían saber mejor estas cosas olvidan a veces Web Security for the Tech-Impaired: Passwords that Pass the Test:

• Utilizar claves diferentes para sitios diferentes
• Tu clave no debería tener menos de 12 caracteres
• Utilizar una mezcla de minúsculas, mayúsculas, números y caracteres especiales
• No utilizar secuencias predecibles a la hora de organizar estas mezclas.

Ya hemos hablado más veces de contraseñas por aquí, por ejemplo en Algunos enlaces interesantes sobre claves y allí había más enlaces.