Thanks for the reply!
Sounds like things just evolved this way :)
Like I said, I don't think there is a vulnerability, I was just curious
about why it worked this way.
BTW - I was just thinking it might be best not to use mysql to do
hashing/encryption - the password may be being sent in plaintext over
the network (I think you can set mysql to use SSL though).
Cheers,
Adrian.
On 05/06/2013 13:31, Samuele Kaplun wrote:
Dear Adrian,
On Wednesday 05 June 2013 11:01:13 Adrian Mouat wrote:
I was just wondering why you you are using AES_ENCRYPT for storing
"passwords" in Invenio. (I say "passwords" as I realise you are actually
storing the e-mail address encrypted with the password).
exactly, which in the ends means we are actually storing nothing more than the
email address.
I'm not an expert on security, but the issue with AES_ENCRYPT is that it
can be *decrypted*(1) whereas a one way hash (e.g. SHA) can't. Also, why
don't you store and encrypt a random number per user rather than use the
e-mail address? This would be *slightly* more secure(2) and avoid the
problem where users must reset their passwords.
I guess, originally the idea was to find a good compromise between security
and database upgrade (basically reciclying the already existing email address
column in the db as a sort of random string.
To introduce a a new column to store the random number at that time seemed
like an unnecessary burden (or simply was innocently not considered, at al :-)
).
On the other hand, as you points out, to use the email introduced potential
drawbacks, such as requiring users that have changed email to reset their
password...
Just to be clear, I don't see a potential attack here.
Apologies if you've answered this many times before.
Regards,
Adrian.
1) I realise all decryption would give you is the e-mail address. I
suppose if an attacker for some reason has the encrypted passwords but
nothing else, they can use a dictionary attack to get the e-mails and
log-in.
Yep, theoretically this is a possibility, although if the attacker has the
encrypted string (i.e. the email encrypted with the password), he will likely
have the whole DB table including the emails.
2) I say slightly as it requires the attacker to know the random numbers
rather than just the (possibly public) e-mail. But if they have access
to the DB, they probably have the random numbers.
Yep! But as you propose, this solution would avoid resetting emails and make
attackers live a bit harder :-)
Definitively something to be taken into consideration.
I’d suggest you to open a ticket in Trac so that this proposal improvement is
not forgotten, but I am not sure you have an account for that, and account
creation is for the time being not fully automatic...
Cheers!
Samuele
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
