Re: [Treebase-devel] harvesting

[Rutger V. <rut...@gm...>]

>
> That sounds about right. I'd strongly recommend SHA1 in favor of MD5
> (computationally harder for brute-force rainbow tables, and programming
> support should be equal to MD5), the comparison to a retyped password could
> also be done entirely client-side (JavaScript), and the password reset
> function could initially be written to reset the password to a randomly
> generated one, which could then be emailed to the user, if changing to a
> token-based system for reset is more effort than we can or want to afford
> for now. (A randomly generated password being sent over email is still
> hugely better than storing passwords in clear text in the database.)
>

Yes that's probably easier to do initially. I had no idea we were under
attack by brute-force rainbow tables.


> BTW you didn't cc the list - intention? If not, feel free to forward this
> one back to the list.
>

Ah, thanks for catching - I was trying out gmail offline for chrome and I'm
not crazy about it.

More below:

On Feb 2, 2012, at 12:59 PM, Rutger Vos wrote:

>
> So based on the above I'm still hoping this could be done in a way that
>> isn't a major thing, or equivalent to redoing the authentication system.
>>
>> Either way, I agree it's worthwhile to consider whether we can use the
>> emergency funds for this. One difficulty here is obviously how we'd do this
>> without adding Yale's 60% overhead rate - perhaps we can hire Harry on an
>> outside contractor basis for this task if he does work on the side? Could
>> you or Harry give me an estimate of effort in number of hours?
>>
>
> So what are the steps involved in this? I think what needs to happen is:
>
> * encrypt the passwords in the database (SHA? MD5?)
> * make sure the passwords that users enter, either when logging in,
> creating an account or updating their password, are encrypted in the same
> way as early as possible
>
> I looked at User.getPassword() and User.setPassword() and there's only a
> couple of points in the call hierarchy that interact with those methods
> (AbstractUserController, PasswordFormController and
> RegisterUserController). The behavior at those points would need to be
> altered. In particular:
>
> * AbstractUserController can't simply compare the HTTP parameter
> "retypedpassword" with what's in the database: the "retypedpassword" needs
> to be encrypted first.
> * PasswordFormController can no longer echo the password back in plain
> text. This controller can only provide password change functionality since
> the plain text password is no longer available anywhere.
>
> Or as Hilmar suggests: email a randomly generated password that is only
stored in encrypted form and that the user most then change.

> * RegisterUserController needs to behave such that when it calls
> UserService.createUser() the user object has its password already
> encrypted. This won't require the controller to change though: it's
> probably better if setPassword() encrypts its argument before assigning it
> to a local field.
>
> All in all this doesn't seem like that much work, but it needs to be
> coordinated carefully. Especially when we pull the trigger on encrypting
> the passwords in the database and committing the code that handles them.
>
> Rutger
>
>
> --
> Dr. Rutger A. Vos
> Bioinformaticist
> NCB Naturalis
> Visiting address: Einsteinweg 2, 2333 CC, Leiden, the Netherlands
> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
> http://rutgervos.blogspot.com
>
>
> --
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>


-- 
Dr. Rutger A. Vos
Bioinformaticist
NCB Naturalis
Visiting address: Einsteinweg 2, 2333 CC, Leiden, the Netherlands
Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands
http://rutgervos.blogspot.com