Mining Bits and Knowledge
Artigos com o marcador store
Dobrando o Gnome Keyring Com o Python – Parte 4
24/01/11
 |
This post is also available in English |
Mantendo o assunto anterior, hoje vou escrever um pouco sobre a segurança do Gnome Keyring. Conforme apresentado no último post o Gnome Keyring é responsável por armazenar informações sensíveis em bases de dados encriptadas chamadas keyrings. Eu mostrei como criar um Keyring e armazenar alguns dados. Mas agora eu pergunto, essas informações estão seguras? Elas podem ou não estar, depende de você.
Existe uma discussão recorrente sobre o comportamento do Gnome Keyring. Quando fazemos log-on, o Gerenciado de Sessão “destranca” o chaveiro padrão com sua senha de logon para evitar muitos popups perguntando se você quer permitir que uma certa aplicação acesse o Gnome Keyring. Muitas pessoas encaram isso como uma falha de segurança, Eu não concordo totalmente. O Gnome Keyring também utiliza o nome da aplicação para confirmar as permissões. Vamos ver um exemplo, vou supor que estamos desenvolvendo uma certa aplicação chamada ‘MyApp’ e que ela irá criar um chaveiro simples. O trecho de código a seguir cuida disso:
Dobrando o Gnome Keyring Com o Python – Parte 3
29/12/10
|
This post is also available in English |
No ultimo post Eu mostrei como criar chaveiros usando o Python e mencionei as “pequenas diferenças” com o processo de armazenamento de senhas pelo SeaHorse. Bem, acontece que, quando começamos a cavar mais fundo, essa diferença se mostrai um pouco maior. Usando o SeaHorse todo chaveiro é criado a flag “Update if Exists” com o valor False, com isso é possível criar itens idênticos no chaveiro. Essa não é uma abordagem muito segura e pode resultar em um chaveiro inconsistente. Mas ao utilizarmos a flag “Update if Exists” com o valor True, algo inesperado acontece:
#!/usr/bin/env python
import gnomekeyring as gk
import glib
APP_NAME = 'MyApp'
KEYRING_NAME = 'MyKeyring'
glib.set_application_name(APP_NAME)
keyrings = gk.list_keyring_names_sync()
# If this keyring already exist, let's remove it
if KEYRING_NAME in keyrings:
# Gnome Keyring Daemon may ask for a password here
gk.delete_sync(KEYRING_NAME)
# If anyone asks, the password is 'mypasswd'
gk.create_sync(KEYRING_NAME, 'mypasswd')
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'guest@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Jupiter:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (id=%i)'%(id)
Salve esse código como my_keyring_creator.py e execute-o.
Bending Gnome Keyring with Python – Part 3
24/03/10
 |
Este post também está disponível em Português |
In the last post I’ve shown how to create keyrings using python and mentioned a slightly difference from the “seahorse password storing process”. Well, it happens that, when we start to dig this difference isn’t so small. Using seahorse every keyring item is created with the “Update if Exists” flag as False, so you can create identical keyring items. This is not a safe approach and can result in an inconsistent keyring. But as we use the “Update if Exists” flag set as True, something unexpected happens:
#!/usr/bin/env python
import gnomekeyring as gk
import glib
APP_NAME = 'MyApp'
KEYRING_NAME = 'MyKeyring'
glib.set_application_name(APP_NAME)
keyrings = gk.list_keyring_names_sync()
# If this keyring already exist, let's remove it
if KEYRING_NAME in keyrings:
# Gnome Keyring Daemon may ask for a password here
gk.delete_sync(KEYRING_NAME)
# If anyone asks, the password is 'mypasswd'
gk.create_sync(KEYRING_NAME, 'mypasswd')
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'guest@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)
id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Jupiter:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (id=%i)'%(id)
Save this as my_keyring_creator.py and run it.
Bending Gnome Keyring with Python – Part 2
20/03/10
|
Este post também está disponível em Português |
In the last post we started introducing how the Gnome Keyring works. I showed how to create a keyring and its items using Seahorse, now I’m going to show how to do it using Python. In order to interact with Gnome Keyring from Python we need python-gnomekeyring installed. Let’s start bending…
Exploring Gnome Keyring
As a first step, I’ll show how to “explore” Gnome Keyring. A good start is ensure that the Gnome keyring Daemon is available using the is_available method. To search through existing keyrings we can use the list_keyring_names_sync method. If you test this from a Python Console you will notice an recurrent warning “g_set_application_name not set”, an example:
>>> import gnomekeyring as gk >>> gk.list_keyring_names_sync() ** (process:1737): WARNING **: g_set_application_name not set. ['login', 'MyKeyring', 'session'] >>>
This happens because the daemon requests information about which application is trying to access the Gnome Keyring info and as a Python Console we don’t have any application name. To solve this, we can import the gobject library and use the method set_application_name. Below, there is a simple keyring listing example:
Bending Gnome Keyring with Python – Part 1
17/03/10
|
Este post também está disponível em Português |
In the last days, I was working in Tiamat and faced the need to store SSH and Telnet passwords. I don’t even hesitated, one name came to my mind: Gnome Keyring. It’s easy, it’s secure and have Python binding, what was missing?! Know how to use it. Before we start bending, I’d like to discuss a little about how some applications store your passwords.
It’s common to find applications that stores passwords “incorrectly” and “insecurely”. It’s easy to find IM (Internet Messengers), e-mail and other clients that stores the user’s password in a hidden config file in the user’s home. Isn’t hard to find out that the passwords are in plain text. Some times this password config file receives a “little protection”, it’s applied a password to the password. This means that the password is obfuscated with a reversible algorithm by a “master password”. This isn’t correct! It gives us the felling of false security, they seem to be encrypted but aren’t! With a little brutal force is possible to unveil the user’s passwords.
A perfect example is Pidgin. The famous IM client stores your password at /home/<username>/.purple/accounts.xml. Don’t believe me?! Look here. Still don’t believe yeah? The pidgin development team spoke about it here. Let me quote the first paragraph:
