Re: [Treebase-devel] harvesting

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

>
> 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?
>

As far as I can see the changes would be relatively minor, though they are
scary because if we F this up it locks everyone out of their accounts. I
think we would need to make the following changes in principle:

* encrypt all the passwords in the database (SHA?)
* make it so that any password strings that enter into the code base are
encrypted at the earliest point

I searched in eclipse where in the call hierarchy the methods
User.getPassword() and User.setPassword() are interacted with, and it's
mercifully limited:

1. in RegisterUserController.onSubmit() when we create the user, this
user's password should already be encrypted. Right now, we simply coerce
the command Object into a User (line 42), which means that the password is
treated as an ordinary object property which we obtain out of the session
variables. Here we would have to do the encryption and pass that into
User.setPassword() - we can't do the encryption inside the body of
setPassword() because that would mean the encryption is done twice when
User objects are created out of the database (where the passwords are
already encrypted) rather than out of session variables.

2. in AbstractUserController.checkPasswords() we compare User.getPassword()
with the HTTP parameter "retypedpassword". Here getPassword() should return
the encrypted string, and the HTTP parameter should be encrypted for
comparison.

3. in PasswordFormController.onSubmit() we send a reminder email with the
password in plain text back to the user. We can't do that because we won't
have the unencrypted password anywhere in the system. Instead we should
send a password change email.

If we first do only 1. and then ask for the reminder email we can check to
see if a new dummy user is successfully created with an encrypted password.
We then do the encryption of all other passwords in the database and 2.
change checkPasswords() to compare with an encrypted "retypedpassword". At
this point the reminder email is no longer useful, because it will return
an encrypted string that will be encrypted again before the comparison is
done, so then we have to 3. change the reminder email to a password change
email. That's a bit tricky because we would have to send a special link
that sets the user to "authenticated" on our end so we can send them to the
updateProfile page, but it's functionality that's more or less separate
from everything else so we can start thinking about how to do that, perhaps
in parallel.

Anyway, all in all this should be doable, but I'm worried about missing
something. What do you guys think?

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