Naked password

yeaaah, venga esa complejidad!

De los rincones recónditos de User Experience en StackExchange y una pregunta de cómo incitar a los usuarios a poner passwords fuertes, me entero de la existencia de Naked Password, un plugin de jQuery que en sitios informales (muy informales) incentiva a los usuarios a usar passwords complejos, de forma… digamos… “natural”. Pueden probar el demo en su misma página.

Dicho sea de paso, otras buenas respuestas fueron:

• Asustar al usuario (mostrando en cuánto tiempo se podría crackear su password)
• No hacer nada (considerando la mejor experiencia general, que el usuario decida como más quiera)
• Recompensarlos con características extras (por ejemplo, funcionalidades en beta)

Soy un zorrinito de poca complejidad.

Link del día: Borrando muchas veces

Los mitos sobre seguridad van desapareciendo de a poco.

En IT Security de StackExchange publicaron una pregunta que quizá muchos nos hayamos preguntado: ¿Por qué escribir ceros múltiples veces es más seguro que escribirlos sólo una vez?

Para quién no esté en el ámbito, se supone que borrando información confidencial, lo más seguro es escribir sobre esa información hasta unas treinta veces. Por supuesto, esto toma treinta veces más tiempo, y más aún en determinados métodos en donde en lugar de escribir ceros escriben datos al azar, datos auto-generados o alguna otra cosa que también use recursos del procesador. El punto es que se hace más de una vez “para estar más seguro”. Ahora, ¿es esto seguridad real o paranoia?

La respuesta (resumida) es que alguna vez tuvo sentido, ya que alguna vez Peter Guntman demostró que se podía distinguir un cero escrito sobre un cero que un cero escrito sobre un uno, hasta habiendo sido escrito unas 31 veces. Desde entonces, el estándar suele ser hacer unas 35 escrituras, aunque parece que esto no es necesario, ya que la tecnología de discos ha cambiado mucho. Para más detalles, pueden leer la pregunta y sus respuestas, que tienen muchos links de referencia.

Soy un zorrinito seguro.

Link del día: Programando con el sombrero rosa

La gente de Babcock y Jenkins escribió un artículo sobre una actividad que ellos denominan “Coybow coding”, que como lo pueden imaginar, tiene que ver con la codificación temeraria. En este caso, se trata sobre la programación o remediación de defectos directa en servidores de producción. Su artículo se titula Cowboy Coding and the Pink Sombrero.

La metodología de ellos es realmente hacer llamar la atención a alguien cuando se están haciendo cambios en producción. Es muy común que ciertas empresas muestren un mensaje cuando se accede a un servidor de producción, o que muchas acciones estén restringidas, o que se necesite usar passwords a cada rato. En defnitiva, es la importancia de recordarle al programador / administrador de sistemas que se encuentra trabajando en un sistema que está en vivo.

Ahora, otra forma de lograr este efecto es “haciendo pensar” al programador si realmente se justifica estar haciendo estos cambios en producción, y para eso, nada más llamativo de la atención que un sombrero rosa. Lo llamativo del sombrero hace que todos sepan que hay alguien trabajando en producción, y cuando se acercan a preguntar, la persona haciendo los cambios comienza a dudar si realmente lo mejor era hacer eso.

Buena técnica, curiosa implementación. Me gusta como se juega con la psicología para que de a poco se vayan castigando estos comportamientos. Sin embargo, creo que si alguien debe de hacer un cambio en producción, dudo que el ambiente sea tan animado como para andar poniéndose sombreros.

Soy un zorrinito sin sombrero.

Link del día: Lineamientos de seguridad

Desde los geniales posts que nuestro amigo Alan Pasho ha escrito para el blog de CommonSense, en la serie de Is Your Website or App Secure? (recomiendo la lectura de todos ellos), me encontré ayer con los lieamientos que Mozilla impone a sus desarrolladores como medidas de seguridad al momento de desarrollar aplicaciones.

Cabe destacar que estos lineamientos, WebAppSec/Secure Coding Guidelines, no son nada cortos, pero sí detallados, y se cubren tópicos desde manejo de sesiones a (lo más básico) validación y autenticación. Si alguien está pensando en armar un checklist, este es muy buen comienzo, y si alguien quiere una guía completa de qué cubrir, puede leer esto o, por supueto, todo el contenido de OWASP y los libros relacionados.

Sabemos que la seguridad es todo un mundo, pero cuando se trata de hacer verificaciones o checkeos, siempre necesitamos una lista rápida,y tanto los posts de Alan como la guía de Mozilla son un buen lugar para hacer esa checklist de items.

Soy un zorrinito asegurado.

Link del día: HackArmoury

Como de costumbre, la gente de DragonJar postea cosas muy útiles e informativas en el ámbito de la seguridad. En este caso se trata de dar a conocer HackArmoury, un sitio dedicado a ser un repositorio de herramientas lo más accesible posible, de forma que estemos en donde estemos, con las restricciones que tengamos, siempre podamos acceder a las herramientas útiles en el ámbito de la seguridad.

Cabe destacar que este sitio ha innovado en cuanto a las formas que se tiene de acceder a él. No sólo están el típico HTTP y FTP, sino que también podemos entrar a través de Samba (SMB), rsync, IPv6, TFTP, SVN.. por supuesto, lo estarán expandiendo en el futuro. (Por qué no, por ejemplo… email?)

Soy un zorrinito armado.

Link del día: Cryptico.js

Ya alguna vez había mencionado una librería JavaScript para encriptar datos (jCryption), pero nunca está de más considerar otras alternativas. En este caso se trata de cryptico.js. El proyecto también es de Open Source y nos permite usar AES y RSA (o eso leí, pero la documentación sólo menciona RSA), y con una serie de métodos muy simples, nos permite operar con cadenas que queramos utilizar para transmitir de forma segura.

Lo curioso es que podemos generar claves especificando el tamaño de la misma, pudiendo ir desde una clave de 512 bits hasta 8192… pedazo de clave.

Este tipo de encriptación, por el hecho requerir una clave “insegura” para generar la clave RSA, no es inseguro de por sí. Recordemos que estamos hablando de encriptación asimétrica, de forma que por más que se tenga la clave generada, no hay inseguridad, puesto que es la otra clave (la que se queda con nosotros, la privada) la que se usará para desencriptar los datos.

Soy un zorrinito encriptado.

Misceláneos del fin de semana

Por un lado, esto es una excusa para probar IfTTT. Luego hablaré sobre esto.

Por otro lado, sigo avanzando con el libro de Minsky, The Emotion Machine, sin embargo, ya estoy terminando el capítulo 7 y no creo que vaya a hacer un resumen de capítulo por capítulo como estaba haciendo. Siento que pierdo demasiado tiempo en los detalles cuando lo importante lo puedo resumir al terminar. A la vez, detecto ciertas debilidades en la teoría de Minsky pero quiero darle la oportunidad de justificarse antes de terminar. Aún así, no pongo en duda nada. Hablamos de Minsky, lo pensó bastante mejor que yo. También lo hablaremos luego.

Por otro lado más, veré de apresurar los ratings de películas. Ahora también juego con IMDB y su sistema de recomendaciones. Por lo pronto, aquí está la lista de todo lo que encontré para rankear, y la lista de mis películas pendientes para ver. Todo está en proceso de construcción.

También estoy pensando en volver esto más microblogging… necesito hacer un serio trabajo de rediseño aquí.

Hice un pequeño post sobre Cross Domain POST Requests. Aparentemente no hay nada que los detenga de ocurrir. Si bien eso no es noticia, me pregunto por qué hay problema con Cross Site Ajax Requests y no con esto. El post y una pequeña prueba están aquí.

Por último, pronto se vendrá el review de Killer Elite, si es que llego a verla.

Link del día: Privacidad en las redes sociales

Las redes sociales siempre fueron una preocupación en cuanto a la privacidad de los datos y la forma en la que fácilmente otras personas nos pueden engañar. De hecho, mientras mejor cumplan su trabajo, más peligrosas van a ser en este sentido.

Es por eso que la gente de DragonJar hizo un buen post, casi-recopilatorio, sobre este tema. Se titula: Cómo conservar la privacidad en las redes sociales. En él nos explican una serie de conceptos básicos a modo de caricatura (orientado a chicos que ya son familiares con estas tecnologías) y de ahí una serie de posts que ellos mismos poseen sobre la seguridad en internet, y guías específicas para proteger los datos en cada una de las redes sociales que hoy son más populares (Facebook, Flickr, Hi5, Last.FM, LinkedIn, MySpace, Orkut, Tuenti, Twitter, Windows Live Spaces, Xing y Youtube).

Soy un zorrinito privado.

Link del día: Seguridad, de verdad

Seguramente nosotros nos sentimos protegidos porque tenemos… qué? Un antivirus y un firewall? Muchos de nosotros ni eso debemos tener.

Sin embargo hay gente que se toma la seguridad en serio, y está muy interesante analizar esos casos para aprender qué hacen y por qué. Y creanmé, que las posibilidades que se pueden abordar son enormes y extrañamente complejas. ¿Has pensado que podrías encriptar todo lo que se almacena en tu RAM? ¿Has pensado en llevar contigo tu partición de booteo para que nadie pueda encender tu máquina? ¿Has pensado en usar Windows como honeypot para que alguien lo use y puedas detectar en donde está tu máquina? ¿Restringir los permisos del navegador?

Y la lista continúa. Por supuesto, según dice el autor de este artículo, se puede hacer mucho más, y no estoy realmente seguro, pero por lo menos lo hice un poco más difícil.

El artículo en cuestión es Protecting a laptop from Simple and Sophisticated Attacks, de Mike Cardwell.

Soy un zorrinito inseguro.

Encuesta redes sociales

Llegó a mis manos una encuesta que ayudé a difunder sobre redes sociales. Encontré algunos resultados interesantes, así que decidí además probar Prezi (del cual ya había hablado alguna vez), y ver si podía hacer una presentación con él. Aquí está el resultado de un rato de trabajo.