A razão para eu tentar me livrar do Google é o temor de ficar tão dependente de um serviço deles e eles simplesmente resolverem descontinuar como fizeram com o Code Search, Reader, entre outros. É muito mais uma questão de confiabilidade do que privacidade, monopólio, etc.

Uma das coisas difíceis de se substituir é o Google Search. Principal produto da empresa. Para essa tarefa eu escalei o DuckDuckGo que, apesar do nome inusitado, já havia se motrado um excelente buscador em testes que eu havia feito anteriormente.

O DuckDuckGo tem duas “funcionalidades” interessantes. Uma delas é um respeito maior à privacidade de seus usuários. A outra é a ausência de filtros bolha.

Quando fui avaliar melhor a questão relacionada a filtros bolhas meu cérebro tomou uma linha de raciocínio que seguiu em direção à diversidade de opinião e a tolerância que temos à essa diversidade.

Vou tentar usar fatos atuais para ilustrar a minha linha de raciocínio e para isso terei que trabalhar com assuntos polêmicos relacionados à amor, ódio, religião, ateísmo, homossexualismo, etc.

Também vou partir da premissa de que todo mundo na internet, hoje, tem opiniões fortes sobre todos os assuntos. Dos royalties do petróleo ao dinheiro gasto para mandar a Curiosity para Marte.

O conceito de “filtro bolha” que o Google Search implementa faz com que assuntos que tenham mais relação com o seu histórico de pesquisa tenha um ranking melhor do que algo que não “combine” com você.

O resultado desse comportamento é que o Google Search vai sempre lhe oferecer “mais do mesmo” ao longo do tempo e aquilo que diverge das suas opiniões vai simplesmente sumindo dos resultados criando uma “bolha protetora” de opiniões.

Nas redes sociais isso também acontece mas de uma maneira mais explícita: você oculta as opiniões divergentes, o sistema ‘aprende’ que você não gosta daquilo e nunca mais te manda informações daquele tipo (ou daquela pessoa).

Frequentemente me pego “censurando” alguns posts nas minhas timelines quase que de modo inconsequente.

Sou ateu (mesmo) e acho que todos podem crer ou, como no meu caso, não-crer, no que lhes deixam felizes.

Sou heterossexual mas entendo o homossexualismo sob o aspecto cientifico dos estudos que dizem que as pessoas são homossexuais e não se tornam homossexuais por opção (ou com o passar dos anos).

No espectro político eu piso um pouco mais à esquerda do que à direita e tenho vínculo com um partido político que representa essa posição. Apesar disso sei que existem virtudes na “direita” e pessoas extremamente inteligentes que trafegam nessa vertente.

A minha linha-mestra de pensamento: se você está feliz e não está me tornando infeliz você pode fazer e acreditar no que achar melhor.

Apesar disso sou humano e cometo erros de julgamento e avaliação.

Recentemente, com a chegada de um pastor evangélico fundamentalista à presidência da Comissão de Direitos Humanos da Câmara dos Deputados, as redes sociais estão fervendo com assuntos relacionados à cristianismo, laicismo, homossexualismo, racismo, e outros “ismos”.

Pra mim, na minha timeline, é um festival de surpresas e decepções com pessoas que fazem parte do meu “círculo virtual de amizades”. Até aí não tem nada de errado. O problema aparece é na escolha dos critérios que te fazem ficar surpreso ou se decepcionar.

Sendo ateu eu poderia me decepcionar com uma pessoa quando ela defende parcimoniosamente o discurso do tal pastor demonstrando trechos bíblicos que corroboram tais opiniões (mesmo sabendo que com trechos da bíblia é possível corroborar qualquer tese). Essa pessoa é crente e tem pra ela que esse livro é sagrado, logo, tem força maior que a “lei dos homens”.

Mas eu não posso me decepcionar com essa pessoa e censurá-la na minha timeline porque, com isso, estaria alimentando o meu filtro bolha e mandando a diversidade de opinião às favas. No lugar de censurá-la eu prefiro debater com essa pessoa ou simplesmente deixá-la com suas opiniões, afinal, ela deve ser feliz com aquele pensamento.

Agora vamos para outra hipótese: esse mesma pessoa que citou a bíblia me decepcionaria muito se usasse uma mentira, um estudo científico duvidoso, uma fonte de origem duvidosa, ou até mesmo usar desonestidade intelectual para, por exemplo, “provar que homossexualismo é errado”.

Eu tenho duas reações possíveis com pessoas que me decepcionam dessa forma. Se a pessoa é muito cara para mim eu rebato o post dela para tentar desmenti-lo. Se a pessoa “não cheira nem fede”, ela será censurada. Mas veja que eu censurei essa pessoa por ser desonesta e não por ser crente.

Qualquer tipo de censura cria o efeito “bolha” mas a bolha que eu criei é uma bolha de segurança para me proteger contra pessoas desonestas e não pra me privar da diversidade de opinião.

Além dessa censura aos desonestos eu também censuro, com menos frequencia, os “ativistas”. Censuro eles não pelo que pensam e defendem mas pelo excesso. É uma questão puramente prática: tenho um limite de tempo para ver a minhas timelines. Se elas estão monopolizadas pelos “ativistas” fica difícil ver os posts de todo mundo.

Além disso, ativistas, sejam felizes com o que pensam e defendem e me deixem ser feliz com o que penso e defendo. Parem de se comportar como Testemunhas de Jeová oferencendo a palavra do senhor.

Quanto ao caso do tal pastor: não acho que ele seja adequado para a tal comissão e acho que ele deveria sair de lá. Mas não devemos ser desonestos para atingir esse objetivo.

Não concordo com uma palavra do que dizes, mas defenderei até o ultimo instante seu direito de dizê-la.

Eu havia decidido dar um tempo com esse blog porque eu gastava muito tempo escrevendo os posts que eram publicados por aqui. Eu gastava muito tempo porque sempre tentava manter referências, créditos e ilustrações nos artigos.

A partir de agora me dei o direito de não ser tão detalhista nos meus posts e, provavelmente, usarei este blog como uma memória paralela onde guardarei informações que provavelmente me esqueceria se não anotasse em lugar nenghum.

Vou tentar postar alguns pacotes de links para coisas interessantes na web ou até mesmo algumas traduções.

Apesar do nome do blog ser Pythonologia não vou me restringir a falar de Python. Mas tratarei só de assuntos técnicos e/ou profissionais da área de TI.

Assuntos de cunho pessoal, opiniões sobre política, religião e futebol ficarão em outro blog que será atualizado bem mais esporadicamente que este aqui.

Alguns palestrantes internacionais já confirmaram presença e estamos em negociação com outros três palestrantes.

A chamada de trabalhos ainda não está aberta porque estão trabalhando em algumas modificações no sistema de submissão que vão permitir que as propostas sejam modificadas durante todo o período de submissão.

As propostas que forem submetidas também ficarão abertas para que todos os associados da Associação Python Brasil tenham mais tempo para ir avaliando os trabalhos. Será possível submeter links para videos e slides que ajudem a “promover” a proposta.

Assim que o período de submissão de trabalhos se encerrar as modificações serão barradas e os associados da Associação Python Brasil receberão instruções para avaliar quais trabalhos deverão ser apresentados no nosso evento.

Já é a sétima edição do encontro anual de programadores Python do Brasil. Todas as edições foram fantásticas. Esse ano vamos experimentar um novo modelo de evento. Um evento mais “profissionalizado”, com uma estrutura melhor e com o apoio de vários patrocinadores de peso.

Ou seja, temos tudo para fazer a PythonBrasil[7] ainda melhor esse ano.

Espero poder me encontrar com vocês por lá.

Ajude a divulgar

A gente sabe que a melhor forma de divulgação que existe é o ‘boca-a-boca’ e todo ano a gente conta com o apoio dos entusiastas de Python para nos ajudar na divulgação do evento.

Para facilitar a vida de quem quer ajudar montamos a página “Divulgue a PythonBrasil[7]” onde vocês poderão encontrar as instruções e o material necessário para ajudar nessa tarefa.

Se você já foi à uma PythonBrasil, publique no seu blog histórias legais sobre o evento. Se ainda não foi, publique no seu blog o que você espera encontrar no evento. Depois é só enviar o link para a notícia no site do evento para aparecer como um “Site Amigo“.

Se você não tem um blog mas tem Twitter, Facebook, Orkut, etc… divulgue o evento entre seus amigos e seguidores (usando a hashtag #pythonbrasil7).

Se vai fazer uma apresentação sobre Python em algum evento convide a sua audiência para participar do nosso encontro.

Quero ver o auditório lotado! :D

Confesso que passei o dia todo tentando bolar uma forma bem humorada de comemorar o aniversário dele, porque ele era super bem-humorado, mas não consegui.

A homenagem que eu tentei fazer pra ele no dia do aniversário dele era conseguir uma camisa do Internacional (o “Colorado”) e usá-la durante todo o dia, fotografar, e colocar aqui. Mas não consegui uma camisa que coubesse em mim :/

O Déo era torcedor do Colorado e eu sou corinthiano. Da comunidade Python eu, ele e o Érico eramos dos poucos que se interessavam por futebol.

Como não consegui fazer essa homenagem tentei algo mais “tradicional”. Escrever um post num blog tal como os outros amigos fizeram. Também não deu.

Todas as tentativas resultaram em textos tristes, porque é tristeza que sinto agora, e um texto triste não serveria pra homenagear o aniversário do Déo. Não existia tristeza ou mal-humor com o Déo.

Tentei, então, um post com histórias vividas com ele. Difícil terminar também… a visão começava a ficar ‘desfocada’ pelas lágrimas e, assim, não dava pra continuar…

Também pensei em não falar nada na tentativa de enganar minha cabeça fazendo-a pensar que o Déo não tinha sofrido nenhum acidente e que comemoraria seu aniversário jogando Wii com sua família. Mais uma frustração. As homenagens dos outros amigos teimavam em me lembrar da verdade o tempo todo.

Vi que várias homenagens ao Déo falavam da sua capacidade técnica e de suas colaborações com código para vários projetos de software livre. Resolvi então tentar falar sobre outra característica importante dele: empreendedorismo.

Todos sabem que estou num momento “empreendedor” e que estou vivendo isso intensamente. E o Déo era uma referência pra mim nesse assunto. E ele também “propagava” essa mensagem sempre que podia.

Mas não daria pra homenageá-lo adequadamente falando só disso. Seria muito pouco.

Então vou desistir de participar do #dornelesday. Admito que é um problema muito difícil pra resolver. O tipo de problema cuja solução só o Déo poderia me ajudar a encontrar.

Vocês poderão encontrar mais informações no site do encontro.

Para participar é só se inscrever no formulário disponível em: http://bit.ly/1meetupPR. Não é necessário pagar inscrição e o único custo fica por conta dos R$10 de consumação da Casa di Bel.

O que é um Startup Meetup?

Explicação curta e informal: Um Happy Hour para ‘startupeiros‘.

Explicação mais formal: é um encontro informal de empreendedores de uma cidade para um bate-papo sobre seus planos, projetos e empreendimentos. Esses encontros tendem a acontecer com uma certa regularidade e visam fortalecer o ambiente de negócios e empreendedorismo na cidade onde ele acontece.

Os Meetups geralmente acontecem num bar para que as pessoas possam comer, beber e conversar mais à vontade.

Ajude a Divulgar

O evento é organizado por empreendedores para empreendedores de forma voluntária e, por isso, precisamos da ajuda de todos na divulgação que pode se dar dos seguintes modo:

• Avise os seus amigos da imprensa;
• Divulgue no seu blog;
• Divulgue no seu Twitter (usando o link encurtado: http://bit.ly/1meetupPR);
• Anuncie e divulgue no Facebook (“curta” a página do encontro);

Como estamos?

No momento em que eu escrevo esse post temos 27 inscritos no formulário. Se compararmos com o que os Startup Meetups de outras cidades é muito pouco, portanto, vamos agitar isso aí! :D

O evento tá logo aí: 1º de março de 2011! (terça-feira antes do carnaval).

Apoios

A organização local está contanto com o apoio de diversas empresas que ajudam na organização desses encontros em todo o Brasil, entre elas: Aceleradora, Samba Tech e Read Write Web Brasil.

Entre em contato

Caso tenha alguma dúvida ou queira colaborar com a organização do evento de algum modo entre em contato comigo ou com o Diego.

Hoje, infelizmente, algo ruim aconteceu com o Dornéles Treméa. O Deo era um grande amigo meu, amigo do meu sócio na Triveos (o Marcos Petry), participante ativo da comunidade Python (ele era o nosso presidente) , importante membro e desenvolvedor na comunidade Plone mundial, e o maior homem do mundo para sua esposa e suas duas garotinhas lindas.

Ele se foi num acidente de carro. Num daqueles dias que você jamais imaginaria perder um amigo.

1. Triveos Tecnologia

A Triveos é a minha empresa e tenho, como sócio técnico, o pythonista Marcos Petry. Não chega a ser uma “equipe” mas já dá pra fazer um bom estrago ;D

Aqui na Triveos a gente não tem preconceito contra nenhuma tecnologia (nosso site e blog rodam em PHP e somos membros do Microsoft Bizspark).

Eu particularmente tenho algumas “birras” com alguns softwares que já me torturaram no passado: Trac, Nagios, Squirrelmail, Bazaar, etc.

2. Git, Github, Codebase

Nós gostamos muito de usar DVCS e adoramos o Github para hospedar nossos (poucos :/) projetos open-source. Gostamos das ferramentas de apoio à criação de grupos de desenvolvedores que eles oferecem.

Usamos o Git por conta do Github. Mas usaríamos Mercurial se o Bitbucket fosse tão bom quanto.

No nosso dia-a-dia a gente lida com projetos de clientes e/ou de código fechado e para esses projetos nós achamos melhor procurar um local mais “tranquilo” pra hospedá-los. Sem o oba-oba, “excessos” do Github e com um suporte mais “rápido” à eventuais problemas.

Então contratamos um plano no Codebase. Lá eles oferecem hospedagem de código com repositórios Git, Mercurial ou SVN. Também disponibilizam um sistema de Tickets/Milestones e Wikis para projetos.

3. Tecla, Webfaction e Linode

Para hospedagem em produção preferimos usar o Linode (e eu indico a todos que querem um serviço simples e de qualidade).

Mas em alguns projetos (leia-se Ludeos) temos algumas exigências relacionadas a comprovação de gastos. Nesses casos usamos o Cloud da Tecla. Eles são melhores que a Locaweb mas ainda são infinitamente inferiores a qualquer hosting similar nos EUA. E nem estou falando de preço (o pior deles, IMHO, é o sistema de cobrança).

Os sites mais simples (e blogs) ficam numa conta compartilhada simples no Webfaction. Para colocar um WordPress “no ar” com poucos cliques é uma baita ferramenta. Mas costumo notar certa lentidão no acesso às páginas de tempos em tempos.

4. Vim, Textmate e nada de IDEs

Uso principalmente o Vim mas me viro bem com o Textmate também. Dependendo da minha “vibe” eu uso um ou outro.

Recentemente passei a usar o MacVim mas ainda não estou me dando muito bem com ele. Vou insistir mais um pouco pra ver se me acostumo.

Nossos funcionários usam Eclipse+PyDev… engraçado isso… :D

5. Python (… JS, Ruby, C, Shell Script, Java, PHP, …)

Aqui na Triveos é assim: se a bola foi lançada a gente mata ela no peito e chuta pro gol! :D

É claro que a gente seria mais feliz usando só Python, mas não dá pra fazer isso sempre.

Para desenvolvimento web nós usamos Django mas já namoramos o Flask, o Repoze.BFG (Pyramid), e diversos outros frameworks web feitos em Python.

Já usamos jQuery (apesar de eu não gostar dessa biblioteca) e estou estudando YUI3 seriamente a algum tempo.

6. OS X e Ubuntu Linux

OS X pra criar e Ubuntu pra produzir em massa. :D

Já usamos CentOS e Debian em ambientes de produção mas eu detesto lidar com software velho. Então adotamos uma alternativa mais “arriscada”? E usamos a última versão de Ubuntu disponível. Procuro sempre atualizar os ambientes de produção.

Instanciamos uma máquina com o Ubuntu mais novo “nas nuvens”, rodamos um comando de setup/deployment e pimba! servidor novo, com software atualizado e rodando…

…mas isso só é possível em projetos onde usamos “Continuous Deployment”… e ainda estamos aprendendo a fazer isso direito. Quando estivermos “fera” nisso pretendo escrever sobre o assunto aqui.

Mas se alguém quiser uma idéia do que planejo pode ver no artigo Python deployment tips do Lorenzo Gil.

7. Ambiente

Uso o Terminal.app (mas tenho planos de experimentar o iTerm) com bash configurado para modo vi no prompt.

Uso:

• Python 2.7 (baixado do python.org)
• virtualenv
• Algumas personalizações no shell
• Alguns pacotes do Rudix (não instalo tudo por conta da versão do git dele)
• git do site oficial

Passando a bola pra frente

Agora é a vez dos colegas:

• Marinho Brandão (@marinhobrandao)
• Arthur Furlan (@arthurfurlan)
• Marcos Petry (@petry)

… descreverem seus ambientes :D

E se formos voltar no tempo vamos descobrir que todo ano temos pelo menos 2 ocorrências similares em sites grandes. E isso vem acontecendo ano após ano desde que a Internet se tornou acessível entre “civis”.

Se todos os usuários usassem senhas diferentes para cada um dos serviços que usa na internet o estrago causado por esse tipo de situação seria bastante limitado. Mas não é isso o que acontece e, quando senhas “vazam” na internet o estrago pode ser gigantesco.

Problema antigo. Solução conhecida.

Em 1994 fui fazer estágio na Telesp no interior de São Paulo. Lá eu tive meu primeiro contato “sério” com um Unix. Era um SCO Unix que rodava num 386SX com 7 terminais seriais.

Enquanto eu estava aprendendo a usar o Unix eu vi que tinha um arquivo chamado /etc/passwd e, pelo nome, imaginei que lá eu encontraria as senhas de usuários do sistema.

Naquela época eu era “metido a hacker” e fiquei entusiasmado com a idéia de descobrir a senha de todo mundo que usava aquele servidor. Fiquei mais animado ainda quando vi que as permissões do arquivo permitiam que qualquer usuário examinasse seu conteúdo.

Quando abri o arquivo veio a decepção… no lugar onde deveriam ficar as senhas estava um “x”. Mas não me dei por vencido. Após estudar as manpages (que viam impressas em manuais imensos!) fiquei sabendo que as senhas não estavam lá. Elas estavam no arquivo /etc/shadow.

Com o ânimo renovado fui atrás desse arquivo. Mas dessa vez as coisas estavam um pouquinho mais difíceis… só o usuário root conseguiria ver esse arquivo.

Chegou a hora, então, de uma pitada de engenharia social… não vou contar como fiz porque foi muito fácil mas consegui a senha de root do sistema… hora de ver a senha dos outros usuários da Telesp e implantar uma mega-revolução na telefonia brasileira!… erm… menos…

Quando abri o arquivo tomei uma ducha de água fria definitiva. No lugar onde as senhas deveriam estar eu só um amontoado de caracteres que não se pareciam com senhas. Até poderiam ser as senhas dos usuários mas parecia muito improvável (e de fato não eram).

Descobri depois que o que estava armazenado ali era o resultado de uma espécie de “criptografia”. Ou seja, em 1992 os sistemas Unix já não armazenavam as senhas em texto puro. É bem provável que eles já não fizessem isso a muito mais tempo.

Estamos em 2011. Se depois de 19 anos eu armazenasse as senhas dos meus usuários em “texto puro” eu deveria ser chamado de irresponsável e incopetente. Se um invasor tivesse acesso à essas senhas eu deveria ser tratado como criminoso. No mínimo.

A solução

A única solução correta e infalível para armazenar senhas de forma segura é: não armazená-las.

Aí você deve estar perguntando: se eu não armazenar a senha do usuário como eu consigo verificar a senha dele durante sua autenticação?

Uma resposta “básica” seria: armazene o hash da senha.

Segundo o HowStuffWorks brasileiro:

“Hash é resultado da ação de algoritmos que fazem o mapeamento de uma seqüência de bits de tamanho arbitrário para uma seqüência de bits de tamanho fixo menor de forma que seja muito difícil encontrar duas mensagens produzindo o mesmo resultado hash (resistência à colisão ), e que o processo reverso também não seja realizável (dado um hash, não é possível recuperar a mensagem que o gerou).”

Existem vários algorítmos para cálculos de hash. Cada um deles possui um determinado tipo de aplicação. As funções de hash mais “famosas” são aquelas cuja aplicação está no campo da criptografia: MD2, MD4, MD5, SHA1, SHA256, …

Vou demonstrar o que acontece com o MD5:

$ echo "123mudar" | md5sum
642d8860fc6fe3126803ebdbe9974abd
$ echo "123mudar" | md5sum
642d8860fc6fe3126803ebdbe9974abd
$ echo "123mudor" | md5sum
fe294bbc902c287efb7acb20c8fdb67a

Note que sempre obtemos o mesmo resultado quando a senha é a mesma mas quando mudamos 1 único caracter o resultado do cálculo de hash muda completamente.

Tendo isso em mente podemos pensar em armazenar no nosso banco de dados apenas o hash da senha do usuário. Quando for preciso verificar a senha informada pelo usuário aplicamos a função de hash à ela e comparamos com aquela que está armazenada no banco de dados.

Perfeito não é? Problema resolvido, não? Não! Ainda falta uma pitada de “sal” nessa receita…

Salt – mais uma dificuldade para o invasor

Vamos supor que um invasor tenha acesso ao banco de dados da aplicação e ao hash das senhas…

Com esses hashes o usuário pode disparar um ataque baseado em dicionários ou até mesmo procurar pelos hashes no Google! Veja o que acontece com uma senha “fraca”:

$ echo "senha" | md5sum
6fd720fb42d209f576ca23d5e437a7bb

Agora procure por “6fd720fb42d209f576ca23d5e437a7bb” no Google e veja o resultado :D

Para resolvermos esse problema devemos usar um “salt” para gerar o hash da senha.

Salt é uma sequência aleatória de bits que são concatenados à senha do usuário antes de gerar o hash (quanto maior essa sequência mais difícil será o trabalho do invasor).

Por ser uma sequência aleatória precisamos armazená-la junto com o resultado do hash para ser possível verificar a senha depois. Vamos à um exemplo “pythonico”

$ python
>>> import random
>>> import hashlib
>>> senha = "senha"
>>> salt = ''.join(chr(random.randint(65, 122)) for x in range(5))
>>> salt # Esse é o Salt!
'vGBAA'
>>> salt_senha = salt + senha
>>> salt_senha # salt + senha
'vGBAAsenha'
>>> hash = hashlib.md5(salt_senha).hexdigest()
>>> hash # Esse é o hash do salt+senha
'3607507cfa3f31b0cf10e83af947df97'
>>> armazenar = salt + "$" + hash
>>> armazenar
'vGBAA$3607507cfa3f31b0cf10e83af947df97'

Tente procurar pelo hash “3607507cfa3f31b0cf10e83af947df97” no Google agora… ou submeter esse hash à um ataque de dicionário… Você verá que aumentamos um pouco a dificuldade para descobrir a senha do usuário.

Esse é o procedimento usado por grande parte dos frameworks web que implementam alguma forma de armazenamento de senha (ex. django.contrib.auth). Ele é bastante seguro e podemos considerar isso satisfatório. Mas as coisas estão mudando…

A nuvem “do mal”

Com o advento da “computação na nuvem” chegamos à situação onde podemos comprar “poder de processamento” tal como compramos energia elétrica.

Antigamente se a gente tivesse um salt+hash em mãos era quase impossível (ou economicamente inviável) conseguir poder de processamento suficiente para submetê-los à um ataque de força bruta.

Mas as coisas mudaram e com 1 cartão de crédito e uma quantidade “viável” de dinheiro é possível contratar dezenas de “nós” de processamento na Amazon ECS, por exemplo, e colocá-los para “atacar” o nosso salt+hash.

Esse tipo de prática provavelmente já está sendo usada por alguns invasores pelo mundo e aparentemente não existe uma solução definitiva para esse tipo de situação.

O que existe são medidas que você pode adotar para dificultar um pouco mais a vida dos vilões :D

Uma delas é substituir o algoritmo de hash (MD5/SHA1) por outro algorítmo mais apropriado para o nosso uso.

O problema em usar os algorítmos MD5 e SHA1 para calcular os hashes de nossas senhas é que eles são muito eficientes e rápidos. As principais aplicações desses algorítmos exigem que eles sejam rápidos (ex. assinatura digital de um arquivo gigantesco).

Como eles são muito rápidos é possível disparar um ataque de força bruta e testar muitos hashes em um curto espaço de tempo. Como as plataformas na “nuvem” cobram por tempo de uso podemos quebrar uma senha à um custo relativamente baixo (ou viável economicamente).

Se trocarmos esses algorítmos por um que seja muito mais lento obrigamos o invasor a gastar mais poder de processamento (e consequentemente mais dinheiro) para descobrir nossa senha.

Um dos métodos mais indicados, hoje, é o bcrypt (blowfish). Existe implementações desse algorítmo para diversas linguagens:

• Python
• Ruby
• C#/.Net
• Java
• Perl
• Erlang
• C
• PHP

E como eu sei se um site armazena minhas senhas em texto puro?

Não é possível saber com 100% de certeza se um site ou serviço armazena as suas senhas em “texto puro”, portanto, o melhor mesmo é criar o hábito de usar senhas diferentes em cada um dos serviços (só tente não anotá-las em papéis! :D).

Mas apesar de não ser possível ter certeza se o serviço em questão é desenvolvido por um irresponsável é possível buscar indícios dessa irresponsabilidade:

• Receber um e-mail de confirmação de cadastro onde sua senha está presente – Se ele está te mandando um e-mail com sua senha é grande a possibilidade dela ser armazenada da mesma forma.
• Use a opção “esqueci minha senha” dos sites para testar – se você usar essa opção e o site te mandar um e-mail (ou mostrar na tela) a sua senha é porque eles tem a sua senha “original” armazenada em algum lugar. O correto é receber um link para *resetar* sua senha.

Implicações no “mercado”

Nós que trabalhamos com web e somos entusiastas da idéia “da nuvem” devemos condenar a prática de armazenar dados sensíveis do usuário de forma tão irresponsável. Cada notícia que surge dando conta de vazamentos dessas informações prejudica todos os serviços. Para um leigo é a segurança “da internet” que é falha.

Se você é um empresário ou desenvolvedor sério e responsável deve cuidar da segurança dos dados dos seus usuários com todo o cuidado e, sempre que ver outra empresa trabalhando de outra maneira você tem a obrigação de condená-la pois ela também está, indiretamente, prejudicando o seu negócio.

Atualização:

O meu amigo Guilherme Manika postou um link para um artigo onde a equipe do Gawker relata o problema ocorrido com as senhas de seus usuários.

Pelo que entendi eles armazenavam o hash das senhas usando a função crypt(3) e um salt com apenas 12 bits que, como disse, é muito pouco para os padrões de ataque atuais.

Então, em 2008, eles modificaram o sistema para usar o bcrypt() também. Mas, aí a ‘burrada’ deles: eles continuaram gerando o hash com crypt(3) e armazenando no mesmo lugar que os hashes bcrypt() pra manter compatibilidade retroativa!

Segundo um e-mail que circulou numa lista de segurança, 748.081 usuários tinham as senhas armazenadas com crypt() e 195.178 tinham as senhas armazenadas com crypt() e bcrypt(). Total: 943.259 usuários afetados. Quase um milhão de pessoas.

Esse post é pra avisar à todos que tem interesse em aprender Python e Django que o curso online de Desenvolvimento Web com Python e Django está pronto e disponível para compra em nossa plataforma Ludeos!

Esse curso é ideal para aqueles desenvolvedores Web que querem começar a usar Python e Django nos seus projetos e não tem um curso presencial à disposição.

Os videos são gravados no formato screencast e podem ser vistos quantas vezes for preciso. A compra é feita no nosso site de treinamentos online e o pagamento pode ser parcelado em até 12x no cartão de crédito (o pagamento é feito através do PagSeguro, ou seja, segurança total para sua compra).

Com esse curso a Triveos, agora, tem o mais completo pacote de treinamentos de Python e Django do país. Composto de:

• Curso in-company de Python e Django – voltado para empresas que querem qualificar os seus funcionários e deixá-los aptos a trabalhar com desenvolvimento de aplicações Web com Python e Django. O material didático é bastante completo: livro Python e Django, PDF com os 220 slides usados no treinamento, conteúdo adicional e prático sobre depuração e deployment Django, etc.
• Curso online em vídeo alta-definição – Mais de 8hs de vídeo no formato em alta-definição (720p) cobrindo a maior parte do conteúdo do curso in-company. Além dos vídeos o aluno terá acesso aos slides completos usados em nosso curso in-company, ao código fonte dos exercícios desenvolvidos e suporte por e-mail para esclarecimento de dúvidas sobre o conteúdo do curso.
• Livro Python e Django – O primeiro livro publicado em língua portuguesa sobre Django. Voltado para desenvolvedores Web que usam outras linguagens de programação para o trabalho e querem começar a usar Python e Django.

Caso tenham alguma dúvida sobre algum dos nossos cursos podem entrar em contato conosco. Mas, para agilizar, seguem algumas informações interessantes/importantes:

1. A Triveos oferece desconto de 20% nos cursos in-company agendados para o período de 1/janeiro a 30/abril.
2. Oferecemos 50% de desconto em nossos cursos online para associados da Associação Python Brasil que estão em dia com sua anuidade. É só se cadastrar no site da associação e entrar em contato conosco solicitando o código de desconto pra ser usado no momento da compra.
3. O curso, até o momento, fica disponível por tempo indeterminado e pode ser assistido quantas vezes desejar. Pode ser que isso mude no futuro, até lá, aproveite :D
4. Conteúdo integrado: o conteúdo do livro, do curso em video e do curso in-company segue a mesma linha.
5. As pessoas que já adquiriram o curso durante o período de pré-venda ganharão um presente da Triveos. Aguardem o contato em breve (alguns clientes já receberam seus presentes).

A plataforma Ludeos, onde os cursos ficam disponíveis, também é um produto da Triveos. Este produto ainda está na sua primeira versão e, por isso, ele ainda está longe do que consideramos ideal.

Estamos trabalhando numa nova versão do Ludeos onde teremos: certificados, suporte tira-dúvidas integrado na plataforma (usamos e-mail/gtalk hoje), download do conteúdo e suporte para que qualquer um possa criar e vender seus treinamentos. Teremos novidades dentro de alguns meses.

Apesar da plataforma não estar completa já é possível assistir os videos e ter acesso ao conteúdo normalmente, portanto, não se preocupem se a “cara” do site não lhe parecer muito boa porque em breve ela ficará melhor. :D

Ludeos 2.0 (em breve)

You can download/install accessing: http://j.mp/pychrome.