A veces, cuando diseñamos un sistema, no somos conscientes de todas las consecuencias de nuestras decisiones. Tarde o temprano nos tocará cambiar algunas partes para remediar estos problemas. En GitHub se han encontrado con este problema a la hora de identificar los tokens de autentificación y descubrir que no podían diferenciar unos tipos de otros. En Behind GitHub’s new authentication token formats nos lo cuentan.

El formato de algunos tokens antiguos están codificados en formato hexadecimal de 40 caracteres y esto los hace indistinguibles de otros que están codificados de la misma forma, pero que son de otros tipos. Y esto es un problema.

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes.

Consideran, igual que otros, que la mejor forma de diferenciar estos elementos es mediante un prefijo, y por eso los están sustituyendo.

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

Pero aún querían ir más allá, añadiendo sumas de comprobación (checksums).

Identifiable prefixes are great, but let’s go one step further. A checksum virtually eliminates false positives for secret scanning offline. We can check the token input matches the checksum and eliminate fake tokens without having to hit our database.

Y para hacerlo, han seleccionado el algoritmo C·C32

We start the implementation with a CRC32 algorithm, a standard checksum algorithm. We then encode the result with a Base62 implementation, using leading zeros for padding as needed.

OAuth es un conjunto de especificaciones para delegar la autentificación y autorización en un tercero. Tiene algunas ventajas notables, como la de permitir que alguien pueda actuar en nuestro nombre sin cederle nuestras credenciales. O que ese ‘alguien’ sea ‘algo’ que utilizamos y donde no queremos (o alguien no quiere) que se almacenen las credenciales, sino un sistema alternativo que permite realizar determinadas operaciones.

En The Modern Guide to OAuth una buena guía que nos puede ayudar a comprender mejor la cosa, sus posiblidades y qué podemos hacer con ello.

Es bastante larga, así que no vamos a extaer apartados ni contenido y simpelmente haremos una invitación a la lectura.

Python es uno de mis lenguajes favoritos, y lo uso con frecuencia para algunas tareas. Sin embargo, hay en otras en las que no es lo más adecuado y de este tema hablan en el artículo que traemos hoy.

En Programming language Python is a big hit for machine learning. But now it needs to change hay algunas ideas interesantes sobre lo que Python debería ser en el futuro.

Desde luego, está claro que es un gran éxito en los temas relacionados con la inteligencia artificial y aprendizaje autómatico y se ha convertido en un lenguaje muy popular.

Sin embargo, nos dicen, no se puede ejecutar en el navegador, y tampoco en el teléfono móvil. Y tampoco hacen juegos con él.

Python is the top language according to IEEE Spectrum’s electrical engineering audience, yet you can’t run Python in a browser and you can’t easily run it on a smartphone. Plus no one builds games in Python these days.

Otra limitación, es la de la dificultad para construir y distribuir aplicaciones de escritorio, sobre todo si tienen interfaces gráficas.

“It’s an embarrassing admission, but it’s incredibly awkward to use Python to build and distribute any applications that have actual graphical user interfaces,” he tells ZDNet.

Mucho del problema tiene que ver con la dificultad de cambiar el lenguaje sin causar problemas en algunos de los módulos más populares como numPy. Y por lo tanto, enfadar a mucha gente.

Ronacher says Python has been “stuck like this for many years”. Time and again, efforts to “kill the global interpreter lock” fail because it would cause troubles for extensions like NumPy.

Interesante.

Si nuestra aplicación tiene que procesar datos de los usuarios, tenemos un problema: tradicionalmente ha sido una vía de ataque que ha tenido muchos éxitos.

En Allow arbitrary URLs, expect arbitrary code execution nos cuentan el caso de vulnerabilidades en aplicaciones de escritorio por no validar suficientemente los datos de entrada, que son interpretados como URLs y manejados por el sistema operativo.

In this post, we show code execution vulnerabilities in numerous desktop applications, all with the same root cause: insufficient validation of user input that is later treated as a URL and opened with the help of the operating system.

Esto puede llevarnos a ejecución de código, fundamentalmente por dos caminos: atacar el comportamiento del sistema operativo ante determinados esquemas y extensiones de ficheros; y explotando vulnerabilidades de aplicaciones de terceros que gestionan algunas de estas peticiones.

Con estas premisas en el artículo se hace un repaso de varios fallos de seguridad en el manejo de estas URLs, en aplicaciones como el cliente de Nexcloud, Telegram, VLC y otras aplicaciones.

Termina con algunos consejos para los desarrolladores, tanto de sistemas operativos (no montar directorios remotos, por ejemplo), entornos y aplicaciones (validar las URLs, y ser cuidadosos cuando registremos nuestra aplicación como gestor de URLs o extensiones).

Interesante.

Uno de los consejos que siempre se da con respecto a la criptografía es no meterse en ese negociado sin experiencia (“don’t roll your own crypto”).

De este tema se habla en Actually, You Are Rolling Your Own Crypto.

Así que solemos preocuparnos por los algoritmos y, sin embargo, lo cierto es que solo son una parte del tema. Luego hay que tener en cuenta más aspectos, que podrían tener consecuencias nefastas.

What they might not realize is that the algorithms themselves are the first in a series of traps, each of which can have catastrophic effects on the outcomes of cryptography use.

La elección de los algoritmos, su uso y su inclusión en otros procesos (protocolos) también tienen sus dificultades.

Algorithm selection, algorithm use, and protocol creation are all potential pitfalls that await once you’ve decided not to create your own algorithm.

En cuanto a la selección de algoritmos, podemos empezar por la diferencia entre criptografía simétrica y asimétrica, y dentro de ellas las distintas opciones disponibles.

There are a massive number of existing algorithms that do a wide range of things. The encryption space, for example, can first be broken down into symmetric and asymmetric. Each of those categories has a number of usable algorithms, and many of those algorithms have some other number of usable modes.

No sólo eso, no hay que olvidar que esos algoritmos pueden quedarse obsoletos con el tiempo (y por eso no comentaremos nada aquí sobre ellos).

En cuanto al uso, comenta que hay que tener cuidado con las opciones, como se inicializan… sin olvidar que hay que tener en cuenta nuestro contexto y luego elegir las implementaciones.

So you’ve chosen a secure algorithm in a secure mode that fits your operational environment. Now you need an implementation, no problem!…

Y ahora, hay que usarlos dentro de un proceso que permite algún tipo de comunicación segura: un protocolo. Es posible que no haya ninguno que se adapte bien a nuestro caso y entonces comienzan nuestros problemas.

your crypto is probably going to be deployed inside a protocol scheme that enables secure communication. When it comes to protocols, there is rarely an off-the-shelf solution. As a result, developers are often forced to implement their own protocols, even though they understand it is risky.

Muchas veces serán modificaciones de otros conocidos, pero que necesitamos adaptar a nuestras necesidades. Y aquí podríamos estar introduciendo debilidades, o suponiendo propiedades que no se cumplirán en el nuevo contexto.

They frequently need to be modified to meet the constraints of a particular operating environment. What’s often overlooked is that even small deviations to the designs can completely invalidate a security argument. What’s more, the threat model under which the original protocol was designed may not be valid for the environment in which it is deployed.

El consejo sería utilizar los bloques predefinidos más grandes posibles que se adapten a nuestras necesidades. Primitivas de alto nivel, protocolos ya desarrollados y, en general, algo que sea de uso amplio y que no tenga muchas opciones para configurarlo.

always use the biggest pre-built building blocks possible that meet your needs. For primitives, you can consider using the highest level interfaces of a library such as NaCl. For protocols, see if something such as an existing TLS implementation will meet your needs. In general, something widely used and with fewer configuration choices will be harder to misuse than something highly configurable.

Interesante.