algoritmo de geração de hashes no Django

[tiagoprn]

Olá pessoal!

Estava pesquisando sobre a geração de senhas de usuário (password) no django,
e me deparei com a seguinte informação no StackOverflow (adoro este site):

"O django não encripta, mas sim gera um hash SHA1 de um password.
Desta forma é impossível reverter um password com 100% de certeza.
Como recurso poderíamos utilizar databases online que possuem hashes de palavras comuns
para tentar descobrir a senha, mas com o Django isto não funciona.

Isto porque o Django adiciona um "salt" ao password ANTES de computar o hash.
Desta forma nem os administradores do sistema podem acessar sua conta.
por tanto, se você perder esta conta, seu password terá que ser "resetado",
o que o Django tb permite."

Como o post é de 2009, só queria confirmar algumas dúvidas:

1) Isto vale para as versões 1.0 até 1.3 do Django? (Alguém comentou que versões
antigas usavam MD5 para o Hash, mas não informaram a partir de qual
versão passou a usar SHA1)

2) O "SECRET KEY" que está no "settings.py" dos projetos seria este "salt"?

3) Se eu quiser usar o mesmo método usado para fazer o hash do password
em um outro campo qualquer da base, como faço para gravar e recuperar este valor,
usando a mesma lógica do password? (Ficaria muito grato se alguém pudesse
postar codesnippets para os 2 casos).

Agradeço antecipadamente os esclarecimenos. creio ser algo interessante e
útil, mas não muito comentado por aqui.



--
***
TIAGOPRN (Tiago Paranhos Lima)
Programador Web, Linux e Windows
(Django, Python, Delphi, Lazarus, MySQL, SQLite)
E-mail: tiag...@gmail.com
Website: http://www.tiagoprnl.com
LinkedIn (profile público): http://br.linkedin.com/in/tiagoparanhoslima
twitter: https://twitter.com/tiagoprn

identi.ca: http://identi.ca/tiagoprn

[Rodrigo Pinheiro Matias]

Em 26 de julho de 2011 13:10, tiagoprn <tiag...@gmail.com> escreveu:

Olá pessoal!

Estava pesquisando sobre a geração de senhas de usuário (password) no django,
e me deparei com a seguinte informação no StackOverflow (adoro este site):

"O django não encripta, mas sim gera um hash SHA1 de um password.
Desta forma é impossível reverter um password com 100% de certeza.
Como recurso poderíamos utilizar databases online que possuem hashes de palavras comuns
para tentar descobrir a senha, mas com o Django isto não funciona.

Isto porque o Django adiciona um "salt" ao password ANTES de computar o hash.
Desta forma nem os administradores do sistema podem acessar sua conta.
por tanto, se você perder esta conta, seu password terá que ser "resetado",
o que o Django tb permite."

Como o post é de 2009, só queria confirmar algumas dúvidas:

1) Isto vale para as versões 1.0 até 1.3 do Django? (Alguém comentou que versões
antigas usavam MD5 para o Hash, mas não informaram a partir de qual
versão passou a usar SHA1)

Não tenho muita certeza, mas acredito que desde que comecei a utilizar o django (0.96) acredito que já era SHA1

2) O "SECRET KEY" que está no "settings.py" dos projetos seria este "salt"?

O django trabalha mais ou menos assim, veja o código python

import os
import hashlib

# esta linha gera uma string aleatória para ser utilizada como salt
salt = os.urandom(4).encode('base64').replace('\n', '') #nao sei se ele usa o 4 ou um numero randomico
password = '1234'

print 'Hash password:  ', '%s$%s' % (salt, hashlib.sha1('%s%s').hexdigest())

O salt é gravado junto com a senha e feito hash como parte da senha tb, veja que o salt poderia aparecer em qualquer parte da string que será transformada (feito hash) mas isto tem que ser padrão no sistema inteiro, tanto na hora de criar, como alterar e checar.

3) Se eu quiser usar o mesmo método usado para fazer o hash do password
em um outro campo qualquer da base, como faço para gravar e recuperar este valor,
usando a mesma lógica do password? (Ficaria muito grato se alguém pudesse
postar codesnippets para os 2 casos).

O valor já mais poderá ser recuperado, so poderá ser checado. realizando processo semelhando com a senha passada pelo usuário e utilizando o salt o que esta antes do $ no password
 

Agradeço antecipadamente os esclarecimenos. creio ser algo interessante e
útil, mas não muito comentado por aqui.



--
***
TIAGOPRN (Tiago Paranhos Lima)
Programador Web, Linux e Windows
(Django, Python, Delphi, Lazarus, MySQL, SQLite)
E-mail: tiag...@gmail.com
Website: http://www.tiagoprnl.com
LinkedIn (profile público): http://br.linkedin.com/in/tiagoparanhoslima
twitter: https://twitter.com/tiagoprn

identi.ca: http://identi.ca/tiagoprn

--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>

--
Rodrigo Pinheiro Matias
Bacharel em Ciência da Computação

Celular
+55 (063) 8111.2080

Telefone em horário Comercial
+55 (063) 3216.7564

Blog
http://rodrigomatias.goware.com.br/blog/

Feed
http://rodrigomatias.goware.com.br/blog/feed/

Twitter
http://twitter.com/rodrigopmatias

[tiagoprn]

Rodrigo entendi.

Só tenho mais algumas duvidas:

1) Para que serve a SECRET KEY do settings, então?

2) Como voces fazem para gravar, por exemplo, numeros de cartao de crédito? (se entendi direito um hash nao serviria aqui, pois preciso pegar de volta o numero neste caso). Ficaria grato se alguem tivesse um code snippet ou um algoritmo que permita encriptar/decriptar, se possivel algo já dentro do próprio django.

3) Não sei para que ela serve, mas não é um furo de segurança ter a SECRET_KEY no proprio settings?

Obrigado.

***
***

Matias<rodrigo...@gmail.com> escreveu:

>> identi.ca <http://identi.ca>: http://identi.ca/tiagoprn

>>
>>
>>
>>
>> --
>> Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
>> Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
>
>
> --
> Rodrigo Pinheiro Matias
> Bacharel em Ciência da Computação
>
> Celular
> +55 (063) 8111.2080
>
> Telefone em horário Comercial
> +55 (063) 3216.7564
>
> Blog
> http://rodrigomatias.goware.com.br/blog/
>
> Feed
> http://rodrigomatias.goware.com.br/blog/feed/
>
> Twitter
> http://twitter.com/rodrigopmatias
>
> --
> Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>

> Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>dito?

>> identi.ca <http://identi.ca>: http://identi.ca/tiagoprn

[Ricardo L. Dani]

Qual a finalidade de se gravar número de cartão de crédito no banco ?!

2011/7/26 tiagoprn <tiag...@gmail.com>:

--
Ricardo Lapa Dani

[Ricardo L. Dani]

Se a SECRET_KEY está no settings, porque isso seria uma falha de
segurança?! Sendo que apenas o programador tem acesso ao settings?

2011/7/26 tiagoprn <tiag...@gmail.com>:

--
Ricardo Lapa Dani

[Elyézer Mendes Rezende]

Não sei se seria o caso, mas poderia ser para pagamentos recorrentes
ou mesmo para agilizar o processo de pagamento.

Achei interessante a discussão de como tratar a segurança de dados
importantes no BD.

Eu penso em criptografar e descriptografar, porém não conheço e nem
nunca usei algo nesse sentido.

Alguém que tem alguma experiencia poderia compartilhar?

Até mais

2011/7/27 Ricardo L. Dani <ricar...@gmail.com>:

--
Elyézer Mendes Rezende
http://elyezer.com

[Bruno Ribeiro da Silva]

A meu ver, guardar número de cartão de crédito em banco de dados é uma responsabilidade muito grande, só se deve fazer se puder garantir a segurança de toda a infraestrutura dos servidores onde a aplicação roda, não adianta você cifrar o número de cartão em banco de dados se a sua aplicação também está sujeira a vulnerabilidades, uma vez que o atacante tem acesso ao servidor de aplicação ele tem acesso aos mesmos dados que sua aplicação tem, e por ai vai.

[tiagoprn]

Opa!

1) Então, a questão do cartão de crédito foi apenas para dar um exemplo, eu nem estou usando acesso a cartões na minha aplicação. Vou refazer a pergunta: como faço para criptografar/descriptografar algum campo que eu queira guardar encriptado na base? O Django possui algo já pronto neste sentido qu eu possa usar?

2) E quanto à SECRET_KEY no settings.py ser um furo de segurança, não é apenas o programador que tem acesso a este arquivo não. Posso estar sendo paranóico, mas se eu tiver meu projeto django em uma hospedagem compartilhada os funcionários desta hospedagem teriam acesso ao filesystem da minha conta, correto?

É isso, levantei estas dúvidas porque acredito que a segurança deve ser pensada ao se desenvolver em Django.

Mas gostaria de continuar esta discussão, até para que fique arquivado aqui na lista para referência futura.

[Ricardo L. Dani]

2) Se os funcionários do acesso compartilhado tem acesso ao
settings.py o SECRET_KEY é o de menos, pois alí há dados de acesso do
banco de dados também... acredito que as permissões de acesso de uma
account compartilhada é do tipo rwxr----- . ou seja, o owner tem
acesso completo, o grupo tem acesso leitura e os outros nao tem nenhum
tipo de acesso, estou certo ?!

2011/7/27 tiagoprn <tiag...@gmail.com>:

--
Ricardo Lapa Dani

[Bruno Gola]

2011/7/27 tiagoprn <tiag...@gmail.com>:

> Opa!
>
> 1) Então, a questão do cartão de crédito foi apenas para dar um exemplo, eu
> nem estou usando acesso a cartões na minha aplicação. Vou refazer a
> pergunta: como faço para criptografar/descriptografar algum campo que eu
> queira guardar encriptado na base? O Django possui algo já pronto neste
> sentido qu eu possa usar?

Respondendo à pergunta original, procure por Python+M2Crypto+Django

:-)

[]'s,
--
Bruno Fialho Marques Gola <brun...@gmail.com>
http://www.brunogola.com.br
Cel: (11) 9294-5883

[Bruno Gola]

2011/7/27 tiagoprn <tiag...@gmail.com>:

> 2) E quanto à SECRET_KEY no settings.py ser um furo de segurança, não é
> apenas o programador que tem acesso a este arquivo não. Posso estar sendo
> paranóico, mas se eu tiver meu projeto django em uma hospedagem
> compartilhada os funcionários desta hospedagem teriam acesso ao filesystem
> da minha conta, correto?

http://www.reddit.com/r/django/comments/d35hy/what_happens_if_your_secret_key_is_found_out/

:-)

[Bruno Ribeiro da Silva]

O correto é somente o owner do arquivo ter permissões de leitura e escrita, não é necessário mais permissões do que essas para rodar uma aplicação em django. É claro que a empresa responsável pelo hosting tem acesso aos seus dados, e se a sua aplicação vai acessar esses dados, sejam eles criptografados ou não, ainda assim a empresa de hosting tem acesso à sua aplicação, logo eles também tem acesso à esses dados criptografados!

Uma maneira que vejo de tornar isso bem difícil pro pessoal do hosting não ter acesso é você usar a senha do usuário como chave simétrica para cifrar os dados daquele usuário no bd e só decifrar em tempo de execução já que você vai ter a senha que o usuário digitou. Essa solução ainda tem umas implicações e ainda é sucetível à ataques, mas já torna um pouco mais difícil.

[Moreno Cunha]

Acabei de assistir o vídeo sobre Playdoh da Mozilla [1] postado aqui na lista e há uma sugestão para melhoria da segurança no Django. SHA2 [2]

Ainda não testei, mas me parece uma evolução do SHA1.

[1] https://blog.mozilla.com/webdev/2011/07/26/scaling-django-to-a-global-audience-with-playdoh/

[2] https://github.com/fwenzel/django-sha2

Talvez ajude,

Moreno Pinheiro
Developer

contato={ 

          'Blog' : 'EasyDjango',

          'Twitter' : '@morenocunha',

          'Skype' : 'moreno.pinheiro',

          'tel' :  '+55 27 9834-6305'