verificacao se o browser que se esta a ligar e o mesmo a cada pedido. Sabendo o cookie de sessao de um utilizador, se eu me ligar a um website usando o cookie de sessao desse utilizador, posso-me fazer passar por ele caso nao haja qualquer tipo de verificacao ao browser utilizado. Para diminuir a probabilidade de roubo de sessoes (sim, porque nao deixa de possivel), aconselha-se a verificacao do browser recorrendo a, por exemplo, o User-Agent, a ordem de envio dos headers, o conteudo do header HTTP-Accept, entre outros, e caso a verificacao falhe, destruir a sessao, dar-lhe uma nova, e obrigar o utilizador a fazer login novamente.Criptografia segura vs criptografia inseguraO uso de criptografia segura pode fazer toda a diferenca entre uma catastrofe e uma saida ilesa de um servidor de uma invasao. Quando todas as medidas de precaucao que usamos ja falharam e estamos condenados, temos uma ultima arma contra a quebra da privacidade dos nossos utilizadores: o uso de criptografia segura. Quando falo de criptografia segura, refiro-me a algoritmos considerados seguros para o armazenamento de dados sensiveis, como os algoritmos SHA-256 e AES por exemplo, em detrimento de criptografia insegura, como os algoritmos MD4, MD5, SHA-1, entre outros. Um dos grandes problemas dos algoritmos de hashing e, sem duvida alguma, a possibilidade de clashing, ou seja, existir outra combinacao de caracteres que nao a original que tenha o mesmo hash.Imaginemos uma palavra-passe Portugal-a-Programar. O hash MD5 desta password e e8ca8f20b74e7e64a11160b7002f943d. No entanto, poderao haver outras palavras-passe que dao este hash de 32 caracteres. Mas, usando um algoritmo de hashing que produza um hash maior (como SHA-256, que produz hashes com 64 caracteres, ou o SHA-512, que produz hashes com 128 caracteres), as possibilidades de clashing sao muito mais reduzidas. Quando as possibilidades de clashing sao menores, um cracker ira necessitar de fazer ataques de dicionario (usando rainbow tables) mais complexos e demorados, uma vez que ira necessitar de uma lista de hashes maior.Outra medida que muitas pessoas defendem, e o uso de sal em palavras-passe, de modo a dificultar muito, se nao tornar impraticaveis, os ataques de dicionario. Este truque do sal consiste em adicionar caracteres a palavra-passe antes de a passar pela funcao de hashing. Imaginemos a palavra-passe amor. Como e extremamente provavel que o hash desta palavra-passe esteja presente em rainbow tables, vamos adicionar-lhe sal, de modo a que passe pala funcao de hashing a password amortty, que e extremamente improvavel que esteja numa rainbow table. Neste caso, o sal que adicionamos foi o tty, que vai ter de ser guardado em algum sitio, sitio esse que ir? estar certamente ao alcance de um cracker durante uma invasao. No entanto, mesmo que o cracker saiba o sal? que adicionamos as palavras-passe, ira necessitar de criar novos dicionarios com aquele sal, um processo demasiado moroso para alguns e que nos fazem ganhar tempo ate que os dados dos utilizadores sejam expostos. Depois da invasao, mudamos o sal das palavras-passe, pedindo aos utilizadores para escolherem uma nova palavra-passe.Falhas no handling de erros e fuga de informacaoOs erros durante