Sí sí, otra vez vuelvo sobre el tema, porque realmente es de nunca acabar. Bueno, es la fuerza que tienen las leyes comprobadas de la ciencia.

Como en muchas otras empresas, trabajamos con servidores de prueba y de producción, separados. En uno de ellos se lleva a cabo el desarrollo y testing de las aplicaciones y luego de superadas ciertas etapas se “sube” a producción, en donde el código tiene su feliz vida dentro de la aplicación real que navegan los usuarios finales.

Hoy quiero contar algo que me pasó en estos días, al intentar subir unos cambios a una aplicación, alojada en un servidor que también me toca administrar. Entre los servidores de desarrollo y producción, en este caso, hay algunas diferencias, pero no demasiado sustanciales. De hecho, no afectan para nada el desarrollo y, casi el cien por ciento de las veces, todos los cambios se limitan a una simple transferencia de archivos.

Hoy fue la excepción. En ciertos casos de uso… bueno, con algunas urls, parte de la aplicación dejó de funcionar. Vueltas y vueltas, configuración de php, investigar las reglas del mod_rewrite, url encodings… ¿qué está sucediendo?

En desarrollo todo iba perfecto, pero en producción, con ciertas combinaciones de caracteres en la url, se obtenian errores 400 alias “bad request” que, junto al 500 (“internal server error“), formaría algo así como la pantalla azul de la muerte para Apache.
Como casi todos los problemas insondables del universo que alguna vez fueron resueltos (y seguramente lo mismo pasará con los que no lo fueron aún), di en la tecla por una suerte de inspiración momentanea, o iluminación. La fuente del problema era una regla del mod_security.

Claro! En desarrollo no lo utilizamos tan severamente como en producción, y el error se veía tan genérico que ni se me ocurrió. Se me ocurrieron decenas de otras causas antes de dar con la correcta.

Ahora bien: ¿qué tiene que ver con el título de mi post? ¿Seguridad y usabilidad? ¿Dónde?

La usabilidad no es sólo de los usuarios. Hace rato que observo diariamente lo que yo llamo “usabilidad del código“, o como quieran llamarle. Se trata de la facilidad de edición de un programa, por ejemplo. En este caso, la facilidad de subir cambios a un servidor de producción.

Como en producción (o live) tenemos reglas más severas, a veces se producen este tipo de cosas inesperadas.

Para dar otro ejemplo un poco más simple: transferir archivos por ssh es un poco (mínimamente) más incómodo que por ftp liso y llano. Pero, por seguridad, nos molestamos un poco más y lo hacemos bien.

Si quisieramos que todo fuera más cómodo, deberíamos bajar nuestros niveles de seguridad. Mientras que si queremos sistemas más seguros, perdemos un poco de comodidad diaria.

La comodidad diaria no es otra cosa más que la usabilidad o, en otras palabras, esos cachitos de felicidad imperceptibles para nuestra consciencia que alguna parte de nuestro cerebro disfruta cuando todo va bien.

Y la seguridad no es otra cosa más que ponerle trabas a esa comodidad. Porque para estar más seguros tenemos que pensar más a través de todo el proceso, y pensar no nos resulta cómodo.

Hoy me encuentro con un artículo muy interesante en el blog de los amigos de Hispasec.

Resulta que una persona se hizo con las claves de las cuentas de correo de cientos de embajadores y altos mandos corporativos a través de la explotación de la red TOR.

La red TOR es un sistema de enrutamiento anónimo. Es básicamente un proxy que ofusca de tal manera el tráfico de los paquetes a través de distintos nodos alrededor del mundo que, prácticamente, es imposible rastrear el origen de un paquete. Es utilizada para navegar de manera anónima.

Si bien todo el tráfico dentro de la red es cifrado, el último tramo no lo es. Esto quiere decir que todo el tráfico que se enrute a través de un nodo TOR, si éste es el último de los nodos que recorrerá nuestro paquete, puede ser capturado directamente, sin más tecnología que un sniffer.

Este ha sido el origen del robo de contraseñas. El atacante instaló varios nodos TOR (cualquiera de nosotros puede abrir un nodo TOR) únicamente para minar su tráfico.

Nuevamente, debemos decir que la inseguridad no está en TOR, sino en la ingenuidad del usuario. O, mejor dicho, el desconocimiento que de cosas tan técnicas tienen los usuarios.

Como bien explican en Hispasec, si no se utiliza el cifrado punto a punto (como SSL), no puede garantizarse la privacidad de los datos en tránsito.

¿Podemos culpar a los usuarios de no conocer a fondo los detalles técnicos del enrutamiento en internet, o de los protocolos de cifrado y de control de tráfico? Por supuesto que no.

Tratándose de usuarios gubernamentales y corporativos, supongo que el mayor peso de la culpa debería recaer sobre los respectivos departamentos de sistemas. Pero claro, todos sabemos que los usuarios suelen tomar iniciativas propias y más hoy en día, cuando los instaladores de software y wizards de configuración facilitan todo al punto de poder prescindir de todo “departamento” de sistemas.
Pero muchachos, de todas formas van a culparlos. “¿Por qué no me avisaste?“… simplemente porque no sabía que lo estabas haciendo. ¿Entonces debemos monitorear todo lo que se hace?

En todo caso vuelve a repetirse la historia: la seguridad es la inversa de la usabilidad.

La llegada de cada producto de la manzanita siempre es una revolución, pequeña o grande, pero revolución al fin. Después de las presentaciones el rumbo de la tecnología cambia: todos lo copian. Y no es porque sí, sino porque Apple siempre revoluciona realmente. Principalmente en usabilidad.

Ahora, un teléfono celular: el iPhone.

www.apple.com/iphone

Desde hace un tiempito (breve) me acostumbré mucho al Google Docs, y a utilizarlo como medio de colaboración de documentos con Tana.

Realmente viene a reemplazar a los wikies, en cuanto a colaboración online se refiere. Además, no tiene esa interfaz engorrosa y esos crípticos formatos en los que uno tiene que codificar sus mensajes para que finalmente se vea un título, o un link, etc.

Claro que un wiki es todo un sistema de publicación y creación de páginas, si se quiere, pero para compartir un documento y que varias personas trabajemos sobre eso Docs de Google le gana lejos a los wikis.

Ahora será cuestión de empezar a colaborar con Spreedsheets también, y llevar, por ejemplo, la contabilidad compartida de una manera mucho más accesible que con documentos locales en las pc de cada uno.

Aguante Google, una vez más. (this is not a sponsored article, nor a blog hahaha)

Los amigos de Flickr pidieron la patente por su sistema de tags que expresan el “interés” de las personas en distintos tópicos (estos).

Esta forma de representar los ítems más hot ya fue ¿copiado? por muchos sitios, entre ellos Clarín, el “gran” diario argentino.