Traemos hoy una guía sobre control de acceso. Se trata de Approaching Access Control on the Web y nos proporciona una panorámica de las distintas aproximaciones para el control de acceso en la web.

Prometía hablar más de estos temas, pero hasta ahora no ha habido novedades.

En Email encryption is here! Use STARTTLS everywhere! nos hablan de la inciativa de la Electronic Frontier Foundation sobre el uso de STARTTLS everywhere!. Se trata de un mecanismo de cifrado basado en la infraestructura (esto es, las máquinas se conectan entre sí utilizando protocolos cifrados) y que, por lo tanto, es sencillo de utilizar por parte de los usuarios. No es tampoco perfecto, puesto que no se trata de un sistema de cifrado entre receptor y emisor, pero es un compromiso suficientemente bueno, dada la dificultad de otros métodos (¿alguien ha probado a enviar correo cifrado alguan vez?).

Ya hacía tiempo que no hablábamos de aleatoriedad. En esta ocasión es Efficiently Generating a Number in a Range hablan de la eficiencia (que no podemos despreciar) a la hora de generar números aleatorios.

Se hace un análisis de los factores principales de coste,

But, perhaps surprisingly, the performance of your randomized algorithm may hinge not on the generation scheme you chose, but on other factors. In this post (inspired by and building on an excellent recent paper by Daniel Lemire), we’ll explore a common source of overhead in random number generation that frequently outweighs PRNG engine performance.

Aunque sabemos que la generación es costosa, no siempre es el principal motivo:

If your randomized algorithm isn’t running as fast as you’d like and the bottleneck seems to be generating random numbers, somewhat counterintuitively the problem might not be with your random number generator!

Luego siguen algunos métodos y medidas que probablemente solo interesarán a las personas con inclinaciones más técnicas. Aunque, cuidado, modificar este tipo de algoritmos y obtener el resultado deseado (aleatoriedad razonable) es algo que debe hacerse sólo cuando tenemos muy claro lo que tenemos entre manos.

Me gusta mucho leer buenas prácticas aplicadas a diversos cometidos: normalmente las propone gente que ha trabajado un tema, nos pueden servir de recordatorio y, a veces, aprendemos nuevas ideas o enfoques.

En este caso hablamos de 10 GitHub Security Best Practices y las prácticas son:

• Nunca almacenar credenciales en un repositorio (como código o en configuraciones).
• Eliminar datos delicados de nuestros ficheros y la historia del repositorio.
• Reforzar el control de acceso.
• Añadir un fichero SECURITY.md
• Validar las aplicaciones de forma cuidadosa.
• Añadir pruebas (tests) de seguridad.
• Seleccionar la forma adecuada de alojar el código.
• Rotar las claves SSH y los tokens de acceso.
• Crear nuevos proyectos teniendo en cuenta la seguridad.
• Auditar cualquier código que importemos a la plataforma.

Lo han publicado en forma de chuleta, en [PDF] Cheat Sheet: 10 GitHub Security Best Practices.

El mundo de la seguridad informática es inabarcable. Por su extensión, que se amplía continuamente, pero también por su duración: todavía podemos encontrar programas vulnerables con fallos que se conocen desde hace quinquenios. Luego, otras veces olvidamos que aunque nuestro lenguaje favorito no sufra esos problemas directamente, puede que los tenga por la vía de los lenguajes en los que se ha desarrollado la infraestructura subyacente (el propio compilador/intérprete, las bibliotecas, el sistema…).

Por eso nos viene bien leer (y recordarlos) en artículos como Funciones inseguras de un futuro pasado. Habla de las funciones peligrosas a vista de pájaro y sugiere la utilización de las herramientas actuales para detectar y evitar esos fallos.

Pero, seguramente, seguirán apareciendo.