Archivos Mensuales: Enero 2009

Finanzas personales con Mint.com

A través de este apunte de LifeHacker he conocido Mint.com, un servicio on-line de finanzas personales.

A primera vista tiene MUY buena pinta… un interfaz cuidado, muchas funcionalidades, estadísticas que te permiten saber en qué gastas el dinero, te permite fijar alertas, notas, te avisa por correo electrónico, … un poco de todo.

Así que con una cuenta de correo electrónico que tengo para registros de este tipo me doy de alta… vamos a investigar un poco más qué es esto.

Piden cuenta de correo, una contraseña, nombre, apellido y código postal ¿?.
Una vez te has dado de alta… viene la ¿sorpresa?


Te piden directamente el usuario y contraseña de cada una de las cuentas de los bancos con los que trabajas para poder entrar en tus cuentas… esto es un poco difícilse acabó la prueba.

La verdad es que la idea es buena, muy buena… ellos tienen acceso a tus cuentas bancarias, se conectan, descargan todos tus movimientos, los categorizan, hacen los cílculos, preparan los gráficos, … y tú al día siguiente tienes toda la información actualizada, sabes en qué te gastas el dinero, puedes ver si te pasas de presupuesto, como llevas los pagos, … en dos palabras: parece perfecto.

Sólo tiene un problema… tienes que meterle el usuario y contraseña para darles acceso a tus cuentas bancarias y del phising ya hablaré otro día.

KDE 4.2 disponible

Desde el martes tenemos disponible la versión 4.2 de KDE. Como comentaba hace unos días, los traductores de KDE-ES andábamos a tope con las traducciones de KDE 4.2.

El resultado fue bueno y logramos traducir creo que el 100% de las aplicaciones que se incluirían en la release.
Por otro lado seguimos en pleno proceso de confirmación de las asignaciones de traducciones, que finaliza la semana que viene.

Respecto a KDE 4.2, tenemos el anuncio de lanzamiento de KDE 4.2 y en ese anuncio aparecen algunas de las mejoras, nuevas funcionalidades, corrección de errores…

Podeis descargar KDE 4.2 desde los sitios habituales y como siempre, habrá que esperar un poco más a que las distintas distribuciones empiecen a incorporar esta nueva versión a sus repositorios.
En el caso concreto de Debian, tenemos KDE 4 en experimental pero perfectamente instalable y funcional en Lenny (4.1) y Sid (4.2).

Robo de credenciales en Monster

El día 23 la web de empleo Monster.com anunció que se había producido un robo de las credenciales de los usuarios de su web. No dicen cómo se ha hecho… sólo que ha pasado.

Han puesto un comunicado en su web diciendo que los datos que se han robado son: id de usuario, contraseña, dirección de correo electrónico, nombre, teléfonos y lo que ellos llaman datos demográficos pero dicen que los ladrones no han conseguido los currículums… a saber.

Una de las preguntas es… ¿Cómo es que han conseguido las contraseñas? ¿Las guardaban en claro? ¿Ni siquiera un hash? (luego el MD5 se rompe pero eso es otra historia).

Para tranquilizarnos nos dicen que en su nueva web, la seguridad es primordial… 😛

En España, quiero pensar que, un problema de estos llevaría asociada una sanción de la Agencia Española de Protección de Datos. Si se trata sólo de esos datos, supongo que estarían clasificados como de nivel bajo pero a saber qué es exactamente lo que se ha perdido.

A los que tengais vuestros datos en Monster… ya podeis correr a cambiar las contraseñas de vuestros usuarios… y eso si no compartís cuenta de correo-e/contraseñas entre Monster y otros sitios… Una práctica tan poco recomendable como habitual es la de compartir datos de registro (correo-e y contraseña) en varios/muchos/todos los sitios web.

¡A cambiar contraseñas tocan!

Confirmando asignaciones de KDE-ES: 4-febrero

La semana pasada publicaba el ya típico mensaje de renovación de asignaciones en la lista de traductores de KDE-ES.

La idea es sencilla… se ponen TODAS las asignaciones en espera de confirmación, damos un plazo y la asignación que no se confirme queda libre, por asignar, disponible para cualquier traductor que se ofrezca a encargarse de la traducción de ese paquete.
Realizamos ese proceso periódicamente para mantener actualizada la lista de asignaciones.

El día 4 de febrero es el día. A partir de entonces es probable que algún paquete quede disponible y sea la oportunidad para encargarse de traducir un paquete de traducciones de aplicaciones y/o documentación de KDE.

¿Te animas? Los ficheros a traducir están en el SVN de KDE pero ponte antes en contacto conmigo para poder coordinar la asignación de traducciones de forma que no dupliquemos esfuerzos y tengamos a más de una persona traducciendo el mismo paquete.

Vuelve Conficker y los problemas de no parchear

No es nuevo el problema, Microsoft publicaba el parche a finales de octubre en una distribución de esas críticas fuera de ciclo. El hecho de que hagan una distribución fuera de ciclo debe ser motivo para tomárselo en serio y en muchas de las grandes redes se iniciaron los procedimientos para actualizar e instalar dicha actualización cuanto antes.

En menos de un mes ya teníamos al menos un virus detectado y dando guerra. El Conficker se hizo presente. Como siempre, las primeras informaciones eran vagas (conficker, Gimmiv, ¿otro?) y había que fiarse de la intuición y experiencia para identificar como un virus determinados patrones ya sea en el tráfico de la red, en las incidencias de los usuarios, …

A los días las primeras infecciones ya eran masivas. Grandes redes infectadas por un gusano que se introducía en todas las máquinas que no tenían el parche aplicado (y habían reiniciado tras la actualización), los fabricantes de antivirus no daban con la tecla para limpiar las infecciones y sacaban varios patrones de firmas al día tratando de dar con la tecla, las redes mal segmentadas se bloqueaban con el tráfico que el gusano generaba, … caos.

Pasa el tiempo, los administradores (que no lo hicieron a tiempo) van parcheando, los fabricantes de antivirus generan y distribuyen las firmas del virus y parece que todo vuelve a la normalidad… pero no.

A principios del mes de enero, una variante de conficker vuelve a las redes y caen de nuevo las grandes redes. Cuentas de usuario bloqueadas, tráfico que colapsa los routers, los foros y webs echando humo, … en medio de la confusión Panda la caga con un falso positivo y hace que los síntomas de un virus se mezclen con los síntomas del falso positivo de Panda… vuelta a investigar, …

Esta vez la variante es más lista y no sólo se propaga con un gusano típico como en noviembre/diciembre… ahora también lo hace a través de los recursos compartidos, los discos USB, … la Ingeniería Social, crackeando contraseñas débiles usando diccionarios rudimentarios, … vuelta a investigar, vuelta a poner parches (¿pero… no estaban puestos ya? ¿Es que la gente no aprende?).

No se si alguna vez se ganará la guerra a los creadores de virus y malware. Me da que no, siempre vamos al menos un paso por detrás… generando parches y antivirus.

Aun quedan administradores que no ven la actualización de parches de seguridad como algo crítico de sus sistemas (si funciona no lo toques). El miedo a que algo deje de funcionar por instalar un parche sigue pesando más que el miedo a que toda la red deje de funcionar y no puedan dar servicio por una infección masiva (¿?) pero el caso es que los parches no se instalan… o no se hace a tiempo.

¿Qué cuesta más? ¿Mantener un parque de máquinas actualizadas y con los parches de seguridad y antivirus al día o quedarte sin servicio, sin previo aviso, tener que parchear a toda prisa y sin hacer las pruebas pertinentes el día de la catástrofe?

La Gestión de la Seguridad de la Información suele recomendar eso de parchear…

Traducciones para KDE 4.2

Llegan las prisas…
Se acerca la fecha del etiquetado de KDE 4.2 y los traductores de KDE-ES estamos a tope.

Todo lo que no tengamos listo no saldrá en KDE 4.2 y tendrá que esperar a la siguiente versión. Andamos con asignaciones de traducciones de emergencia…

Nuestras estadísticas no suelen ser malas… de hecho no lo son pero es cierto que deberíamos darle un empujón, entre otras cosas, a la documentación que es lo que peor llevamos siempre

Lo que si es cierto es que hace unos años eramos los mejores o los segundos mejores y ahora ni siquiera estamos en el Top-10 de equipos de traducción. Algo falla. 🙁
Ahora mismo los turcos están más cerca de alcanzarnos a nosotros que nosotros de alcanzar a los brasileños…

Pasa que, por la razón que sea, la gente no mantiene los paquetes que tiene asignados y al final nos pilla el toro. La gente trabaja, estudia, tiene otras obligaciones… otras aficiones y claro las traducciones no siempre están en primer lugar.

Tendremos que encontrar nuevas formas de motivar a los traductores actuales y de atraer a nuevos traductores. ¿A alguien se le ocurre alguna estrategia?

¿Cómo lo hacen los ucranianos? ¿Y los gallegos?
Mi enhorabuena a los ganadores 🙂

Datos biométricos en el pasaporte

¿Hasta dónde van a llegar para controlarnos? ¿Qué es lo que hay que proteger? ¿Dónde está el límite de la privacidad? ¿Cómo de intrusivos deben o pueden ser los sistemas de autenticación y seguridad? ¿Cuánto estamos los usuarios dispuestos a tragar? ¿Ni una protesta? ¿Nadie se queja?

La Eurocámara ha aprobado una medida que obliga a la inclusión de datos biométricos en los pasaportes.
¿Incluirá esta medida también los requisitos mínimos de seguridad que deben incluir los pasaportes para garantizar nuestra privacidad?

Tenemos dispositivos RFID y datos biométricos en los pasaportes… mala mezcla… los vendedores de carteras y fundas con jaulas de faraday se van a hartar a vender.

¿Han valorado el coste de lo que pretenden proteger y el coste de la implantación de esas medidas?

25 errores más peligrosos al desarrollar software

Leo en MITRE una lista donde detallan los 25 errores más peligrosos de la programación y creo que es una buena referencia que puede tomarse como una checklist, una lista a comprobar cuando los desarrolladores están realizando su trabajo.

Como dicen en su introducción, esa lista puede servir también de referencia a los educadores y profesores de programación, ingeniería del software, … para que los alumnos conozcan también estos típicos errores que generan vulnerabilidades peligrosas y tópicas.

Una breve enumeración:

  • No validar las entradas. (CWE-20)…
  • … y no formatear (o escapar) adecuadamente las salidas. (CWE-116).
  • Cuidado con la inyección de SQL. (CWE-89).
  • Cuidado con el Cross-site scripting (XSS). (CWE-79).
  • Atención a la ejecución de comandos. (CWE-78).
  • Falsificaciones de peticiones en sitios cruzados. (CWE-352).
  • Transmisión de información sensible en claro. (CWE-319).
  • Race conditions la expresión en español típica (condición de carrera) no es una traducción que me guste en exceso. (CWE-362).
  • Cuidado con la información de los mensajes de error, que no den más información de la cuenta. (CWE-209).
  • Desbordamientos de buffer. (CWE-119).
  • Cuidado con el almacenamiento de datos críticos, no sea que están accesibles. (CWE-642).
  • Cuidado con las rutas y ficheros, exposición de más información de la cuenta o acceso a rutas no necesarias. (CWE-73). Este me parece a mi un error más de configuración de sistemas que de desarrollo puro y duro pero es interesante. Es sencillo encontrar ejemplos de máquinas potencialmente vulnerables.
  • Control sobre el directorio de búsqueda de recursos. (CWE-426).
  • Generación de código. (CWE-94). Veo este error muy relacionado con los de validación de entradas y salidas… pero bueno, así comprobamos dos veces. 🙂
  • Cuidado con la reutilización. (CWE-494). ¡Para qué volver a reinventar la rueda…? pero eso sí, asegurémonos de que la rueda es redonda antes de ponerla.
  • La basura de un hombre es el tesoro de otro. (CWE-404).
  • Inicializa correctamente las variables y objetos. (CWE-665).
  • Cálculos incorrectos. (CWE-682). También relacionada con la validación de las entradas y el desbordamiento de buffer.
  • Control de acceso ineficaz. (CWE-285).
  • Utilización de algoritmos criptográficos débiles o rotos. (CWE-327).
  • No incluir contraseñas en el código. (CWE-259).
  • Asignación de permisos inseguros para recursos críticos. (CWE-732). ¿No es esto demasiado parecido al control de acceso ineficaz del que hablaban antes?
  • Aleatoriedad previsible. (CWE-330).
  • Utilización de más permisos de la cuenta. (CWE-250). Este también es un problema habitual. Muchos desarrolladores se acostumbran a desarrollar con usuarios privilegiados y generan código que requiere esos privilegios para ejecutarse cuando no hay necesidad real.
  • Confiar la seguridad del servidor al clientes. (CWE-602).

Se trata de una lista, unas recomendaciones muy útil para mejorar el desarrollo seguro y generar herramientas y programas con menos vulnerabilidades.
No tenemos por qué estar de acuerdo con todas las cosas que aquí dicen… pero desde luego que son cosas interesantes a tener en cuenta por los desarrolladores.

¿De quién nos fiamos?

Gracias al apunte de Enrique Dans en el que habla de el valor de ser la opción por defecto me acuerdo del apunte que yo publicaba aquí el otro día sobre el ataque a los certificados con MD5. No es exactamente lo mismo pero sí está relacionado.

En ese apunte comentaba el hecho de que los proveedores de navegadores web y sistemas operativos los que de manera habitual incluyen en las configuraciones predeterminadas un conjunto de certificados de CAs que ellos deciden que son de confianza, sin más.

CasiNadie desconfía de esos certificados que nuestros navegadores nos dicen que son de confianza pero dudo que mucha gente compruebe que lo son y simplemente nos fiamos.
Si el navegador dice que sí, es que sí.

La seguridad es una cuestión de confianza.

Los usuarios ponemos la seguridad de los accesos a nuestro banco, la de nuestras compras online, los billetes que compramos, nuestras transferencias de datos personales, … en fin, todas las idas y venidas de nuestros datos y los datos en sí en las manos de Microsoft y de Firefox principalmente y no sólo eso, sino que luego se permiten el lujo de implementar medidas y decir que, los sitios que no utilizan certificados de los que ellos dicen que son de confianza pueden ser peligrosos, falsos, maliciosos, …

Ahora bien… ¿Sería factible hacer que los usuarios tuvieran que comprobar uno a uno la validez de todos certificados de los sitios web a los que se conectan? ¿Cuantos no pulsarían en “aceptar” directamente, sin preguntar ni comprobar nada?

Hay que valorar, si decido que mi proveedor de software decida por mi qué sitio es de fiar y qué sitio no o bien me dedico a comprobar todos y cada uno de los sitios a los que me conecto como si ninguno fuera confiable.

Al final la seguridad es una cuestión de confianza.

Un TBR-160s para mi HF9V

Estas fiestas, entre otras cosas me han regalado (¡muchas gracias!) esto:

 

No, no es sólo un muelle… que también.

Se trata de una bobina y un par de condensadores (digamos un filtro, resonador, como lo queráis llamar) de forma que se consigue que la HF9V pueda funcionar en la banda de 160m (1.8MHz), la top-band.

Ahora a esperar a poder subir al tejado… porque creo que hoy no es el día.

 

¡Nos escuchamos en 160m!

73