I had the same problem as you, I think. We wrote a cutomize login
method ,attached, to
check if the entered password was the same that was stored in the database, we
use the
http://packages.python.org/passlib/lib/passlib.hash.sha512_crypt.html.
If you wish you could write a new validator to encrypt using the library
cited.
João Henrique Gulineli Fachini;
Eng° Mecânico;
Ilha Solteira - SP;
Cel: (18) 8809 1391
tel LABSIN: (18) 3743 1000 ramal 1343
2011/9/21 pbreit <[email protected]>
> It might not be a bad idea to improve password handling at this time. I
> think the biggest problem is that password hases are not currently salted.
> The hmac_hash function appears to take a salt but I didn't see any evidence
> that is ever actually used.
>
> The Django model seems sufficient:
> https://docs.djangoproject.com/en/dev/topics/auth/#passwords
>
> I think this is the code:
> https://github.com/django/django/blob/master/django/contrib/auth/utils.py
>
> Passwords would be stored like this:
> sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
> (ie, algo$salt$hash)
>
> The hash algo is stored with the password. This makes it easier to switch
> algos in the future. The salt is also stored with the password which many
> people mistakenly think is unsecure. Also note that the salt is just a
> simple random string and does not have to be particularly long to be
> effective.
>
> If we did implement this approach, the next question is, could we also
> implement a scheme whereby if the algo is changed, when someone goes to
> change their password, the system can confirm that the old password is
> provided correctly and then store the new password under the new scheme?
>
# coding: utf8
from gluon import *
from passlib.apps import custom_app_context as pwd_context
def sha_512(db):
def aux_sha_512(email,password):
user = db(db.auth_user.email==email).select().first()
if user:
return pwd_context.verify(password, user.password)
return aux_sha_512
