That may be an even better way to accomplish this task. I actually
considered using some sort of self-reference first, but didn't find it
there.
On Sep 28, 9:00 pm, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:
> I was thinking about this... how about editing the validate function
> in dal.py and allow it to pass the current record to the validators?
> We cannot change the APIs but a validator is an object so we can just
> pass the current record by attaching it as an attribute to the
> validator object. CRYPT could check if the current record exists and
> use it to extract the salt. In this case you woud change only the
> validate function in dal.py and CRYPT.
>
> On Sep 28, 6:39 pm, Dave <dave.st...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I've made this work. I still need a little bit of time to make it
> > backward compatible with non-salted passwords though.
>
> > First things first, I had to disable the CRYPT validator. Although it
> > makes handling passwords easier, encrypting them at the validator
> > level really limits a lot of account enforcement options.
>
> > Next I created an extra utility library with two methods:
> > crypt(password='', algorithm='sha256', salt='') and
> > check_password(plain_password='', encrypted_password=''). The crypt
> > function is pretty simple. It returns a hexdigest given a specified
> > algorithm, string and salt. If no salt is specified, a 16 character
> > salt is randomly generated.
>
> > Finally I had to do some tweaking in the Auth class. First I changed
> > the login method to check the password with my check_password instead
> > of a simple string compare. Next I had to add a "onvalidate" method
> > to the 'register' and 'change_password' methods to encrypt the
> > password. The change_password was actually a little more involved
> > because I had to customize the old_password validator to use my
> > check_password method.
>
> > I'm not quite ready to share the diff files because I want to re-work
> > it so that it's reverse compatible with auth_user data created with
> > the default settings.
>
> > On Sep 21, 1:05 pm, Dave <dave.st...@gmail.com> wrote:
>
> > > Well clearly I've sparked plenty of discussion. I am working on this
> > > to fit my app need. Once I have a working model that doesn't break
> > > other applications that use the default hashing and CRYPT functions
> > > I'll post my work. As others have commented, the typical way for
> > > storing the password would be {algorithm}$salt$hash. I have no
> > > problem with that. The previous developer of the app I am working on
> > > just chose to store thesaltin a separate field in the table. It's
> > > fairly trivial for me to convert the 1500 or so user password strings.
>
> > > Stay tuned and I'll post something later this week or next.
>
> > > On Sep 20, 11:36 pm, Massimo Di Pierro <massimo.dipie...@gmail.com>
> > > wrote:
>
> > > > This will be useful put presents a technical difficulty because of the
> > > > way CRYPT works. CRYPT is the validator that check is a password is
> > > > valid, and it does not know what is stored in db therefore it does not
> > > > know thesalt. Anyway, let me know if you have a suggestion.
>
> > > > Massimo
>
> > > > On Sep 20, 9:25 pm, Dave <dave.st...@gmail.com> wrote:
>
> > > > > I have just started using web2py but already, I'm quite impressed. In
> > > > > the past couple days I've already rolled out an entire site rewrite
> > > > > and I'm working on my second project.
>
> > > > > The project I'm working on right now is currently in PHP. I was in
> > > > > the process of converting it to a Java / Spring MVC project when I
> > > > > discovered web2py and decided that'd be a much easier, simpler and
> > > > > quicker way to roll the app.
>
> > > > > So, let me get to my point.. The current application utilizes the php
> > > > > sha1() function with aper-usersaltstored in the database. Thesalt
> > > > > is randomly generated each time the password is changed. This is
> > > > > similar to the default configuration on most linux boxes.
>
> > > > > I need to make some changes to the Auth class to support the per-
> > > > > record passwordsaltinstead of application-widesalt. Does it make
> > > > > sense for me to provide my edits as part of the project, in case
> > > > > someone else thinks the functionality is useful? I plan on basically
> > > > > checking to see if there is a 'salt' field in the user auth table, and
> > > > > if so, append that to the plain text password before passing it to the
> > > > > appropriate hashlib function.
>
> > > > > Thoughts?
