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 the salt in 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 <[email protected]>
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 the salt. Anyway, let me know if you have a suggestion.
>
> Massimo
>
> On Sep 20, 9:25 pm, Dave <[email protected]> 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 a per-user salt stored in the database. The salt
> > 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 password salt instead of application-wide salt. 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?
