Siempre me ha interesado leer guías de estilo de codificación y ese tipo de cosas de diversas empresas y proyectos porque es útil para saber lo que queremos (o no querríamos) hacer con nuestro propio estilo. Sí que leo con cierta frecuencia código de otros en GitHub y en los proyectos de programación de nuestros estudiantes, que de todo el mundo se aprende.
El código de los proyectos de software libre (y las normas/consejos) de los propios proyectos nos pueden servir para leer un buen montón de código que es algo que, me temo, no hacemos con la suficiente frecuencia.
Se trata de la idea (extendida y aplicada) del enmascaramiento de contraseñas cuando nos estamos autentificando en un sitio. Lo cierto es que puede ser una buena idea, pero para muchos usuarios es una molestia y, seguramente, es mejor darles la oportunidad de decidir si están en un entorno donde la contraseña debería enmascararse o no. De eso habla Luke Wroblewski en Showing Passwords on Log-In Screens continuando con algo que ya anticipó en Mobile Design Details: Hide/Show Passwords y que es un nuevo factor al que deberíamos darle algunas vueltas antes de diseñar nuestro sistema.
Muestra varios ejemplos y aprovecha también para introducir algunas ideas nuevas relativas a la identificación biométrica (con los iPhones, fundamentalmente).
Para su correcto funcionamiento necesita BeautifulSoup y requests y tal vez algunos módulos más. Si no están instalados en nuestro sistema, recibiremos las ‘quejas’ correspondientes.
Para obtener las credenciales tenemos que registrar nuestra aplicación en Facebook My Apps. Hace falta ir al menú avanzado (es más fácil registrar aplicaciones web, la verdad) y se nos asignarán algunos identificadores (fundamentalmente el token OAUTH, que podemos mirar en https://developers.facebook.com/tools/explorer/APPID/?method=GET&path=me%3Ffields%3Did%2Cname&version=v2.2, donde APPID es el que nos hayan asignado), que en nuestro caso almacenamos en ~/.rssFacebook y leeremos desde el programa.
El programa es muy sencillo, se puede descargar en rssToPages.py V.2015-01-26 (enlazo a la versión actual por si en el futuro hago algún cambio).
Como decíamos arriba, empezamos leyendo la configuración relativa a los blogs de los que queremos leer para elegir uno. Si sólo hubiera uno se elegiría directamente:
config=ConfigParser.ConfigParser()config.read([os.path.expanduser('~/.rssBlogs')])print"Configured blogs:"i=1forsectioninconfig.sections():printstr(i),')',section,config.get(section,"rssFeed")i=i+1if(int(i)>1):i=raw_input('Select one: ')else:i=1print"You have chosen ",config.get("Blog"+str(i),"rssFeed")
Esta configuración debe contener una sección por blog y para cada uno de ellos contendrá la fuente RSS, el nombre de la cuenta de Twitter y el nombre de la cuenta de Facebook. Para este sitio tendría el siguiente aspecto:
También puede contener un campo más, linksToAvoid que se usa en el programa de extraer los enlaces para evitar algunos de ellos (lo uso en otro blog para eliminar los enlaces a las categorías).
Finalmente, buscamos si la entrada contiene alguna imagen. Si no la hay no pondremos nada, pero Facebook lo hará su cuenta (puede ser nuestra foto, un botón, lo primero que haya).
Tal vez podríamos configurar una por defecto cuando nuestra entrada no tenga una, si no nos gusta la que sale por defecto (en mi caso es mi foto; como no me gusta verla allí esto me obliga siempre a pensar en una foto para el post):
pageImage=soup.findAll("img")# Only the first one
iflen(pageImage)>0:imageLink=(pageImage[0]["src"])else:imageLine=""
Leemos la configuración para Facebook y empezamos a trabajar, solicitando la lista de páginas de las que somos administradores (el nombre de la página en la que queremos publicar lo habremos puesto en ~/.rssBlogs):
Ya llevo más de un mes probando con un par de blogs y la solución parece que funciona bastante bien. Lo más molesto fue conseguir las credenciales y dar de alta la aplicación (con un ‘falso’ paso a producción; falso porque no la usa nadie más, al ser de escritorio).
Dudas, comenarios, ideas… ¡Hazme un pull request o un issue!
Un texto interesante en Software defense: mitigating common exploitation techniques sobre diversas técnicas que los sistemas Windows ofrecen para proteger nuestros programas frente a ciertos ataques comunes, en particular relacionadas con la gestión de la memoria y dificultar a un atacante la posibilida de encontrar los datos en lugares predecibles.
La criptografía es de mis temas ‘menos’ favoritos en seguridad. Siempre nos avisan de que es algo difícil de hacer bien. Por lo tanto nos relega al papel de meros consumidores, eso sí, tratando de estar al día en los tamaños de claves, algoritmos criptográficos y esas cuestiones.
Empiezan hablando de RSA y las propiedades que lo hacen interesante (la factorización es costosa -lenta- y la multiplicación es rápida).
The RSA algorithm is the most popular and best understood public key cryptography system. Its security relies on the fact that factoring is slow and multiplication is fast. What follows is a quick walk-through of what a small RSA system looks like and how it works.
Incluso muestran un pequeño ejemplo:
Let’s make this more concrete with an example. Take the prime numbers 13 and 7. Their product gives us our maximum value of 91. Let’s take our public encryption key to be the number 5. Then using the fact that we know 7 and 13 are the factors of 91 and applying an algorithm called the Extended Euclidean Algorithm, we get that the private key is the number >29.
Y sigue…
Luego, entra más a fondo en la criptografía de curvas elípticas:
An elliptic curve cryptosystem can be defined by picking a prime number as a maximum, a curve equation, and a public point on the curve. A private key is a number priv, and a public key is the public point dotted with itself priv times. Computing the private key from the public key in this kind of cryptosystem is called the elliptic curve discrete logarithm function. This turns out to be the trapdoor function we were looking for.
