How is a user's password transmitted from the browser to the server? Is it hashed in Javascript and then sent or is it sent plain text then hashed / stored in DB?
(2017-05-16, 03:09 AM).m. Wrote: [ -> ]hashing done through php [functions_user.php]
Awesome, thanks! Out of curiosity, if I wanted to implement my own hashing function that involved using the username as part of the hash, how complicated would that be? In the create_password() function I see the $user is optional so it is probably not as easy as just finding a global username variable (does one even exist?) and adding it to my hash function if its not present correct?
(2017-05-16, 04:27 AM)primesoftware Wrote: [ -> ] (2017-05-16, 03:09 AM).m. Wrote: [ -> ]hashing done through php [functions_user.php]
Awesome, thanks! Out of curiosity, if I wanted to implement my own hashing function that involved using the username as part of the hash, how complicated would that be? In the create_password() function I see the $user is optional so it is probably not as easy as just finding a global username variable (does one even exist?) and adding it to my hash function if its not present correct?
That isn't ideal.
You shouldn't add identifiable information (or easy to guess information) into the hash. This is where MyBB is going wrong *now* by adding the salt into the database. MyBB 2.0 fixes this by using bcrypt.
(2017-05-16, 04:27 AM)primesoftware Wrote: [ -> ] (2017-05-16, 03:09 AM).m. Wrote: [ -> ]hashing done through php [functions_user.php]
Awesome, thanks! Out of curiosity, if I wanted to implement my own hashing function that involved using the username as part of the hash, how complicated would that be? In the create_password() function I see the $user is optional so it is probably not as easy as just finding a global username variable (does one even exist?) and adding it to my hash function if its not present correct?
Like Ben said:
do not use the username as any part of a salt. Moreover, don't reinvent the wheel. If you're going to improve the hashing, use the password_hash() API in PHP 5.5 and above (or via the password_compat library for 5.3.8 or later). Don't make your own custom hashing functions unless some other software you're using absolutely has to use that. And in that case, you should probably seriously consider tweaking that software instead.
Since MyBB 1.8.11 it's feasible to override the password verification logic thanks to new plugin hooks, although you'd need some significant experience with PHP to make it work correctly.
If you're interested in improving server-side password security, you can use
DVZ Hash.
(2017-05-16, 02:59 PM)Devilshakerz Wrote: [ -> ]Since MyBB 1.8.11 it's feasible to override the password verification logic thanks to new plugin hooks, although you'd need some significant experience with PHP to make it work correctly.
If you're interested in improving server-side password security, you can use DVZ Hash.
Thanks for the info! That plugin looks rather interesting. I think I will leave well enough alone. I am experienced with PHP which leads to me conclude its probably going to take me more time to get right than I have right now.
(2017-05-16, 05:46 AM)Ben Cousins Wrote: [ -> ]This is where MyBB is going wrong *now* by adding the salt into the database. MyBB 2.0 fixes this by using bcrypt.
Storing the salt in the database is the right way to prevent rainbow table attacks because the salt needs to be unique for every user. Bcyrpt does it in the same way.