Introdução ao memcache

O problema

Imagine um portal como o globo.com, com suas inúmeras chamadas para matérias que constam já na página principal.

Apelação milenar

Apelação milenar

Cada imagem, título e descrição de reportagem ou comercial que aparecem na página são informações dinâmicas dela. A cada vez que acessamos a página, podemos obter notícias mais recentes, resultando em uma página diferente. Assim, imagina-se que os dados apresentados na página estejam armazenados em um banco de dados e que, a cada acesso de usuário, temos várias consultas sendo realizadas pelo servidor ao banco de dados. Isso seria o mais natural, considerando-se a alta taxa de criação de novas notícias no site. Porém, você já deve saber que o disco é o grande gargalo dos computadores modernos e que acessos a disco são o grande vilão da performance da maioria dos programas de computador. Então, como fazer um sistema web com foco no conteúdo dinâmico sem realizar frequentes acessos ao BD (e consequentemente, ao disco)?

Uma possível solução

Uma solução pode ser fazer o caching de alguns dados na memória. Em um portal de notícias, os usuários que acessarem a página mais ou menos no mesmo horário vão receber o mesmo conteúdo, que são as últimas notícias postadas. Então por que repetir as consultas ao banco de dados para todo e qualquer acesso de usuário ao portal? Seria mais inteligente se o nosso sistema consultasse o banco de dados somente uma vez, armazenasse os resultados da consulta em memória (na nossa cache) e então passasse a responder às requisições subsequentes usando o conteúdo armazenado em memória sem precisar buscar nada no disco até que o conteúdo mude novamente. Assim, as requisições podem ser respondidas com o conteúdo da memória. Quando o conteúdo do BD sofrer alguma alteração, a cache pode ser invalidada e atualizada com o novo conteúdo.

Um exemplo

Vamos seguir com o foco em um portal de notícias, já que existem muitos casos de uso similares. Como já vimos em outro post, o Google App Engine suporta Python; e o mecanismo de datastore que ele oferece é legal pra caramba. Suponhamos que nesse portal existe um modelo de dados que contenha uma entidade Noticia, conforme representado abaixo:

class Noticia(db.Model):
    titulo = db.StringProperty(required=True)
    conteudo = db.TextProperty(required=True)
    url = db.LinkProperty(required=True)
    autor = db.UserProperty(required=True)
    thumbnail = db.LinkProperty()
    data_publicacao = db.DateTimeProperty()

Como todo bom portal de notícias, esse também vai ter aquela página inicial carregadíssima, cheia de notícias e outros elementos. Haja barramento pra aguentar tantos acessos ao disco!

O código a seguir poderia ser a view que gera a sua página principal:

    class PostHandler(webapp2.RequestHandler):

        def get(self):
            ultimas = get_noticias(100, '-data_publicacao')
            categorias = get_categorias()
            comerciais = get_comerciais_ativos()
            for n in ultimas:
                # lista e formata as noticias, categorias, comerciais
                ...

    def get_noticias(limit, order_by):
        return Noticia.all().order(order_by).fetch(limit)

    def get_categorias():
        return Categoria.all()

    def get_comerciais_ativos():
        return Comercial.all().filter('ativa = ', True)

Beleza, funciona. O problema começa quando o site começa a ficar popular e os usuários começam a reclamar de lentidão e de indisponibilidade constante. O que fazer? Bom, a resposta certa é fazer profiling da aplicação, isto é, medir o tempo que estão levando as operações necessárias para carregar a página — tanto no lado cliente quanto no lado servidor — e então você poderá decidir melhor como resolver o problema. Mas quando um site está realizando várias consultas ao banco para cada acesso do usuário, frequentemente uma solução é evitar a realização dessas consultas usando uma cache.

Let’s cache them all!

mecanismo de cache que vou apresentar aqui é o memcache específico para o Google AppEngine, embora existam várias implementações do memcache para as mais variadas plataformas e linguagens. O memcache é um mecanismo que permite o armazenamento de pares chave-valor (assim como um dicionário, ou uma tabela hash) em memória, de forma que o acesso aos valores ocorre de forma bem eficiente.

Agora, vamos modificar o método get_noticias() para fazer caching do conteúdo da página principal. O princípio de funcionamento é bem simples: antes de qualquer consulta ao banco, verifique se os dados que queremos estão presentes na cache. Veja o código:

from google.appengine.api import memcache

def get_noticias(limit, order_by):
    # busca na cache por um valor de chave 'noticias'
    ultimas = memcache.get('noticias')
    if ultimas is None: # valor ainda não está em cache
        # busca no BD
        ultimas = Noticia.all().order(order_by).fetch(limit)
        # e inclui o resultado na cache para os futuros acessos
        if not memcache.add('noticias', ultimas):
            logging.error('Erro ao setar memcache.')

O que foi feito acima para os dados das notícias pode ser feito também para os comerciais e para as categorias. Assim, o primeiro de todos os acessos ao site pode demorar um pouquinho mais, mas os acessos seguintes de todos os usuários vão ser muito rápidos.

Cuidado com a Sincronização

Uma vez que começamos a usar a cache, nós passamos a ter informações redundantes (BD e cache). Dessa forma, basta que alguém insira uma notícia nova no BD para que tenhamos os dados fora de sincronia. Uma alternativa para solucionar esse problema pode ser: logo após salvar uma nova notícia no BD, atualizar os valores da cache. Se isso for algo demorado, poderíamos iniciar uma tarefa em background para fazer isso.

Quando usar cache?

Como já comentei anteriormente, a cache não é a solução para todo e qualquer problema de um sistema web. O problema pode estar no plano de hospedagem, no excesso de arquivos estáticos, em lógica duplicada resultante de um mau hábito de copiar-e-colar, em algoritmos pouco otimizados, etc.

A cache é um mecanismo bem simples de ser implementado, em alguns casos, mas isso não quer dizer que você já deve sair de cara utilizando cache em todo e qualquer projeto a partir de agora. Afinal, premature optimization is the root of all evil. 😛

Para finalizar…

No curso Web Development, ministrado pelo grande Steve Huffman no Udacity.com, aprendi o seguinte:

Um simples acesso de usuário a uma página jamais deveria gerar um acesso ao banco de dados.

Ou seja, se um usuário qualquer quiser apenas visualizar sua página, blog, ou portal, esse acesso não deveria exigir do sistema um acesso ao banco de dados. É um princípio bem simples e que pode evitar que o seu site caia quando se tornar mega-popular. 🙂

Grandes sites como Twitter, Facebook e Reddit usam largamente os mecanismos de cache, de forma que seja possível responder aos tsunamis de requisições que eles recebem a cada segundo.

Leia mais sobre o memcache na Wikipedia.

 

Obrigado ao Elias pela revisão!

Anúncios

Google App Engine e Datastore

Sumário

Em um post anterior, vimos como manipular no servidor os dados vindos de um formulário HTML, com Google App Engine (GAE) e Python. Porém, até agora não vimos como armazenar dados vindos do cliente em um banco de dados.

Neste post vamos incrementar a aplicação de envio de mensagens via formulários HTML que construímos em um post anterior, possibilitando que as mensagens enviadas pelos usuários sejam gravadas em um banco de dados e que sejam listadas logo abaixo do formulário na página principal. Vamos começar vendo o mecanismo para armazenamento de dados do GAE: o datastore.

Datastore

Diferentemente do que acontece quando estamos lidando diretamente com um banco de dados relacional, onde criamos as tabelas com suas propriedades no banco de dados, para então ajeitar a aplicação para que possa acessar tal banco, com o GAE nós poderemos implementar uma app inteira sem ver código SQL algum.

Para criar uma entidade no BD, basta definir uma classe contendo os atributos que desejamos que façam parte de nosso BD. Vamos criar uma entidade chamada de Mensagem, que irá armazenar os atributos relacionados às mensagens enviadas pelo usuário:

from google.appengine.ext import db

class Mensagem(db.Model):
    nome_usuario = db.StringProperty(required=True)
    url = db.LinkProperty()
    email = db.EmailProperty()
    comentario = db.TextProperty(required=True)

Nossa classe estende a classe db.Model, o que é um requisito para que ela possa representar uma entidade no BD. Veja que a definição de uma entidade é bem simples, bastando declarar os atributos desejados como variáveis de classe. Já definimos também os tipos dos dados que cada atributo irá representar. No exemplo acima, StringProperty é o tipo que usamos para definição de campos de texto com menos de 500 caracteres. Já o tipo TextProperty é usado para a definição de campos para textos mais longos. Para conhecer a lista completa dos tipos de atributos disponíveis no framework de persistência do Google App Engine, consulte a documentação oficial.

Persistência de objetos no datastore

Uma vez que definimos uma entidade para representação de nossas mensagens no banco de dados, criar e salvar dados no BD é tão simples quanto criar um objeto:

msg = Mensagem()
msg.nome_usuario = "stummjr"
msg.url = "https://pythonhelp.wordpress.com"
msg.email = "stummjr@someemail.com"
msg.comentario = "Um comentário bem interessante!!!"
msg.put()

O procedimento é bem simples. Primeiramente, instanciamos um objeto da classe Mensagem (linha 1). Após isso, setamos os atributos desse objeto (linhas 2-5). Por fim, salvamos tal objeto no BD (linha 6).

Também poderíamos passar os valores para todos os atributos como parâmetros nomeados na construção do objeto:

msg = Mensagem(
    nome_usuario="stummjr",
    url="https://pythonhelp.wordpress.com",
    email="stummjr@someemail.com",
    comentario="Um comentário bem interessante!!!"
)
msg.put()

Agora já podemos integrar o código acima em nossa app do post anterior. Basta criar o objeto Mensagem e persistir esse objeto no BD dentro do método post, que irá tratar os dados enviados pelo usuário via formulário:

def post(self):
    msg = Mensagem(
        nome_usuario=self.request.get('nome_usuario'),
        url=self.request.get('url'),
        email=self.request.get('email'),
        comentario=self.request.get('comentario')
    )
    msg.put()
    self.redirect('/')

Observe que, ao final do método post(), fizemos uma chamada ao método self.redirect('/'), que faz com que o usuário seja redirecionado para o recurso recebido como parâmetro (nesse caso, a raiz do site). Fizemos isso porque se apenas enviarmos ao usuário uma resposta de confirmação, ele poderá causar a submissão duplicada do formulário caso solicite ao navegador que este atualize a página (o famoso F5). Assim, redirecionamos a outro recurso para evitar que uma sequência de refreshes na página recebida como resposta a um POST possa causar várias inserções duplicadas.

Adicionamos os campos nome_usuario, url e email ao formulário contido na variável html:

html = """
    <html>
        <head>
            <title></title>
        </head>
        <body>
            <form method="POST" action="/">
                Nome: <p><input type="text" name="nome_usuario"></p>
                URL: <p><input type="text" name="url"></p>
                Email: <p><input type="text" name="email"></p>
                Comentário:<p><textarea name="comentario" cols="40" rows="10"></textarea></p>
                <button type="submit">Enviar</button>
            </form>
        </body>
    </html>
"""

Feito isso, agora nosso app já é capaz de salvar no BD os comentários enviados pelos usuários. Caso já tenha visto o post anterior, apenas complemente aquele código com o que foi apresentado até aqui e execute servidor de desevolvimento local. Se não viu o post anterior, o código completo é apresentado na seção “O projeto completo”.

A interface administrativa local

Enquanto estamos desenvolvendo nosso app, podemos querer verificar se determinado objeto foi realmente persistido no BD ou não. Caso ainda não tenhamos desenvolvido algum método para listagem de objetos em nosso app, podemos utilizar a interface administrativa local do GAE, que fica disponível na URL http://localhost:8080/_ah/admin/ (obs.: o servidor de testes precisa estar em execução)

http7.1

Basta selecionar o tipo de objeto e solicitar a listagem.

Consultas ao datastore

Para realizar consultas aos objetos que estão no banco de dados, basta utilizar os métodos all(), filter(), dentre outros que são comuns a todas as classes que estendem db.Model. Veja alguns exemplos:

# obtém todos os registros de Mensagem do BD
msgs = Mensagem.all()

# pega somente Mensagens do "John Doe"
msgs.filter('nome_usuario =', "John Doe")

# ordena pelo endereço do email, de forma DESC (-)
msgs.order('-email')

for msg in msgs:
    print msg.email

Veja mais métodos para consulta de dados na documentação oficial.

Em nosso projeto, precisamos apenas adicionar ao método get() a funcionalidade de listagem das mensagens já existentes no BD, logo abaixo do formulário de submissão de mensagens. Com base nos métodos de consulta que vimos, podemos montar nosso método:

def get(self):
    self.response.out.write(html)
    self.response.out.write('<ul>')
    for msg in Mensagem.all():
        self.response.out.write('<li>' + unicode(msg.comentario) + '</li>')
    self.response.out.write('</ul>')

Tenha em mente que imprimir código HTML diretamente não é uma boa abordagem para desenvolvimento web. Existem técnicas mais recomendadas, como a utilização de modelos de páginas. Mas isso é um assunto para um outro post.

O projeto completo

Como já vimos anteriormente, a estrutura do diretório do nosso projeto deve ficar como:


projeto/
  handlers.py
  app.yaml

Segue abaixo o código dos arquivos relacionados:

Arquivo handlers.py:

import webapp2
from google.appengine.ext import db
from google.appengine.ext.webapp.util import run_wsgi_app

html = """
    <html>
        <head>
            <title></title>
        </head>
        <body>
            <form method="POST" action="/">
                Nome: <p><input type="text" name="nome_usuario"></p>
                URL: <p><input type="text" name="url"></p>
                Email: <p><input type="text" name="email"></p>
                Comentário:<p><textarea name="comentario" cols="40" rows="10"></textarea></p>
                <button type="submit">Enviar</button>
            </form>
        </body>
    </html>
"""

class PostHandler(webapp2.RequestHandler):

    def get(self):
        self.response.out.write(html)
        self.response.out.write('<ul>')
        for msg in Mensagem.all():
            self.response.out.write('<li>' + unicode(msg.comentario) + '</li>')
        self.response.out.write('</ul>')

    def post(self):
        msg = Mensagem(
            nome_usuario=self.request.get('nome_usuario'),
            url=self.request.get('url'),
            email=self.request.get('email'),
            comentario=self.request.get('comentario')
        )
        msg.put()
        self.redirect('/')


class Mensagem(db.Model):
    nome_usuario = db.StringProperty(required=True)
    url = db.LinkProperty()
    email = db.EmailProperty()
    comentario = db.TextProperty(required=True)


mapeamento = [
    ('/', PostHandler),
]
app = webapp2.WSGIApplication(mapeamento)
run_wsgi_app(app)

Arquivo app.yaml:


application: gaepost
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
  script: handlers.py

Com os arquivos acima, você já pode executar o projeto usando o ambiente de testes.

Aprenda mais

Caso tenha dificuldades para entender o funcionamento do Google App Engine, leia os posts anteriores nos quais introduzimos o assunto:

  1. Desenvolvendo com Python e Google App Engine
  2. Tratando dados de formulários com Google App Engine

Se quiser ir mais a fundo no GAE, sugiro que leia a documentação oficial, e também o livro Programming Google App Engine.

Armazenando senhas de forma segura

Dica ao leitor: não deixe de ler a seção “O mecanismo correto”.

Diga aí, você anota a senha do seu email em um post-it e deixa ele colado em seu monitor, visível a qualquer um? Aposto que não, pois seria muito fácil para alguém acessar sua conta e mandar emails engraçadinhos para seus contatos. Da mesma forma que você protege sua senha, os aplicativos que utilizam informações de login e senha para autenticar usuários (como o seu serviço de email) também devem cuidar das senhas armazenadas neles, não devendo nunca guardá-las em texto puro. Vamos ver nesse post como funciona a autenticação, e as melhores práticas para implementar esse serviço na sua aplicação de forma razoavelmente segura.

Autenticação

Você já parou para pensar em como funciona a autenticação em um serviço de email? Primeiro, você digita o seu nome de usuário e senha em um formulário web, como o exemplo abaixo:

Usuário: pythonhelp
  Senha: *******

Esses dados são então enviados para o servidor que está fornecendo o serviço de autenticação do seu email. Lá dentro, o serviço de autenticação irá procurar por um usuário chamado pythonhelp no banco de dados de usuários. Se encontrá-lo, irá realizar uma comparação (mais para frente veremos que não é uma simples comparação de duas strings) para verificar se a senha fornecida no formulário web corresponde à senha do usuário. Em caso positivo, a autenticação ocorre com sucesso e você pode então acessar sua conta de email. Em caso negativo, aquela mensagenzinha chata avisando que você errou seu nome de usuário ou sua senha aparece na tela. (A propósito, você já percebeu que a maioria dos serviços não informa se o que erramos foi o nome de usuário ou se foi a senha? Esse tipo de informação é usualmente interessante para um invasor em potencial.)

Deixando de lado alguns detalhes, a autenticação funciona basicamente da forma descrita acima. Antes de vermos como isso tudo poderia ser implementado, veremos como NÃO deve ser implementado um serviço de autenticação.

Como NÃO implementar autenticação

Vamos desenvolver o serviço de autenticação para a nossa aplicação. Para isso, criamos uma tabela no banco de dados chamada USUARIOS, que contém duas informações sobre cada usuário: seu nome de usuário e sua senha. Como você pode ver abaixo, armazenamos a senha dos usuários em texto puro, ou seja, as senhas estão visíveis a qualquer pessoa que obtiver acesso ao banco de dados.

+--------------+
| USUARIOS     |
+--------------+------------------------+
|    NOME      |        SENHA           |
+--------------+------------------------+
| joaozinho    | teste                  |
+--------------+------------------------+
| pedrinho     | teste123               |
+--------------+------------------------+
| maria        | t35t3                  |
+--------------+------------------------+

Para fazer a autenticação, basta que o usuário forneça a sua senha e que comparemos a senha fornecida com a que está armazenada no BD.

Isso até funciona, mas eu é que não forneceria a minha senha para um sistema meia-boca desses que vai armazená-la em texto puro no banco de dados. Sabe por quê? Porque uma vez que alguém obtenha acesso ao banco de dados do sistema, basta isso para quebrar a privacidade de todos os usuários:

user@host:~/$ sqlite usuarios.db
sqlite> select * from usuarios;
joaozinho|teste
pedrinho|teste123
maria|t35t3

You're doing it wrong!

Que coisa, não? As senhas estão expostas. Falha de segurança gravíssima! Sabendo que a maioria dos usuários usa a mesma senha para os logins em vários sites, dá pra ter uma idéia do estrago né?

Lição número 1: JAMAIS ARMAZENE SENHAS EM TEXTO PURO!

Um jeito melhor

Agora que você já sabe como não fazer, vamos ver uma forma um pouquinho melhor (ainda não a correta) de implementar um mecanismo de autenticação.

Dessa vez nós não vamos armazenar as senhas dos usuários no BD. O que vamos armazenar é uma informação relacionada à senha e gerada a partir dela, o chamado hash da senha.

O que é o Hash?

O hash de um valor é o resultado da aplicação de uma função de hashing a tal valor. Esse resultado é, em geral, muito diferente do valor original. Uma função de hashing H recebe como entrada um valor x e retorna como resultado o hash h correspondente àquele valor:

H(x) -> h

Vamos calcular o hash do valor 'teste123':

H('teste123') -> 'aa1bf4646de67fd9086cf6c79007026c'

Vamos agora calcular o hash do valor 'teste12':

H('teste12') -> '0940004e70ce8d82b440d3c1244dfdee'

Vamos calcular novamente o hash do valor 'teste123':

H('teste123') -> 'aa1bf4646de67fd9086cf6c79007026c'

Agora vamos aplicar a função de hash ao valor 'aa1bf4646de67fd9086cf6c79007026c' (que é o hash de 'teste123'):

H(‘aa1bf4646de67fd9086cf6c79007026c’) -> ‘0728a200630cec4b33e33e20646bc54a’

Observando com atenção, você pode notar algumas coisas sobre as funções de hash:

  1. A função de hash gera um resultado cujo valor é muito diferente do valor original.
  2. Quando alteramos levemente o valor de entrada para a função de hash, o valor retornado por ela muda completamente (veja os exemplos de aplicação nas entradas 'teste123' e 'teste12'). Isso é chamado de efeito avalanche.
  3. Quando aplicamos H novamente à entrada 'teste123', obtivemos o valor idêntico ao obtido pela primeira vez. Ou seja, a função de hash é determinística.
  4. O último exemplo nos mostra que uma função de hash não é reversível, isto é, dado o hash de um valor, não conseguiremos descobrir o valor original através desse hash.

A partir das observações acima, podemos inferir algumas propriedades que as funções de hash possuem:

  1. É improvável (muito improvável mesmo) que você modifique a entrada da função sem modificar o resultado dela.
  2. É impossível gerar o valor de entrada a partir do resultado.
  3. É muito difícil (muito mesmo) encontrar dois valores para os quais a função de hashing produza o mesmo resultado.
  4. Sempre que aplicada ao mesmo valor x, uma mesma função H(x) irá retornar o mesmo resultado h.

* Nos exemplos acima, usei o algoritmo de hashing MD5, embora existam vários outros que poderiam ser igualmente usados, como SHA-1, SHA-256, etc.

Autenticação com hash

Conhecendo as propriedades acima, podemos criar um mecanismo de autenticação mais seguro. O objetivo é armazenar as informações de senha de forma mais protegida, em vez de deixá-la exposta em texto puro.

A primeira idéia pode ser simplesmente armazenar apenas o hash da senha. Parece uma boa idéia, afinal, a propriedade 2 diz que se alguém roubar o valor do hash da sua senha, não conseguirá obter a senha propriamente dita, e a propriedade 4 nos possibilita verificar se a senha está correta comparando o hash do que o usuário digitou com o hash armazenado no banco de dados.

Veja abaixo como ficaria o nosso novo BD de usuários. Para cada usuário, armazenamos o hash da senha que ele forneceu no cadastro.

+-----------+
| USUARIOS  |                                  
+-----------+----------------------------------+
| NOME      |         HASH DA SENHA            |
+-----------+----------------------------------+
| joaozinho | 698dc19d489c4e4db73e28a713eab07b |
+-----------+----------------------------------+
| pedrinho  | aa1bf4646de67fd9086cf6c79007026c |
+-----------+----------------------------------+
| maria     | c7ac7410983dc7efbb2e5c062c515b7d |
+-----------+----------------------------------+

Quando o usuário quiser se autenticar no sistema, teremos em mãos a senha fornecida por ele na tela de login, mas não podemos compará-la diretamente ao valor armazenado no banco, pois o que está armazenado é o hash da senha. O serviço de autenticação deverá aplicar a função de hash sobre a senha fornecida pelo usuário e comparar o resultado com o que está armazenado no BD. Se o valor obtido for idêntico ao hash armazenado no banco de dados para aquele usuário, a autenticação ocorre com sucesso. Caso contrário, erro de autenticação.

Agora as senhas estarão um pouquinho mais seguras. Isso mesmo, somente um pouco, pois existem meios para descobrir o valor da senha original através do hash dela. A próxima seção vai descrever um pouco isso.

Ataques ao banco de dados de senhas (ou hashes delas)

Uma coisa que acontece com frequência é um sistema sofrer uma invasão e os invasores realizarem uma cópia do seu banco de dados. Considere que os invasores roubaram o seguinte banco de dados:

+-----------+
| USUARIOS  |                                  
+-----------+----------------------------------+
| NOME      |         HASH DA SENHA            |
+-----------+----------------------------------+
| joaozinho | 698dc19d489c4e4db73e28a713eab07b |  <-- hash de "teste"
+-----------+----------------------------------+
| pedrinho  | aa1bf4646de67fd9086cf6c79007026c |  <-- hash de "teste123"
+-----------+----------------------------------+
| maria     | 2a1bdbdad93b1081007abc4b419d8f0b |  <-- hash de "t35t3"
+-----------+----------------------------------+
|    ...    |               ...                |
+-----------+----------------------------------+

O que eles poderiam fazer com esses dados? De acordo com as propriedades que vimos sobre as funções de hashing, não seria possível extrair o valor original que gerou o hash, então você imaginaria que as senhas estariam seguras dessa maneira.

Teoricamente, sim. Mas agora imagine que o invasor (uma pessoa muuuuuuito paciente), de posse do hash da senha do usuário joaozinho (698dc19d489c4e4db73e28a713eab07b), comece a fazer alguns testes com valores comumente usados como senhas:

>>> import hashlib
>>> print hashlib.md5('123').hexdigest()
202cb962ac59075b964b07152d234b70
>>> print hashlib.md5('abcde').hexdigest()
ab56b4d92b40713acc5af89985d4b786
>>> print hashlib.md5('bla').hexdigest()
128ecf542a35ac5270a87dc740918404
>>> print hashlib.md5('teste').hexdigest()
698dc19d489c4e4db73e28a713eab07b

Opa! O invasor acabou de descobrir a senha do joaozinho (teste), pois o hash obtido para essa string é o mesmo hash que está armazenado para o joaozinho no BD. Se ele continuar testando valores que considera prováveis de serem usados como senha, ele pode, eventualmente, acabar fazendo:

>>> print hashlib.md5('teste123').hexdigest()
aa1bf4646de67fd9086cf6c79007026c

Então ele terá descoberto a senha do usuário pedrinho, pois o hash gerado para teste123 possui o mesmo valor que está armazenado para esse usuário. A esse tipo de ataque, chamamos de Ataque por força bruta.

Imagino que você esteja pensando que o invasor terá muito trabalho para descobrir a senha do usuário maria, testando milhões de possibilidades antes de chegar em t35t3. Pois é. Se ele for testando manualmente, dificilmente irá descobrir a senha. Mas imagine agora que o invasor tenha escrito um programa que gere uma tabela gigantesca contendo possíveis senhas e seus hashes:

+----------------------------------+---------------------+
|              HASH                |       SENHA         |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+
| 698dc19d489c4e4db73e28a713eab07b | teste               |
+----------------------------------+---------------------+
| e959088c6049f1104c84c9bde5560a13 | teste1              |
+----------------------------------+---------------------+
| 38851536d87701d2191990e24a7f8d4e | teste2              |
+----------------------------------+---------------------+
| 56c1056afb34f0d5ad809821d417a52b | t3st3               |
+----------------------------------+---------------------+
| 2a1bdbdad93b1081007abc4b419d8f0b | t35t3               |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+
| 128ecf542a35ac5270a87dc740918404 | bla                 |
+----------------------------------+---------------------+
| 14a310c18e7ee2627b3de4ff82b11e76 | bl4                 |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+

Tendo essa tabela pré-calculada, uma vez que o invasor esteja de posse do hash da senha da maria (2a1bdbdad93b1081007abc4b419d8f0b), basta pesquisar por esse hash na tabela de hashes. Se encontrar um registro que possua tal hash, basta obter a senha que o acompanha.

É evidente que essa tabela deve ser gigantesca, gigantesca mesmo, para conter uma boa quantidade de combinações de valores de senhas. Para “facilitar o trabalho”, invasores do mundo todo colaboram na criação e busca em tabelas desse tipo. Essas tabelas são conhecidas como Rainbow Tables.

Não só isso, os próprios usuários colaboram com os invasores, usando as mesmas senhas em vários lugares, ou usando palavras simples de adivinhar, de forma que bem antes duma tabela dessas cobrir todas as possibilidades de hash, ela já pode ser extremamente útil para os invasores.

Lição número 2: O HASH SOZINHO NÃO FAZ MILAGRE!

Evitando as Rainbow Tables

Para lidar com isso, existe uma técnica chamada de salgar senhas (tradução literal do inglês “salting passwords”), que consiste em adicionar um “temperinho” na senha antes de armazenar. A idéia é gerar uma string contendo alguns valores aleatórios e concatenar essa string à senha do usuário na hora gerar o hash. Assim, ao invés de tomar somente a senha do usuário como entrada, a função de hashing passa a tomar como entrada também a string aleatória (chamada de salt, ou sal). Esse sal também é armazenado no BD para que posteriormente seja possível que o serviço de autenticação realize a verificação.

O que isso traz de segurança para o sistema? Vamos visualizar uma tabela que armazena o nome do usuário, o hash da concatenação entre senha e sal, e o sal. A senha de cada usuário é a mesma senha mostrada lá no início do post.

+-----------+
| USUARIOS  |                                  
+-----------+----------------------------------+-----------+
| NOME      |       HASH DE (SENHA+SAL)        |    SAL    |
+-----------+----------------------------------+-----------+
| joaozinho | e3e923b2c0d3890270a2cb6d52b13bf6 |   h6ja8   |
+-----------+----------------------------------+-----------+
| pedrinho  | 046b8f04069efab205d9f7bcc099e3d3 |   5uoWB   |
+-----------+----------------------------------+-----------+
| maria     | 960e18e4dc393660fdf3caba8634f38e |   jtm7a   |
+-----------+----------------------------------+-----------+

Veja como foram gerados os hashes armazenados:

>>> print hashlib.md5('teste'+'h6ja8').hexdigest()
e3e923b2c0d3890270a2cb6d52b13bf6
>>> print hashlib.md5('teste123'+'5uoWB').hexdigest()
046b8f04069efab205d9f7bcc099e3d3
>>> print hashlib.md5('t35t3'+'jtm7a').hexdigest()
960e18e4dc393660fdf3caba8634f38e

Está achando estranho o fato de termos armazenado o sal em texto puro no BD? Pois é, se o invasor roubar nossa base, ele terá de lambuja o valor do sal. Mas isso não é um problema, pois o objetivo principal de salgarmos a senha é impossibilitar a utilização de rainbow tables, afinal a idéia principal por trás dessas tabelas é o cálculo prévio dos hashes de vários valores. Ao roubar o sal e o hash de uma senha, o invasor teria que recalcular toda a rainbow table para poder descobrir a senha do usuário. E essa tarefa é muito custosa.

Assim, se cada usuário possuir um sal diferente, a rainbow table terá que ser recalculada para cada usuário, tornando essa atividade praticamente impossível.

Considere que o invasor possui a rainbow table abaixo, bem como o hash (e3e923b2c0d3890270a2cb6d52b13bf6) e o sal (h6ja8) do usuário joaozinho (roubados da base de dados de usuários).

+----------------------------------+---------------------+
|              HASH                |       SENHA         |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+
| 698dc19d489c4e4db73e28a713eab07b | teste               |
+----------------------------------+---------------------+
| e959088c6049f1104c84c9bde5560a13 | teste1              |
+----------------------------------+---------------------+
| 38851536d87701d2191990e24a7f8d4e | teste2              |
+----------------------------------+---------------------+
| 507eb04c9c427e9f961e47a7204fac41 | teste3              |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+
| 128ecf542a35ac5270a87dc740918404 | bla                 |
+----------------------------------+---------------------+
| df5ea29924d39c3be8785734f13169c6 | blabla              |
+----------------------------------+---------------------+
| ...                              | ...                 |
+----------------------------------+---------------------+

Para obter a senha do usuário, o invasor terá que recalcular toda a tabela. Por exemplo, terá que calcular o hash de “testeh6ja8”, de “teste1h6ja8”, e assim por diante, até encontrar o hash correspondente. Considerando que ela pode ter zilhões de registros, essa é uma tarefa bastante demorada. Imagine recalcular toda a tabela para todas as possíveis combinações de valores no sal.

Perceba que o sal que utilizamos é bastante curto. Quanto mais longo for o sal, mais protegidas contra rainbow tables as senhas estarão, pois o número de combinações possíveis de valores para o sal aumentam exponencialmente.

Dessa forma, o sal derruba a maior força das rainbow tables, que é a busca rápida por elementos (que ocorre graças ao cálculo prévio dos valores). Ao usar valores de sal suficientemente longos, estamos aumentando MUITO (MUITO MESMO) a quantidade de entradas que uma rainbow table deve ter para servir como uma base de hashes pré-calculados (segundo a Wikipedia, hoje em dia são usados salts de até 128 bits). Se, além disso, usarmos um sal diferente para cada usuário, então tornamos impossível o uso de tabelas pré-computadas para a descoberta das senhas dos nossos usuários.

Mas, ainda assim, hashes salgados não são a solução definitiva para armazenamento de senhas. Leia a próxima seção para descobrir o porquê.

O mecanismo correto

Mesmo sendo um mecanismo muito mais seguro do que armazenando a senha em texto puro ou o hash simples, o armazenamento de hashes de senhas salgadas ainda não é a melhor solução. Apesar de amplamente utilizados, os algoritmos de hashing como MD5 e SHA-1 não são recomendados para o armazenamento de senhas, pois são bastante velozes para realizar o hashing de um valor. Um algoritmo rápido torna a geração de ataques via força bruta e rainbow tables mais fácil, pois o tempo necessário para gerar as tabelas acaba sendo pequeno.

Um algoritmo para uso no armazenamento de senhas tem como requisito ser lento. Lento o suficiente para atrapalhar o atacante, mas não o bastante para atrapalhar o usuário.

Uma forma recomendada de armazenar as senhas dos usuários é usando o bcrypt. O BCrypt é um mecanismo criptográfico criado para lidar com senhas. Assim sendo, uma de suas características é ser demorado para geração do hash.

Para ter uma idéia da diferença na velocidade dos dois mecanismos, observe o resultados de uns testes que fiz usando o timeit:

$ python -m timeit -s "import bcrypt; salt = bcrypt.gensalt()" "bcrypt.hashpw('teste', salt)"
10 loops, best of 3: 243 msec per loop

$ python -m timeit -s "import hashlib" "hashlib.md5('teste')"
1000000 loops, best of 3: 0.409 usec per loop

Enquanto o MD5 gera os hashes em uma média de 0.409 microsegundos por hash, o bcrypt leva em média 243 milisegundos por hash.

Instalando o bcrypt

A implementação Python do bcrypt não está disponível com a biblioteca-padrão, portanto é necessário instalá-la através do gerenciador de pacotes pip:

sudo pip install py-bcrypt

Obs.: o módulo é escrito em linguagem C, portanto o código será compilado. Para isso, é necessário possuir instalados (em sistema Ubuntu): build-essential e python-dev.

Alternativamente, num sistema Debian ou Ubuntu você pode instalar o pacote no repositório do apt:

sudo apt-get install python-bcrypt

Usando o bcrypt

Assim como a maioria dos módulos Python, o bcrypt é facinho de usar. Vamos fazer alguns exemplos.

Gerando o hash de uma senha

>>> import bcrypt
>>> print bcrypt.hashpw('teste123', bcrypt.gensalt())
$2a$12$axTaPizQ6q2V8VCLseqEq.Rwm1aZVx7oimvjPmmLWTNE3uW15xpIu

Execute o código acima no seu interpretador Python local e perceba a diferença no tempo de resposta entre o bcrypt e o MD5.

Verificando a senha do usuário

Para verificar se determinado hash é correto, devemos passá-lo como argumento para a função hashpw, juntamente com a senha:

>>> print bcrypt.hashpw("teste123", "$2a$12$axTaPizQ6q2V8VCLseqEq.Rwm1aZVx7oimvjPmmLWTNE3uW15xpIu")
$2a$12$axTaPizQ6q2V8VCLseqEq.Rwm1aZVx7oimvjPmmLWTNE3uW15xpIu

Se ela retornar o mesmo hash que foi passado como argumento, é porque o hash corresponde à senha passada como primeiro argumento.

Podemos então criar uma função de validação de senha de usuário:

def valida_senha(senha_digitada, hash_senha):
    return bcrypt.hashpw(senha_digitada, hash_senha) == hash_senha

Um sistema de autenticação usando BD

Vamos agora implementar um mecanismo para autenticação de usuários, usando sqlite3 e bcrypt.

# -*- encoding:utf-8 -*-
import bcrypt
import sqlite3

def valida_senha(senha_digitada, hash_senha):
    return bcrypt.hashpw(senha_digitada, hash_senha) == hash_senha

def insere_usuario(conexao, usuario, senha):
    hash_senha = bcrypt.hashpw(senha, bcrypt.gensalt())
    conexao.execute('insert into USUARIOS values ("%s", "%s")' % (usuario, hash_senha))
    conexao.commit()

def usuario_autenticado(conexao, usuario, senha):
    cursor = conexao.execute('select SENHA from USUARIOS where NOME = "%s"' % (usuario,))
    dados = cursor.fetchone()
    hash_senha = str(dados[0])
    return valida_senha(senha, hash_senha)

# alguns testes
if __name__=='__main__':
    conexao = sqlite3.connect('arquivo.db')
    insere_usuario(conexao, 'maria', 'teste')
    insere_usuario(conexao, 'joao', 'teste123')
    if usuario_autenticado(conexao, 'joao', 'teste123'):
        print 'joao está autenticado!'
    else:
        print 'Xiiiii...'

 

Antes de terminar …

O post mostrou quão simples é a implementação de um mecanismo seguro para armazenamento das senhas dos usuários em um banco de dados. Agora você não tem mais desculpas para implementar a autenticação usando senhas armazenadas em texto puro.

Se você armazena as senhas em texto puro, é fácil alterar seus algoritmos de autenticação e gerar os hashes das senhas existentes (faça backup antes, claro :)). Vale a pena gastar um tempinho corrigindo isso em seu sistema.

Finalizando, o py-bcrypt é tão simples de ser utilizado que me deixa à vontade para deixar como lição final:

LIÇÃO FINAL: USE O BCRYPT PARA ARMAZENAMENTO DE SENHAS DE USUÁRIOS!

LIÇÃO DEFINITIVA: NÃO SEJA RELAPSO COM AS INFORMAÇÕES DOS SEUS USUÁRIOS!

Leia mais sobre o assunto

Em inglês:

P.S.: obrigado ao eliasdorneles por ter revisado esse post. 🙂

Apresentando o SQLite com Python

(este é o primeiro post do eljunior, o novo colaborador do pythonhelp)

Então você vem acompanhando há algum tempo o pythonhelp, e já está cheio de idéias para criar seus programas usando Python, sua linguagem preferida. Se você já começou a fazer alguma coisa, provavelmente já se deu conta que existem muitas questões relacionadas a guardar e acessar os dados utilizados pelo seu programa, seja ele uma mega-aplicação para controle de estoque ou um programa para fazer o gerenciamento da sua coleção de tazos (nossa, isso é muito anos 90..!).

Felizmente, muitos desses problemas já foram resolvidos, e você só precisa selecionar a ferramenta certa que irá ajudá-lo a completar sua tarefa com sucesso. Entram em cena os poderosos sistemas de bancos de dados. Sistemas de bancos de dados são para informações o que Python é para código: você pode viver sem eles, mas sua vida é muuuito mais fácil com eles. Usando banco de dados, você se preocupa com O QUE você vai armazenar, e PARA QUE você vai usar essas informações, sem ter que se preocupar demais em COMO você irá guardar tudo no disco, o leiaute dos arquivos, acessá-los eficientemente e ainda deixar tudo isso flexível pra o caso de você ter que alterar alguma coisa depois.

De uma forma bem resumida, trabalhar com banco de dados geralmente envolve o seguinte:

  1. Definir um modelo de dados (schema), isto é, quais tipos de dados você vai armazenar no banco, e como eles se relacionam. Você decide, por exemplo: “Vou armazenar informações sobre álbuns, que devem conter título, ano de lançamento, gênero e artistas. Artistas, por sua vez, conterão nome artístico, nome completo opcional, data provável de nascimento, e data de falecimento opcional.” Você faz isso usando a linguagem SQL (“Structured Query Language” == “Linguagem Estruturada para Pesquisa”), definindo tabelas e colunas, e os tipos de dados relacionados.
  2. Definir operações a serem feitas no banco de dados, a partir do schema definido. Por exemplo: “Em dado instante, a aplicação deverá adicionar informações de um álbum ou artista no banco de dados.” Ou, “quando o usuário clicar nesse botão, a aplicação deverá listar todos os álbuns ordenados por ano de lançamento”. Essas operações são chamadas de “queries” (consultas), e usualmente envolvem alterar os dados no banco ou buscar dados que estão guardados nele.
  3. Repetir os passos acima tantas vezes quanto for necessário — ou seja: eternamente… :).

Pois bem, hoje queremos apresentar-lhe um desses sistemas de banco de dados, o SQLite, que possui algumas características interessantes que o diferenciam de outros mais tradicionais (tipo MySQL, PostgreSQL, SQL Server, etc), é muito fácil de usar em Python e pode muito bem ser útil no seu próximo programa em Python.

O SQLite é o que chamamos de um banco de dados embutido, ou seja, é um banco de dados que cabe inteirinho em sua aplicação, sem precisar de um processo servidor como os sistemas de banco de dados mais tradicionais. Seu uso é muito popular em diversas aplicações para armazenar dados na máquina de um usuário. De fato, se você usa o Firefox, saiba que suas preferências de usuário, o histórico de sua navegação e diversas outras informações, são todas armazenadas em arquivos SQLite. Isso é legal porque fica muito fácil de carregar as informações desses arquivos e cruzá-las conforme for necessário, inclusive a partir de programas externos que “conheçam” SQLite. 1

Como você é inteligente e está usando Python, que vem com baterias inclusas, você já tem a sua disposição o módulo sqlite3, ao alcance de um simples import sqlite3. 2

O código abaixo usa o módulo sqlite3 para ler o arquivo que contém o banco de dados com o histórico de downloads do Firefox, e imprime no console o nome dos arquivos e o tipo MIME:

import os, sqlite3
from glob import glob

user_directory = os.path.expanduser('~')
files = glob(user_directory + '/.mozilla/firefox/*/downloads.sqlite')
if len(files) > 0:
    # abre o banco de dados, 'conecta':
    conn = sqlite3.connect(files[0])
    # executa uma consulta, selecionando o nome e tipo da tabela moz_downloads:
    cursor = conn.execute('SELECT name, mimeType FROM moz_downloads')

    # percorre os resultados da consulta, mostrando-os na tela:
    download = cursor.fetchone()
    while download:
        print download
        download = cursor.fetchone()
else:
    print 'Nao consegui achar nenhum arquivo com historico de downloads :('

É isso aí, a partir de agora você está oficialmente autorizado a explorar o SQLite nos seus próximos programas Python. 🙂

Você também pode querer testar aplicativos como o SQLite Browser, ou a extensão pro Firefox SQLite Manager, que permite você visualizar e modificar qualquer banco de dados SQLite no seu computador.

Veja mais sobre o SQLite em:

Notas:

1 Originalmente, o SQLite é uma biblioteca escrita em C, mas existem bibliotecas disponíveis para muitas outras linguagens. O suporte em Python é diferenciado porque já o inclui na instalação padrão.

2 O módulo sqlite3 está disponível por padrão em qualquer instalação Python, com versão maior ou igual 2.5. Caso você estiver usando um Python mais antigo, você ainda pode instalar o módulo sqlite3 disponível aqui