Otra historia que no merecería mayor comentario sino fuera porque demuestra que incluso las empresas que se dedican a la seguridad hacen las cosas mal de vez en cuando: RSA asks for plaintext Twitter passwords on conference reg page. La realidad nos demuestra que es difícil (muy difícil) hacer bien las cosas en el contexto que nos movemos hoy en día: a lo mejor subcontratas una parte de tu proceso y quien lo hace no está preocupado por estos detalles, o se dedica a ello alguna parte de la empresa cuyo cometido no es tan técnico y no prestan atención a esos detalles, …. O directamentelos de marquetin deciden que hay que hacerlo así.

¿Lo mejor de todo? Los asistentes, también gente interesada en la seguridad y que en un número no despreciable escribieron sus credenciales sin mayor problema.

Muchas veces se utiliza la palabra principios como algo grandilocuente y altisonante para justificar casi cualquier cosa. En el contexto de seguridad (y seguramente en la vida también) los principios deberían ser normas o reglas de caracter general que nos permiten tomar decisiones y actuar cuando no tenemos otras normas más claras y directas. Serían las que nos permiten pensar en los problemas de los que todavía no somos conscientes, o afrontar los que ya conocemos pero para los que hemos de adoptar una aproximación más o menos consistente.

En este caso tenemos The Security Principles of Saltzer and Schroeder.

This kind of arrangement is accomplished by providing, at the higher level, a list-oriented guard whose only purpose is to hand out temporary tickets which the lower level (ticket-oriented) guards will honor

Los principios serían:

• Economía del mecanismo. Esto es, mantener el sistema tan pequeño y simple comoo sea posible.
• Por defecto, fallar de forma segura. Basar las decisiones sobre acceso en lo que está permitido, en lugar de lo que está prohibido. De esta forma, si algo no está permitido por error es mejor (desde el punto de vista de la seguridad) que si está incorrectamente admitido.
• Mediación completa. Esto es, siempre comprobar la autorización antes de conceder el derecho.
• Mínimo privilegio. Tener permiso exclusivamente para hacer lo que necestia nuestro trabajo.
• Mínimo común mecanimo. Minimizar la cantidad de información y otros artefactos compartidas entre diferentes usuarios o de la que dependen muchos usuarios.
• Separación de privilegios. Cuando sea posible, un mecanismo de protección que necesita dos claves es más robusto y flexible que uno que sólo requiera una.
• Diseño abierto. El diseño no puede ser secreto y la protección no debería basarse en el desconocimiento del atancante.
• Sicológicamente aceptable. Si lo que se propone no entra en nuestros esquemas mentales puede que lo aceptemos, pero terminaremos tratando de saltarlas, aligerarlas o evitarlas.

Vale la pena leer el artículo porque utiliza ejemplso de la saga de películas de Star Wars.

Y vale la pena recordar los principios para cuando tengamos dudas sobre cómo realizar alguna tarea para la que no tenemos las reglas claras del todo.

Los ejemplos de código son una fuente de alivio cuando solucionan nuestro problema y una fuente de disgustos cuando no entendemos muy bien lo que tenemos entre manos (o el que nos proporciona el código no entiende muy bien lo que tiene entre manos). Todavía peor es cuando el código mal hecho aparece en fuentes de referencia como pueden ser libros o tutoriales (o incompleto, que es algo que pasa muy frecuentemente: no tienen en cuenta la seguridad/robustez, por ejemplo).

En este caso traemos un estudio al que hacen referencia en Computer science students mine software developer forums to teach coding practices y el artículo se puede ver en [PDF] Automatically Mining Negative Code Examples from Software Developer Q & A Forums.

Se basaron en el análisis de lenguaje natural y las preguntas realizadas por foreros que, frecuentemente, aportan un fragmento de código que falla y el mensaje de error que han obtenido.

Curioso.

Hacía una temporada que no hablábamos del tema de la aleatoriedad, que ha ido cobrando interés y relevancia en los últimos años. En esta ocasión tenemos una presentación sobre el tema, donde Ian Kilgore hace una introducción al tema y luegor presenta su propio desarrollo hardware [PDF] Yet Another (Kind Of Bad) Hardware Random Number Generator.

Interesante.

Seguimos con artículos de investigación que nos han llamado la atención. ¿Existe el estilo de programación? ¿Podemos identificar a alguien que desarrolla programas por su código? Parece que no sólo es cierto (siempre que tengamos código para comparar, claro) sino que también sería cierto con los binarios que se generan por el compilador a partir de ese código. Al menos, eso es lo que dicen en When Coding Style Survives Compilation: De-anonymizing Programmers from Executable Binaries. La preocupación de los autores se refiere a la privacidad y anonimato de los desarrolladores.

Del resumen, descompilando el código binario observan como algunas particularidades sintácticas se conservan y pueden obtenerse de nuevo:

We examine executable binary authorship attribution from the standpoint of machine learning, using a novel set of features that include ones obtained by decompiling the executable binary to source code. We show that many syntactical features present in source code do in fact survive compilation and can be recovered from decompiled executable binary.

La capacidad de atribución alcanzó un 92% de los 100 desarrolladores de una Google Code Jam:

We demonstrate this improvement on data from the Google Code Jam, obtaining attribution accuracy of up to 92% with 100 candidate programmers

Y parece robusta frente a intentos de ofuscación, intervenciones más agresivas del compilador, …

Muy interesante.