python-keyring está muy bueno
Está bueno cuando un programa puede recordar la password que le das.
Es mejor cuando almacena esa password de forma segura. Sin embargo, no es trivial hacerlo si te importa que el programa sea multi plataforma.
O al menos no lo era hasta que Kang Zhang escribió python keyring, un móduo que abstrae el mecanismo de almacenamiento de claves de KDE, GNOME, OSX y Windows (y tiene un par de backends con archivos por las dudas).
¿Cómo funciona?
Se instala de la forma habitual. Si no está disponble para tu distro/sistema operativo, usá easy_install:
easy_install keyring
También se puede obtener via mercurial:
hg clone http://bitbucket.org/kang/python-keyring-lib/
La API es la simplicidad misma. Así se guarda un secreto:
Tal vez te muestre este diálogo (o algo similar en otras plataformas):
Y aquí está la prueba de que se guardó correctamente (es el administrador de claves de KDE):
¿Y cómo recuperamos el secreto?
Y funciona así:
$ python load.py thisisabadpassword
Como se puede ver, la API es tan fácil como puede ser. Hasta eligió el backend KWallet automáticamente porque estoy en KDE!
Python-keyring es un módulo que resuelve un problema real, así que un aplauso para Kang Zhang y Tarek Ziadé (que tuvo la idea).
Python-keyring is available on Debian, should be available in Ubuntu in ... some months I guess.
It's also available in Arch.
Thanks for the link
Using python is a bit of a silly idea; I can see a virus searching for your python app in your homedir and modify it to email all passwords it can harvest from the kwallet (since the user gave it an 'ok its safe!').
This may even be the case if the python stuff is installed as root, simply because its easy to place new python code in your homedir and make it be executed instead of the packages-installed app.
And the same problem happens; the user gives an ok because the user is unable to detect the difference.
I seriously think using any scripting language is just wrong for this kind of work.
The "app X is asking for permission to open wallet" is trivial to overcome, since the app name is simply a parameter in QApplication construction.
If you are depending on that for your security, you are screwed.
It *may* be non-trivial if kwallet (or gnome-keyring) checked whih process is asking, looked for the binary location via /proc and refused to work if it's not a system binary, but even that kinda sucks in other ways.
Perhaps if the wallet stored an MD5 for the approved application this scenario could be handled. I think the majority of python apps would be installed through package management which means the virus would need root privileges to modify them anyway.
Yes, MD5 sums would increase security from a technical point of view. The application name alone is quite insufficient. For instance in Gnome you could write a malicious app which calls gobject.set_application_name("trusted_app") and then inherits the rights of "trusted_app" (correct me if I'm wrong).
Anyway, in daily use MD5 sums would fail too. Consider some packaged application which gets updated regularly. Each time the question "Application X is requesting access to ..." would reappear and users would tend to blindly acknowledge, also because they mostly cannot decide if the MD5 change has been caused by a regular package update or by hijacking the application name.