On 07/09/16 22:03, Nicolás Alvarez wrote:
On Sep 7, 2016, at 17:53, CM <[email protected]> wrote:
On 07/09/16 21:19, Nicolás Alvarez wrote:
2016-09-07 17:11 GMT-03:00 CM <[email protected]>:
Hey,
I wrote about this in boinc_projects but felt it would appropriate to also
post it in the boinc_dev mailinglist before raising an issue in the BOINC
github:
http://lists.ssl.berkeley.edu/mailman/private/boinc_projects/2016-September/011834.html
Topic of discussion: The current BOINC project user password
hashing process!
Upon creating an account, the user's password is hashed as an md5 & salted
with their email address:
https://github.com/BOINC/boinc/blob/master/html/user/create_account_action.php#L107
If a BOINC server was fully compromised, the attacker would have access to
all user's email addresses in the SQL table (entirely negating the salt's
effectiveness) leaving the password only protected by an md5 hash.
I looked up whether or not an md5 password hash is sufficient protection,
and the overwhelming response was a resounding no:
https://security.stackexchange.com/questions/19906/is-md5-considered-insecure
"Using salted md5 for passwords is a bad idea. Not because of MD5's
cryptographic weaknesses, but because it's fast. This means that an attacker
can try billions <http://hashcat.net/oclhashcat-plus/>of candidate passwords
per second on a single GPU."
I realise that switching to a different password hashing mechanism for an
existing BOINC account wouldn't be possible without resetting the entire
user base's passwords via email (which would be a nightmare), but for a new
BOINC project would it not be advisable to switch to using a more secure
password hashing process such as Bcrypt or PBKDF2 for password hashing?
Looking further into this, using boinc-server-docker provides php v5.6 & in
php v5.5 they introduced simple password hashing functionality
(password_hash(), password_verify(), etc) which implements bcrypt which is
significantly more secure than md5 & it wouldn't be adding crazy amounts of
new code nor external libraries.
https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 (see
the php section, pretty simple!)
https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
If we were to migrate from 5.6 to 7.0+ in the future
(https://secure.php.net/manual/en/migration70.php would it pose a
significant challenge?), we could also switch to Argon2 instead of bcrypt as
default: https://password-hashing.net/ (Also worth checking out the other
entries).
Thoughts regarding this? I'm going to try using Bcrypt in my 'Project Rain'
project.
To login, you send the email address and the password hash. The
hashing algorithm is irrelevant because you don't even need to crack
it. If the server is compromised, you get access to the password hash,
and you can send it in a request to login. There are no "candidate
passwords" involved.
BOINC has the security equivalent of storing the passwords in
plaintext. The security or speed of MD5 is absolutely irrelevant.
Note: Sorry Nicolas for the spam, I accidentally directly replied - CC'ing the
boinc_dev mailing list this time, please excuse my lack of mailing list
experience.
Yes, if a BOINC account is compromised you can effectively log into all user
accounts via each user's authenticator/account key (I don't believe with the
password hash since the BOINC server would attempt to hash the password hash &
reject the login).
The client calculates the hash of the password and sends it to the server. The
server compares it to what is in the database without hashing it again.
Security-wise, the hash is the password and it's in plaintext. Either
intercepting the network request or accessing the database gives you all you
need to login.
I don't believe you send the password hash, but rather you send the password and
the BOINC server hashes it then compares it to the stored password hash &
rejects the login attempt if it doesn't match. Only projects that don't use SSL are
sending passwords/account keys plain-text over the internet.
I have read the code, and I have seen what requests look like in the server logs. You
send the hash to the server. You should at least look at a non-SSL network capture while
attaching to a project before saying how you "believe" it works...
But even then, anything about password storage security in BOINC is of little
relevance (except for the problem of password reuse). The account key is in the
database and sent on every request. If you get that, you can also login to the
project, and it's even worse than the password because users can't change the
account key.
Ah, OK I was thinking about how the website handles the login process
rather than the BOINC client login process.
So, if it's hardcoded into the BOINC client to hash the password (as
md5, then use email as salt) before sending the 'login/attach' message
to the BOINC project server then by implementing bcrypt on my project
I'll potentially break the login/register functionality within the BOINC
client for my project? Nightmare!
I do think password storage security within BOINC projects is of
relevance, alongside the other security issues you have raised. Would it
make more sense to handle the password hashing on the web server rather
than the BOINC client and to potentially encrypt the communications
between the client and server (on top of SSL)?
Regarding account keys (authentication key?), I raised this issue in my
original email on boinc_projects
(http://lists.ssl.berkeley.edu/mailman/private/boinc_projects/2016-September/011834.html),
I'm going to try and create account key reset functionality for my project.
Regarding intercepting account credentials, I just had a quick look -
the 'choose a project' window only provides https for Collatz despite
the majority of the projects in the list having SSL. I really hope where
SSL is available it switches to it, but i dread to realize all these
projects are in fact using plain text HTTP?
Best regards,
CM.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
