Si has estado atento a las noticias de informática en los últimos meses seguramente has oído/leído algo sobre Superfish. Con la intención de ofrecer productos similares a los que los usuarios supuestamente podrían estar interesados Lenovo introdujo una herramienta para interceptar el tráfico web (y, en particular, el tráfico cifrado).

Traigo aquí un resumen en A third-party, man-in-the-middle proxy used by Superfish is also used in other apps donde nos alertaban. No solo de lo mala que era la idea en sí sino también, claro, de las consecuencias laterales (y no previstas): que otras aplicaciones traten de sacar partido de este ‘truquillo’.

La explicación del modo de funcionamiento, un proxy que se colocaba entre nuestra conexión y los sitios que queríamos visitar:

Superfish uses a man-in-the-middle proxy component to interfere with encrypted HTTPS connections, undermining the trust between users and websites. It does this by installing its own root certificate in Windows and uses that certificate to re-sign SSL certificates presented by legitimate websites.

La utilización de un certificado común para todos los sistemas:

Security researchers found two major issues with this implementation. First, the software used the same root certificate on all systems and second, the private key corresponding to that certificate was embedded in the program and was easy to extract.

Y, finalmente, la utilización de componentes de terceras partes para toda esta maniobra, lo que haría posible su utilización por parte de otros programas

But it gets worse. It turns out Superfish relied on a third-party component for the HTTPS interception functionality: an SDK (software development kit) called the SSL Decoder/Digestor made by an Israeli company called Komodia.

Para eliminarlo hay instrucciones en Superfish, Komodia, PrivDog vulnerability test (updated again!) y también la propia Lenovo proporciona herramientas: SuperFish Uninstall Instructions.

A lo mejor lo más directo sería borrar el sistema e instalar uno limpio (con la ventaja de que, seguramente, quitaríamos otras cosas que no sean tan peligrosas, pero puedan ser molestas o poco convenientes).

Ya hemos hablado algunas veces de confianza por aquí y siempre conviene recordar el clásico Reflections on trusting trust y uno más reciente del que hablábamos en La confianza.

Recientemente hemos visto alguno de los problemas de la biometría: una vez que te roban, no puedes cambiar de huellas dactilares 5.6 million reasons fingerprints shouldn’t be used as passwords

Este verano se celebró el Black Hat USA 2015 y entre las presentaciones disponibles en la web acabo de ver una que habla de más problemas: [PDF]Hidden Risks of Biometric Identifiers and How to Avoid Them donde el autor hace una buena presentación del tema.

Según él, los riesgos son:

• Confiabilidad de la biometría la percepción que tenemos de ella.
• Falta de discusión sobre las consecuencias de los errores.
• Irreversibilidad de los datos biométricos y sus implicaciones.
• Nuestros datos biométricos pueden ser obtenidos sin nuestro consentimiento
• Nuestro comportamiento puede delatarnos - a veces de manera incorrecta
• Proporcionar nuestros datos biométricos y comportamentales puede llegar a ser obligatorio (al menos, de facto).
• Ladrones de datos biométricos y agregadores

Hace algún tiempo comentamos las “Guías sobre biometría del INTECO” con algunos enlaces más.

Hoy traemos un informe sobre seguridad de datos en las empresas, patrocinado por Oracle: [PDF] DBA-Security superhero lo que más me ha gustado (o llamado la atención) es una de las últimas gráficas. Concretamente la figura 32: en ella podemos ver que casi un 50% de los que respondieron a la encuesta actualizan los parches críticos dentro del ciclo o en el siguiente. Lo que nos deja con algo más del 50% que irían con un retraso de más de 9 meses y un nada despreciable 15% que no actualizan nunca o se encuentran en otra situación.

Ya hemos hablado de Las actualizaciones o en Los parches hay que aplicarlos.

Hace mucho que no se habla demasiado de compiladores. Sin embargo, ya lleva entre nosotros una temporada The LLVM Compiler Infrastructure que es una plataforma para desarrollar un compilador reutilizable que, además, permitiría la construcción de compiladores no libres sobre su infraestructura (lo que lamentaba Richard Stallman en Re: clang vs free software.

En todo caso, para los amantes de la velocidad y la mejora la competencia es buena y, en ese sentido, es posible que merezca la pena darle una oportunidad para algunos proyectos.

En todo caso, traigo aquí Defending GCC considered futile donde Eric S. Raymond donde hace autocrítica sobre el GCC:

The reason has nothing to do with any philosophical issue but merely the fact that compiler technology has advanced significantly in ways that GCC is not well positioned to exploit.

En parte refuerza el argumento anterior, la competencia nos hace reconsiderar algunas posturas; por otra parte, iniciar un proyecto nuevo nos libera de decisiones pasadas.

Interesante, aunque no te intersen para nada los compiladores.

Si alguien nos preguntase sobre si la aletoriedad es importante en seguridad, seguramente diríamos que sí. Si luego nos preguntaran cuánta atención habíamos dedicado a ella en nuestros proyectos tengo serias dudas sobre las respuestas. En este sitio se nos van acumulando ya las lecturas sobre el tema, pero siguen apareciendo nuevas. Y nos gusta referenciarlas.

Ahora es The Role of Randomness in Online Gambling. En este caso el artículo me ha gustado porque no incide tanto en la parte más teécnica como en los aspectos relacionados con el juego y los jugadores.

Sobre la percepción de la necesidad:

We intuitively recognize that, if the chance element of the game was not truly random—and if some players had knowledge of the non-randomness—then informed players would have an unfair advantage over uninformed players.

Sobre la forma de medirla:

Often randomness is asserted through the results of statistical analysis. Software like Dieharder will take a sample of output from a supposedly random source and identify statistically improbable outcomes. The result is confidence (not proof) that a given result set is random.Predictability has to do with whether or not the outcome of a random event can be known in advance (partially or completely).

No todo es aleatorio todo el rato:

Consider poker: there is exactly one random event in a game of poker. The deck is shuffled randomly. That’s it. The rest of the game is down to the actions of the players.

Últimamente hemos hablado de aleatoriedad en.

Números aleatorios seguros en Java

Generador de números aleatorios de Intel