07.09.06

Putting money where the security is: Liability

Posted in Efficiency, IT, Legal, Security at 12:48 pm by Jens Hardings

This article in Wired by Bruce Schneier gives another hint at what some people have been arguing for a long time: Liability for software vendors. It describes how fast an organization reacts when there is money in risk. In spite of the promise to focus on security after several worm breakouts with huge financial consequences for customers, the security has not been one of the most outstanding features for Microsoft lately. In Bruce’s words:

In the absence of regulation, software liability, or some other mechanism to make unpatched software costly for the vendor, “Patch Tuesday” is the best users are likely to get.

[...]

Last week, a hacker developed an application called FairUse4WM that strips the copy protection from Windows Media DRM 10 and 11 files.

[...]

So Microsoft wasted no time; it issued a patch three days after learning about the hack. There’s no month-long wait for copyright holders who rely on Microsoft’s DRM.

You can read more about this article on this blog entry.

12.07.06

Another reason to use SSL correctly

Posted in Security at 2:52 pm by Jens Hardings

This is yet another flame to the online banking systems in Chile (and elsewhere).

The problem is as follows: apparently to make the system faster for visitors (requiring only one click), many banks make their login form available on a non-secured page. When everything works as intended, the form directs the request to an SSL-enabled page, so the transmission is effectively encrypted before your browser begins to send any data. But what happens when you get to a web-page that seems exactly like the original but that doesn’t redirect you to that SSL-enabled page? Your data goes unencrypted, probably right to the hands of someone you should not trust. You might notice this if you pay attention, but it would probably be too late and there are many ways of how to make it look as if you really did go to the bank’s web after giving away your login credentials to some unknown server on the internet.
So, how are the odds of getting to a fake bank page? Not very high, unless you get some phishing e-mail or somebody plays with the DNS resolver you use, both very simple and common activities nowadays.

Many banks are using marketing strategies to show how secure they are by giving (actually, selling) tokens for enabling 2-factor authentication. This is good for avoiding your fixed password to be captured by some keylogger (either a software or hardware keylogger). But it does not protect you from a man-in-the-middle attack like the one published on Washington Post.
Ironically, to get to the login page of my bank (Banco de Chile), you have to make an extra click. I can understand that, since not everybody who connects to the main page of the bank needs authentication or encryption, the main page is not secured. Probably most customers would not care to make one extra click (or store a bookmark so they won’t have to) in order to get to the secure login page. But in my case, even when I have to click on the link to get to a second page, that second page is also not secured by SSL, even when the most common use for that page is for logging into the customers bank account. There is not even the alternative for a security-aware customer to go to a, maybe slower but secure, login page. The only way to log in securely is to first enter a valid ID and a fake password, verify the authenticity of the server, go back to the non-secure page and assume that the second time you will also connect to the right server (which is not necessarily true). Or, you may have come across a dark and upublished way to access the server and obtain the login form.

14.06.06

Signing in on bank websites

Posted in Security at 2:19 pm by Jens Hardings

BrokenLock.gifShould I be glad for not being the only one that cares about the reckless attitude of banks with the usage of SSL? It would be preferable for the problem to be solved (since the solution is pretty much straight forward). I first wrote about the situation of chilean banks back in december 2003, and it hasn’t improved. Now I see that the same is happening in USA, with more or less the same answers.

23.01.06

OpenSSL certificado por FIPS

Posted in FLOSS, Security, Standards at 9:08 pm by Jens Hardings

Logo OpenSSLSe demoró (más del doble de lo normal) pero ya está: Newsforge nos informa de los detalles. El hecho que fuera software con disponibilidad del código fuente al parecer mostró ser un desafío mayor…

18.01.06

Votación Electrónica

Posted in Electronic Voting, Security at 5:00 pm by Jens Hardings

evoting.jpgHoy apareció una columna de Paolo en La Nación (copia local aquí por si falla el link) acerca de votación electrónica, un tema que ya he tocado antes. Paolo postula que sería beneficioso el uso de la tecnología en buena parte del proceso, incluyendo la emisión del voto. Con la salvaguarda que el proceso estaría dividido en dos partes: por un lado la autenticación, por otra la emisión del voto.

En el tema del costo no me voy a meter ahora, pero le compro el razonamiento a Paolo. No tiene por qué ser más caro, y más temprano que tarde terminaríamos ahorrando recursos. Probablemente no sean necesariamente recursos del estado los que se ahorren, pero sí habría un considerable ahorro social (el costo en tiempo, movilización y costos de oportunidad en que todos incurrimos, incluyendo vocales de mesa por supuesto). Tampoco voy a tratar el tema de la interfaz: es posible (pero ciertamente no trivial) lograr una interfaz que sea igual de fácil de utilizar que el lápiz y papel hoy en día.
Con la división del proceso en autenticación/emisión separados, de acuerdo a Paolo, se evita que el voto pierda su calidad de secreto. En realidad hoy en día, es muy fácil que alguien entre en la urna con una cámara y le saque foto a su voto con algún otro elemento que permita identificar a la persona. Yo no dudaría un instante en hacerlo si de eso dependiera la integridad física de algún familiar que fue secuestrado, por ejemplo. Paolo tiene razón en que es perfectamente posible tener un sistema que, sin ser perfecto, sea al menos tan seguro como el actual en garantizar el secreto del voto.
También coincido con que el sistema debe ser de público acceso para que todos lo revisen y auditen. Una licencia Open Source es ciertamente algo muy recomendable para eso. Pero hay un tema que se está dejando de lado: ¿Cómo puedo verificar que el sistema que veo en la urna al momento de querer emitir el voto sea efectivamente el mismo que pude auditar anteriormente?

Por lo demás, es el mismo dilema al que me enfrento cada vez que utilizo un cajero automático o un terminal de RedCompra (pago por tarjeta de débito): le estoy entregando información confidencial a un sistema que no controlo y con el que nunca antes tuve contacto ni puedo “ver sus entrañas” para saber lo que hace con la información que le entrego. En los casos del cajero o RedCompra tengo el recurso de reclamar cobros que no correspondan, pero esa solución no se pude aplicar a la votación: no puedo reclamar porque nadie (incluido yo) debe ser capaz de poder demostrar por quién voté. Ni siquiera puedo saber cuál voto del conjunto es el emitido por mi y por tanto menos si fue contabilizado adecuadamente o no.
En el caso de votación por papel yo veo perfectamente cómo se ingresa mi voto, que no queda registro de la hora en la cual se ingresó, me puedo quedar a verificar el conteo. De hecho, los apoderados son una forma organizada de hacer precisamente eso a nivel nacional de manera organizada representando a una única entidad que se hace presente en todo el proceso. Mi pregunta es: cómo se pretende lograr eso? Es una pregunta que no ha respondido nadie hasta el momento, y no tiene una respuesta fácil.

Hay quienes se dan por satisfechos con que exista una forma de verificar la contabilización de los votos (ya no se ahorran demasiados recursos y la ganancia en conocer los resultados es a lo más de un par de horas en el caso de Chile que ya es eficiente en el proceso actual). Pero eso deja abierto el tema de que el voto siga siendo secreto: basta con que el dispositivo receptor del voto mantenga un registo de la hora de cada voto para que el anonimato desaparezca. Y volvemos al tema de verificar el software para que no lo haga y el problema de determinar si el software que estamos viendo es el mismo que verificamos. Insisto: el tema no es trivial, y tampoco es tecnológico.

05.01.06

FON: Colaborando para conectarse

Posted in Legal, Security, Society at 3:40 pm by Jens Hardings

fon.jpg

Por FayerWayer: FON es una iniciativa española para compartir tu conexión a internet via WiFi. Tú abres tu conexión y a cambio puedes utilizar la conexión de los demás que se han inscrito. Esa es la primera forma, que está operacional ahora. La segunda forma (aún no funcional) incluye la posibilidad de compartir tu conexión a cambio de pago por parte de gente que la use.

Bastante interesante la iniciativa, me pregunto cuánto se demorará en que alguien tome la idea para llevarla a cabo en Chile?

Lo único que me inquieta es la responsabilidad de la conexión: qué pasa si alguien usa mi conexión para iniciar un ataque y se me responsabiliza de eso por ser el que maneja la conexión? Supongo que quedará un registro en algún servidor de autenticación, pero no se menciona nada en las preguntas frecuentes, y por lo demás en Chile las leyes son diferentes así que es otro tema.

Saber cómo funcionan los sistemas

Posted in IT, Security at 2:52 pm by Jens Hardings

En EEUU, los que están bajo la sospecha de conducir bajo los efectos del alcohol tienen derecho a conocer exactamente cómo funciona la máquina que les mide el nivel de ingesta alcohólica. Eso incluye acceso al código fuente del programa que maneja la máquina.

Pero hasta ahora los votantes no tenían derecho a saber cómo funcionaban internamente las máquinas utilizadas para la votación, supuestamente por motivos de seguridad. Será que gracias a los derechos de los borrachos se podrá saber ahora cómo funcionan las máquinas de votación?
Obviamente el que un sistema sea secreto no aumenta su seguridad. Al contrario: cuando se conoce su funcionamiento es posible corregir los errores, cosa que no ocurre cuando nadie conoce legalmente las fallas. Y los que las conocen por tener acceso al código de manera ilegal (hubo filtraciones conocidas de código desde servidores de Diebold, así que están circulando) no se van a ver afectados. El efecto es entonces justo el contrario: el sistema es menos seguro porque es fácil para los que se quieran aprovechar de él encontrar las fallas, y los que están interesados en arreglarlas no tienen acceso.

27.12.05

Internet Explorer Sucks

Posted in Security at 1:52 pm by Jens Hardings

No lo digo yo, lo dice Bruce Schneier. Yo le creo a Bruce, tengo varios de sus libros y los uso en mis clases. Definitivamente no es una persona que dice algo así sin tener buenas razones.

Y la razón es un estudio que compara la seguridad de diversos browsers. Entre otras cosas, se puede ver que para Internet Explorer hubo problemas de seguridad durante cada día de 2004 excepto 7 (del 12 al 19 de Octubre), en los cuales no existían correcciones disponibles: un 98% de “inseguridad”. Si se compara con el 7% (sobre Windows) a 15% (sobre Mac) de Firefox, es raro que haya quienes se atrevan a decir que Internet Explorer es el más seguro (aún no encuentro referencias al dichoso estudio que se menciona en la carta).

11.12.05

Votación Electrónica

Posted in Electronic Voting, IT, Security at 7:01 pm by Jens Hardings

Voto ElectrónicoHoy salió publicado un artículo sobre votación electrónica, escrito por Alexis. En ese artículo se habla sobre la (remota) posibilidad de reemplazar el voto en papel por uno “electrónico”. Me parece muy peligroso sugerir ese tipo de decisiones basados en la suposición que al agregarle tecnología al proceso necesariamente lo va a mejorar. Hay momentos en los que se debe decidir objetivamente cuál es la mejor solución.

Así que veamos un poco cuál es la situación. Generalmente, al sugerir cambios sustanciales se intenta solucionar algún problema. Y es ahí que ya aparece la primera duda: cuál es exactamente el problema que se espera solucionar?

Read more »

10.11.05

Spyware

Posted in Security at 4:55 pm by Jens Hardings

Supongamos que tenemos un software, que:

  • viene con una EULA que, al menos, induce a error sobre lo que el software hace
  • interfiere con los esfuerzos de usuarios y programas comunes, incluyendo los que revisan por virus y otras aplicaciones de seguridad, de identificarlo
  • sin mencionarlo al usuario ni obtener consentimiento, envía información sobre las actividades del usuario al creador del software
  • no provee desinstalador, ni siquiera en el sitio web del creador, a pesar que se indica lo contrario en la EULA
  • el creador tiene un desinstalador, pero se rehúsa a entregarlo salvo a usuarios individuales que siguen una larga y engorrosa serie de pasos
  • el creador realiza declaraciones a la prensa que inducen a error sobre el software

Ese software, debiera ser considerado Spyware, cierto? Pues bien, eso es justamente lo que hace el rootkit que Sony distribuye en varios de sus CDs, sobre el que ya había comentado aquí.

Más detalles:

« Previous entries Next Page » Next Page »