Veja o curso em http://www.udemy.com/beginners-guide-to-postgresql/

Se considerar-mos os hábitos de utilizadores, nomeadamente a reutilização frequente de palavras passe, a descoberta de uma palavra passe num local poderá facilitar o acesso a dados do utilizador noutros locais e sistemas. Agentes maliciosos utilizam ataques para obter este tipo de informação devido ao seu valor. Ainda recentemente houve o ataque ao Linkedin, e a publicação da informação de passwords dos utilizadores. É portanto necessário tomar medidas, não só para preservar a segurança dos dados, mas garantir que o acesso a elas não crie novas vulnerabilidades.

Em circunstância alguma devemos armazenar a palavra passe do utilizador na base de dados num formato legível! Se considerar-mos o funcionamento de websites e aplicações, as únicas situações que necessitaria-mos de ter a password original do utilizador numa aplicação seria para reutiliza-la na autenticação a um serviço externo, caso utilizássemos o serviço em representação do utilizador. Mas o risco associado não justifica a prática – a troca de outro tipo de chaves de autenticação é mais seguro para o utilizador. Um exemplo são as autorizações em aplicações de sites como o Facebook: a passe do utilizador não é transmitida, apenas uma chave complexa que autoriza o acesso pela aplicação.

Técnicas para ofuscar a password

Mas e a autenticação no próprio site?! A autenticação no site é efectuado através da comparação da password do utilizador, inserido no formulário de autenticação, e a password armazenada. Recorrendo a um exemplo simples, para ver o funcionamento, imagina que o nosso user José Silva utiliza uma password simples e comum “qwerty”. No formulário ele introduz o username e password, e quando clica para fazer o login, procuramos o registo dele na base e comparamos as passes. Se coincidirem:

if(formData["password"] == dbData["password"]){ ...

o utilizador passa a ter acesso ao site/aplicação. No (semi-pseudo)código, o formData representa os dados vindos do formulário e o dbData os dados provenientes da base de dados.

O erro que alguns programadores inconscientes destes problemas têm é não compreenderem que esta comparação não tem de ser efectuada com as versões originais da passe. Na verdade, podemos e devemos usar a versão codificada da passe, conhecida por “hash” (ou escrutínio, mas a palavra em inglês é bem mais agradável). Ou seja, a partir do momento que o utilizador regista a sua conta, o que deve ser armazenado é uma versão codificada da passe, e utilizando o um algoritmo que permita apenas a codificação num sentido (impedido recuperar o original por processamento inverso). Se recorrermos a um algoritmo como o MD5 ou o SHA-1 a password fica armazenado num formato críptico e bem mais difícil de descodificar. (Nota: o SHA-1 e MD5 hoje em dia não são suficientemente seguros, já que com a capacidade de processamento disponível, a descodificação por ataques de dicionário ou força bruta são viáveis).

Vejam a mesma passe em ambos os formatos:

MD5: "qwerty" => d8578edf8458ce06fbc5bb76a58c5ca4
SHA-1: "qwerty" => b1b3773a05c0ed0176787a4f1574ff0075f7521e


A comparação no método de autenticação passa então a ser entre versões codificadas da mesma palavra, em vez da versão original da palavra:

if(MD5.codificar(formData["password"]) == dbData["password"]){ ...

Apesar de ser muito melhor, e mais seguro que o armazenamento em texto livre da password, não é suficientemente seguro. Existem tabelas com as palavras codificadas pré-calculadas (lookup tables e rainbow tables) que permitem comparação para obter os valores originais, e mesmo a capacidade de processamento actual do hardware disponível permite efectuar o cálculo por força bruta (este a todas as combinações possíveis) em tempo útil.

Um pouco de sal

Uma técnica importante para contrariar o uso de tabelas de lookup consiste em adicionar um pouco de texto adicional à palavra passe, conhecido por um “salt” (daí o trocadilho do sal insonso…enfim…). O facto de acrescentar mais caracteres no inicio e/ou no fim tornará a palavra a codificar mais complexa e comprida, tornando a sua descodificação também mais complexa.

Voltando ao exemplo, imagina que acrescentamos o texto “p@$$wordComSal” no início da password do utilizador, antes de a codificar. Teriamos então:


MD5: "p@$$wordComSalqwerty" => cd17413e25e513690f7c53fbab394e25


O facto de acrescentarmos um termo incomum no inicio da password do utilizador faz com que o uso de dicionários fique inutilizado, uma vez que o dicionário (e as hashes associadas) não terão o salt em consideração. A base de dados terá armazenado a passe codificada com o salt, e a comparação a efectuar será do tipo:

if(MD5.codificar(salt + formData["password"]) == dbData["password"]){ ...

Ainda estou a considerar um salt fixo e geral para o sistema. E mais uma vez, apesar de ser mais seguro que as anteriores, ainda não é o suficiente. Se o salt é descoberto, ataques de dicionário e força bruta passam a ser novamente possíveis, necessitando apenas de recalcular as hashes com o salt.

Aleatoriedade

A melhoria neste processo é possível garantindo que o salt para cada user seja distinto e, preferencialmente, aleatório. Se cada passe tem um salt diferente, a descoberta de um (por força bruta) impossibilita a criação de tabelas de lookup gerais – apenas serviriam para o registo em que foi descoberto. Além disso, as hashes devem ser geradas usando algoritmos mais seguros (SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3) e a criação deverá ser lenta, recorrendo a estratégias de key-streching ( PBKDF2, bcrypt, and scrypt).

A crackstation tem um excelente artigo sobre o tema.

Recomendo a escolha do bloco adequado de código e a integração em frameworks pessoais core para que possa ser usado facilmente.A validação da passe continua com o mesmo processo (apenas escrito de forma adequada às classes fornecidas) :

if(PasswordHash.ValidatePassword(formData["password], dbData["password"])){ ...

O campo de password do utilizador na base de dados passa a ter uma concatenação do número de iterações PBKDF2, o salt, e a hash gerada, separados pelo caracter “:”. O método validate separa as componentes armazenado, aplica a salt à passe submetida (o salt é especifico do utilizador) e compara a hash gerada com a armazenada. O cálculo é demorado (centenas de milissegundos) tornando ataques de força bruta pouco úteis.

É naturalmente importante não esquecer que esta não é a única técnica, e outros métodos devem ser empregues na construção do site / aplicação para anular todos os “buracos” existentes, reduzindo ao máximo e sempre que possível as falhas de segurança.

O curso está em inglês, e espero que venha a ser bastante útil a muita gente de modo a entrar no mundo desta excelente base de dados.

http://www.udemy.com/beginners-guide-to-postgresql/

I just finished publishing a new beginner’s course on PostgreSQL at Udemy, an online platform for learning. The course has 3 modules – an introduction to relational databases, data structures and manipulation finally SQL. Currently, the course has 18 vídeo lessons and the missing ones are currently in production.

The course is in english, and I hope it becomes very usefull to anyone wanting to enter the world of this amazing database system.

http://www.infoq.com/presentations/I-Learned-from-Failure

Dia 2 de Abril vou ter o prazer de participar como orador na “Conferência – Ser Freelancer em Portugal”, no IPJ de Aveiro. vai ser certamente um dia muito interessante em que vamos reunir freelancers de diversas áreas, especialmente quem está a começar, para falar dos vários aspectos inerentes ao trabalho como freelancer.

Vou estar na conferência a representar área da programação web e desenvolvimento de software. Tem piada que vem numa altura em que preparo-me para dar o salto do freelancing para a estrutura de empresa. De qualquer forma, não deixarei de partilhar os diversos aspectos da minha experiência como tal. Há sempre muito para dizer, e muitas questões a responder. Até lá, tenho que recuperar a voz!

Espero ver muito pessoal por lá. Se houver tópicos que alguem gostaria que abordasse em especial, deixa um comment!

Mais info em http://freelancerportugal.com/

Este é um erro que aparenta aparecer em algumas instalações PostgreSQL em Windows, em especial depois de existir algum update do OS. Uma instalação minha teve este problema, com o erro a ser registado periodicamente nos logs do PostgreSQL. Infelizmente o erro é problemático para aplicações dependentes da base de dados, uma vez que ele interrompe conecções entre a aplicação e a base de dados. É causador de um tipico erro de .NET com mensagem pouco esclarecedora:

[SocketException (0x2746): An existing connection was forcibly closed by the remote host]
System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) +232

Poderia ser de uma coneção externa, mas o pilha de chamadas tinha claramente a biblioteca NpgSQL – o provider PostgreSQL para .NET na lista. Não era uma conecção entre cliente e servidor, mas sim entre a aplicação e o serviço de base de dados (que é efectuado sobre TCP, mesmo estando na mesma máquina).

A solução é a actualização da instalação do serviço de base de dados – este caso passei do 8.4.0 para o 8.4.6. (a correcção deve ter sido introduzido no 8.4.1). Esta versão terá o patch para a correcção deste erro. A actualização é simples: para o serviço e correr o instalador mantendo os dados e configurações intactas (poderá ser necessário recolocar o serviço a arrancar pelo sistema utilizador LOCAL SYSTEM, se necessário).

Info sobre o erro ou patch:
http://blog.hagander.net/index.php?url=archives/149-Help-us-test-a-patch-for-the-Win32-shared-memory-issue.html#feedback
http://www.postgresql.org/docs/8.4/static/release-8-4-1.html

O meu servidor é relativamente simples e construído às necessidades. É um setup simples com dois discos de ITB em RAID 1 para sistema e repositórios de ficheiros importantes, e mais 3 discos de 640GB para “tralha”. Decidi fazer um upgrade, e acrescentar algum espaço – Ia juntar um disco de 640GB que estava na prateleira parada com uma das existentes num RAID 1 dedicado a backups, e acrescentar um disco de 1TB para mais tralha. Assim, ficaria com um total de 7 discos, representando cerca de 3TB de espaço, estando metade montado em RAID1. Uma unidade separada e dedicada a backups parece-me uma boa aposta, e quero implementar uma forma mais automatizada de os fazer, quer do servidor, da minha máquina e a dos meus colaboradores.

Portanto abri e limpei algum (pouco, felizmente) pó do servidor, e reorganizei a barra de discos que agora ficou completamente cheia. Introduzi o disco antigo que esteve parado (e que ainda tinha uma instalação de OS anterior do servidor, como backup), arranquei a máquina, criei um novo RAID e… O servidor entrou no OS antigo em vez da instalação actual. Arrancou pelo segundo disco em vez do primeiro. E assim o caos começou.

Obviamente não era isso que eu queria. Queria o arranque pelo mesmo OS que deveria estar intacto no DISCO 0. Infelizmente esta troca alterou o esquema de letras de unidades e o sector de arranque do disco principal., Não compreendi porque, infelizmente, mas tornou-se impossível arrancar pela partição de sistema do disco original, mesmo sendo a única unidade fisicamente ligada. Algo… assustador!

Para corrigir tive que arranjar algum método de corrigir, que não envolvê-se reinstalar. Felizmente encontrei alguns comandos que se podem executar para reconstruir o o sector e informação de arranque que passo a explicar. Há “ordem”, de certa forma, nos passos a executar q passo a descrever. Este foi o meu caso e raciocínio, mas obviamente pode mudar caso a caso.

O primeiro passo é introduzir e arrancar o servidor com o disco de instalação do Windows Server 2008. Ele tem ferramentas de recuperação, que podem ser executadas a partir da linha de comandos. Depois de arrancar, deve escolher a opção de reparação. Surge uma janela de escolha de unidade de sistema a recuperar. Infelizmente no meu caso, pelo menos inicialmente, não reconhecia nenhuma partição com uma instalação de sistema. De qualquer forma, escolhendo “NEXT” permite chegar às opções seguintes e nas opções de ferramentas, escolhi a linha de comandos para abrir uma consola. Foi interessante verificar que, mesmo n conseguindo arrancar pelo OS, na consola, o windows ainda reconhecia a estrutura de partições e unidades presente no disco. Escolhendo a unidade C do sistema (>c:) executei o seguinte comando:

bootrec.exe /fixmbr

O comando repara o Master boot record. Em muitas situações este comando ou a combinação com o seguinte:

bootrec.exe /fixboot

Deveria ser suficiente para reparar o arranque. Infelizmente no meu caso não o foi, pois o /fixboot respondeu com a mensagem de erro “Element Not Found”. Este erro significa, essencialmente, que a partição de sistema não está “activa”, e portanto deve ser activado, para o recuperador o encontrar. para tal, uso o DISKPART:


>diskpart
DISKPART>list disk
...
DISKPART>select disk 0
...
DISKPART>list partition
...
DISKPART>select partition 1
...
DISKPART>active
DISKPART exit


Esta sequência demonstra alguns comandos do diskpart. os “list” listam os discos ou partições disponíveis no disco seleccionado. O “select” permite seleccionar e disco e partição desejada. “Active” activa a selecção. Depois de executar estes comandos, e com a partição activa, o bootrec.exe /fixboot executa correctamente e pode ser executado ainda o comando

bootrec.exe /rebuildbcd

Se tudo correr bem, deverá ser suficiente. Infelizmente, no meu caso, não o foi. Isto porque, no arranque, sugiu nova mensagem de erro, mas desta vez a indicar que o BOOTMGR estava em falta : “BOOTMGR IS MISSING”. Mais uma volta… desta vez foi suficiente executar o reparador de arranque no CD de instalação. Infelizmente, e ao contrario do Vista, esta opção não aparece na lista de ferramentas. Para aceder é necessário entrar na consola de comandos e executar:

X:\sources\recovery\StartRep.exe

Este foi o toque final necessário para ficar tudo OK. Pude finalmente concluir e ligar os restantes discos sem problemas dentro do servidor.

Refs:
http://www.lancelhoff.com/how-to-fix-vista-mbr-repair-broken-vista/
http://www.pcstats.com/articleview.cfm?articleid=2264&page=8
http://www.networksteve.com/forum/topic.php/VPN_created_using_modem_-_unable_to_modify/?TopicId=9937&Posts=2

Foi lançado ontem à noite um novo vídeo do pessoal da Gov Som. Sociedade Violenta de Yaksha, com a participação de Governo Sombra foi filmado pela equipa de “La Casa Nostra”, e como habitual, participei com com assistência e iluminação. Acho que os planos com o bebé, em termos de luz, correram especialmente bem. Enjoy!

A faixa também está disponível para download em http://www.yousendit.com/download/WTNLRGx3T00zMW14dnc9PQ. Dia 23 sai o álbum, que, pelo que ouvi, está fortíssimo!

http://wiki.postgresql.org/wiki/What’s_new_in_PostgreSQL_9.0

Mais:
http://www.postgresql.org/about/press/presskit90
http://www.postgresql.org/docs/9.0/static/release-9-0

Download:
http://www.postgresql.org/download/

No blog do Scott Guthrie, ele refere como funciona a vulnerabilidade e como prevenir. Essencialmente, é necessário reeditar os ficheiros web.config, e configurar de modo a ter os “custom errors” activos. Ele recomenda ainda ter apenas uma página de erro, e injectar algum código no Page_load dessa página:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>









        An error occurred while processing your request.
    

O detalhe completo em: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx