Mejorar las contraseñas en empresas

En How Companies Can Beef Up Password Security dan algunas ideas sobre la mejora de la calidad de las claves en empresas. Se trata de una entrevista a Thomas H. Ptacek. Me quedo con un par de párrafos:

Sobre los hashes para almacenar contraseñas, no hay que olvidar que uno de sus objetivos es que no sean muy rápidos de calcular: eso no supone un problema para el usuario porque no le frena demasiado y lo es para un hipotético atacante.

Well, that’s the opposite of what you want with a password hash. You want a password hash to be very slow. The reason for that is a normal user logs in once or twice a day if that — maybe they mistype their password, and have to log in twice or whatever. But in most cases, there are very few interactions the normal user has with a web site with a password hash. Very little of the overhead in running a Web application comes from your password hashing. But if you think about what an attacker has to do, they have a file full of hashes, and they have to try zillions of password combinations against every one of those hashes. For them, if you make a password hash take longer, that’s murder on them.

Y otro sobre el proceso de aplicar un hash repetidas veces:

– Can you explain in layman’s terms what it is that makes a password hash like Bcrypt take so much longer to crack?

Ptacek: It’s similar to if you said, let’s take SHA-1 password, but instead of just using SHA-1, let’s run SHA-1 on itself thousands of times. So, we’ll take the output of SHA-1 and feed it back to SHA-1, and we’ll do that thousands and thousands of times, and you’ll only know if your password hash is right, when you look at the result of that 1,000th SHA-1 run. So, in order to make that password hash work, you have to run the algorithm 1,000 times for each guess. That’s roughly the tactic that the modern, secure password hashes take. These are algorithms that are designed so that you can’t arrive at the result without lots and lots of work. I mean, we’re talking about 100 milliseconds [one-tenth of a second] worth of work on modern hardware to get the results of a single password attempt.

El código peor… el que hacen los gobiernos

En Study
Confirms The Government Produces The Buggiest Software
hablan del tema
del desarrollo de aplicaciones analizando un conjunto de aplicaciones:

In a talk at the Black Hat Europe security conference in Amsterdam later this week, security researcher and chief technology officer of bug-hunting firm Veracode Chris Wysopal plans to give a talk breaking down the company’s analysis of 9,910 software applications over the second half of 2010 and 2011, automatically scanning them for errors that a hacker can be use to compromise a website or a user’s PC. And one result of that analysis is that government software developers are allowing significantly more hackable security flaws to find their way into their code than their private industry counterparts.

E inmediatamente:

According to Veracode’s analysis across industry and government, fully
eight out of ten apps failed to fully live up to the company’s security
criteria. But breaking down the results between U.S. government and private
sector software, the government programs, 80% of which were built for
federal agencies rather than state or local, came out worse. Measuring its
collection of apps against the standards of the Open Web Application
Security Project or OWASP, Veracode found that only 16% of government web
applications were secure, compared with 24% of finance industry software
and 28% of commercial software. And using criteria of the security-focused
education group SANS to gauge offline applications, the study found that
18% of government apps passed, compared with 28% of finance industry apps
and 34% of commercial software.

Como casi siempre, el diablo está en los incentivos (quién hace qué, por qué y cuáles son sus motivaciones):

Those incentives have led to government bugs persisting even as the rest of the industry starts to clean up its act, says Veracode’s Wysopal. While SQL injection and cross-site scripting vulnerabilities have have dropped off in private industry over the last two years, they’ve remained statistically flat for governments.

A mi me recuerda los estudios aquellos sober las políticas de claves en los sitios web que comentamos en Contraseñas, usabilidad y uso: los sitios web gubernamentales eran los que tenían políticas más restrictivas, sin mucha evidencia de que eso mejorara la seguridad.

Pagar la ‘deuda técnica’

Me pareció muy sugerente el concepto y quiero dejarlo anotado aquí: En ¿Como pagar la “deuda técnica”? se hace la analogía económica con las ‘hipotecas’ en que incurrimos cada vez que aceptamos una chapuza o una mala solución en nuestros sistemas, pensando que ya lo arreglaremos más adelante. Apuntan a la entrada de la Wikipedia, Technical debt y se puede leer algo más sobre el tema en Technical Debt

Seguridad de los productos relacionados con la seguridad

Me suena haberlo comentado alguna vez, pero no lo encuentro. En How To Secure a Security Product And Whose Bug Is It, Anyway? se comenta sobre el tema que aparece de vez en cuando por ahí: no todas las empresas que desarrollan productos de seguridad la tienen en cuenta en sus desarrollos. No es raro ver un antivirus, un cortafuegos o cualquier otra herramienta de este estilo en las bases de datos de vulnerabilidades, mostrando despistes en programadores (y sus empresas) que deberían ser más conscientes que el programador medio de los problemas que puede haber.

En el artículo se comentan las prácticas que deberían seguir estas empresas y casi acaba:

How does this arguably incomplete list differ from what other (non-security) software vendors should do? From a pure security perspective, it really doesn’t, as any product running on a computer – regardless of its declared function – can provide an entry point for attackers, although products running with higher privileges (which security products often are) are more risky. But from the business perspective, security software vendors will be smart to go an extra mile. Security is their sole functionality and their only purpose. It’s hard to convince a customer that you will secure their system if you can’t seem to be able, or willing, to secure your own product.

¿Qué empresas contribuyen más al software libre?

Internet nos ofrece un mundo de datos por explorar. Teniendo en cuenta que son aproximaciones (porque los datos no son completos, o tienen sus propias dinámicas, …) podemos aprender algunas cosas. En este caso en Evaluating Open Source Participation by Email Traffic nos hablan de una recopilación de listas de correo de proyectos de software libre y un análisis sencillo, basado en el origen de los mensajes (buscando los dominios de los mails corporativos de algunas empresas) que nos da algunas ideas de quién y cuánto ha contribuido (a través de la participación de sus empleados en las listas de correo).

Además de los datos sobre algunas empresas conocidas, podemos ver que gmail es el servicio favorito de los desarrolladores de software libre (gana por goleada a hotmail y Yahoo!) y también podemos hacer nuestras propias indagaciones: por ejemplo participación de gente del dominio unizar.es.

Esta entrada claramente era dudosa entre esta bitácora y la otra pero como el otro día puse allí la entrada Sensores como nosotros y aquí se habla un poco de software libre, he preferido ponerla aquí.

Algunas métricas de seguridad en Oracle

En The Good, The Bad, And The Ugly: Stepping on the Security Scale (pdf) podemos leer algunas ideas de Mary Ann Davidson, sobre las métricas y cómo las utilizan en Oracle para mejorar la seguridad. Que nadie espere grandes detalles ni metodologías profundas, pero si una idea de cómo se enfrentan en una empresa de gran tamaño y los consejos y puntos a los que hay que prestar atención.