Devolvam as passwords aos vossos utilizadores com Ruby on Rails 2.0
February 12, 2008

Uma coisa que me chateia imenso nas webapplications de trazer por casa – traduzindo aquelas que são feitas por colegas meus ou por outros amadores pela web fora – é o facto de guardarem quase sempre as passwords na base de dados em plaintext. Acho que não tem o direito de saber a password que uso, nem que a use exclusivamente nesse site (como é o caso)
Assim, se quem fez a aplicação for mal intencionado, pode simplesmente obter a vossa password escrevendo
select * from users where user.username = 'nick'
Mas mesmo que não sejam mal intencionados, outra pessoa pode aceder a base de dados. Ou podem simplesmente não se ter protegido contra sql injection. Há um milhão de razões pelas quais nunca se deve guardar as password em plaintext, sendo que a principal deles é o facto da password não ser vossa. É do utilizador. E isso faz toda a diferença! Não acreditam em mim certo? Estou a exagerar.
Convido-os a visitar esta página
- http://www.ufp.pt/events.php?intId=10046
Agora procurem por ‘qualquer_coisa. O resultado é
- Pesquisa por “\’qualquer_coisa”:
Este \’ é importantíssimo pois significa que a página se esta a proteger contra ataques de sql injection. Caso contrario um hacker podia, com alguma sorte, obter informação privilegiada que estava contida nessa base de dados.
Mas ninguém faz um erro destes, certo? Errado. Vamos ao google e procurem php em páginas de Portugal. O sexto resultado, e único que testei, é a associação nacional de farmácias. Se procurarem por ‘qualquer_coisa o resultado é um não tão surpreendente erro. Isto é um exemplo de milhares, alguns dos quais onde vocês inserem as vossa password (e sabe-se lá o que mais) diariamente. Não se sentiam melhor se soubessem que nessa base de dados não está a vossa password?
Mas voltando ao assunto, a táctica que vou usar consiste em usar um algoritmo de one way hash chamado SHA. O utilizador, quando se regista no site, insere a sua password. Esta é processada (num processo que se chama de digest) para uma hash que contém não a password mas sim a encriptação dessa password em SHA. Como SHA é um algoritmo de one-way-hash, é fácil obter a hash única para qualquer palavra mas quase impossível de decifrar no sentido inverso. Para ser suficiente, mas não é.
Comecemos por ir para a consola do rails. Entrem no terminal e naveguem até onde tem a vossa Ruby on Rails web application. Agora escrevam.
./script/console
Quando lá estiverem podem verificar que aplicando este algoritmo a palavra porto obtemos sempre a mesma resposta.
>> password = 'porto' => "porto" >> Digest::SHA256.hexdigest(password) => "01735c5ff1608734e4c38449a00b74bb9a8d5423ed548238da70178e9e803483" >> Digest::SHA256.hexdigest(password) => "01735c5ff1608734e4c38449a00b74bb9a8d5423ed548238da70178e9e803483"
Não sei se repararam mas o nosso utilizador usa uma palavra pass muito fraca. Isto vai fazer a diferença, por o hacker pode obter a password facilmente se tiver a hash.
Como? Sim eu disse que era muito difícil crackar o SHA, alias não conheço ninguém que o tenha feito. Ninguém conhece :P
Mas o hacker pode pegar numa lista de palavras comuns nas passwords e, para cada uma das palavras associar a hash correspondente. Agora se tiver a vossa hash pode comparar com o dicionário que criou descobrir algumas das passwords da base de dados, aquelas que estavam na lista de palavras comuns.
Para resolver este problema usamos um salt. Um salt é também uma palavra (como a vossa password) que sera usada para evitar esta técnica. é mais simples mostrar que explicar, e por isso mesmo:
>> password = 'porto'
salt = [Array.new(6){rand(256).chr}.join].pack("m").chomp
>> salt = [Array.new(6){rand(256).chr}.join].pack("m").chomp
=> "19L6gVcD"
>> salt = [Array.new(6){rand(256).chr}.join].pack("m").chomp
=> "CqEVe632"
>> password = 'porto'
=> "porto"
>> Digest::SHA256.hexdigest(password + salt)
=> "c017e1c49096149097050c76f0406dce9245058e0d..."
De certeza que o hacker não vai procurar pela string portoCqEVe632 e, portanto, os nossos utilizadores estão seguros. Caso queiram saber um pouco mais sobre o que se passa no criação do salt, e que é aquele pack(’m') peçam nos comentários e eu escrevo um artigo sobre isso. Senão nunca mais saio daqui! :P.
Agora surge a pergunta, como usar esta informação em rails. Simples.
Vamos começar por criar um projecto:
rails secureusers && cd secureusers
Agora precisamos de criar o modelo de utilizador
./script/generate model User username:string \ password_hash:string password_salt:string rake db:migrate
Abram o vosso User.rb model, apaguem o que lá tem, e insiram o seguinte código
require 'digest/sha2'
class User < ActiveRecord::Base
# usei o attr_accessible em vez do
# attr_protected :password_hash, :password_salt
# porque é boa prática em Rails usar o enabled para
# os campos acessíveis e não o contrário.
#
# Imaginem que tinham um campo isAdmin e se
# esqueciam de por no protected.
# Ao dizerem que enabled só o :username impedem
# o acesso a todo e qualquer outro campo,
# excepto aqueles que foram explicitamente
# escolhidos por vocês.
attr_accessible :username
attr_accessor :password
def before_save
unless password.blank?
salt = [Array.new(6){rand(256).chr}.join].pack("m").chomp
self.password_salt, self.password_hash = salt,
Digest::SHA256.hexdigest(password + salt)
end
end
def self.authenticate(username, password)
user = User.find :first,
:conditions => ['username = ?', username])
if user.blank?
raise "O utilizador não existe"
elsif Digest::SHA256.hexdigest(password + user.password_salt) != user.password_hash
raise "A autenticação falhou"
else
user
end
end
end
Usei o attr_accessible em vez do protected porque considero esta uma boa practica. Prefiro dizer quais os campos acessíveis que quais os que se deve proteger. Assim não corro o risco de me esquecer de proteger algum campo. E os que são para ver nota-se bem quando faltam :P Podem ler mais sobre isto aqui.
Depois de toda esta explicação o código deve ser muito facil de entender. Até para quem não sabe Ruby. Vamos testar?
>> nuno = User.new => #<user id: nil, username: nil, password_hash: nil, password_salt: nil, created_at: nil, updated_at: nil> >> nuno.username = 'nuno' => "nuno" >> nuno.password = 'porto' => "porto" >> nuno.save => true >> nuno => #</user><user id: 1, username: "nuno", password_hash: "c490ea11d96be24ece2ca0dba11d84fc9b...", password_salt: "V+b7Sqjh", created_at: "2008-02-12 19:28:54", updated_at: "2008-02-12 19:28:54">
E agora autenticar:
User.authenticate 'nuno', 'porto' => #</user><user id: 1, username: "nuno", password_hash: "c490ea11d96be24ece2ca0dba11d84fc9b...", password_salt: "V+b7Sqjh", created_at: "2008-02-12 19:28:54", updated_at: "2008-02-12 19:28:54">
Fixe. É so por no session[:user] ;) Para finalizar aconselho-vos vivamente a suportarem open-id para o processo de autenticação dos utilizadores. Existem plugins muito bons que o fazem, e podem ler mais sobre open-id no seu fantástico guia supersónico.





February 12, 2008 at 9:58 pm
Como RoR é completo chinês para mim neste momento e estou bastante curioso nesse processo de protecção das palavras passes explica lá um bocadinho melhor o que se passa.
February 12, 2008 at 11:16 pm
Nuno,
Tás maluco? acts_as_authenticated faz isso tudo com uma linha de comando.
http://wiki.rubyonrails.org/rails/pages/Acts_as_authenticated
February 12, 2008 at 11:31 pm
Mário,
Isto é para ensinar as pessoas sobre segurança. Usei o rails como ferramenta.
Tenho noção de todos os optimos plugins que existem para fazer isto em RoR.
Isso e outras coisas: acts_as_spinx, acts_as_tree, acts_as_taggable, will_paginate, attachment_fu.
Os plugins do rails são um espectaculo. eu sei. Mas assim as pessoas aprendem. E o conhecimento não tem valor :)
February 12, 2008 at 11:33 pm
Dextro,
A forma como foi escrito este artigo permite, com facilidade, compreender o que cá esta e perceber os fundamentos que ficam por baixo.
Senão, como o mário disse, limitava-me a dizer: acts_as_authenticated
February 13, 2008 at 1:21 am
Nuno,
Ok, certo, mas o artigo ficaria mais perceptível se fosse omitido toda a implementação prática (que não é necessária) e ficasse apenas a explicação.
Depois podias sugerir bibliotecas para várias linguagens que já implementassem o conceito.
Bom trabalho eitherway :-)
February 13, 2008 at 4:39 am
Sabes que mais, a tua pequena introdução sobre SQL injection fez-me testar umas coisas com o meu site e verificar que este estava vulnerável, coisa que confirmei ao hacká-lo de propósito tendo as bd’s em backup.
Na verdade tinha feito algo muito estúpido durante o seu desenvolvimento, algo apenas próprio de um príncipiante no rails, já que aquele era o meu primeiro projecto e este assim sobreviveu durantes estes meses todos.
Enfim, muito obrigado pelo post. :P
February 13, 2008 at 10:05 pm
Bom post, essa questão das passwords em plaintext por vezes não são levadas a sério. E quase que aposto que 70% (ou mais) das pessoas usam a mesma password para tudo, porque é mais fácil e conveniente… e é bastante simples alguém com um site ou forum online conhecido aproveitar-se do registo de utilizadores para obter os seus dados que provavelmente irão dar acesso a outros serviços, começando logo pelo e-mail que fornecem para o registo.
February 19, 2008 at 2:51 am
Esta forma de misturar o salt e a hash é a mais fraca que existe.
Deviam usar um algoritmo qualquer para o fazer. Exemplo MAC com SHA usando o salt como chave. ;)
March 14, 2009 at 9:19 pm
[...] http://nunojob.wordpress.com/2008/02/12/devolvam-as-passwords-aos-vossos-utilizadores-com-ruby-on-ra... [...]