RevCMS BCRYPT

[Blasteh]

Hello,
I'm resetting my hotel and I want to encrypt passwords differently. I want to use a more secure one, such as bcrypt.

By default, rev uses md5.

    final public function hashed($password)
    {
        return md5($password);
    }

I want to use a more secure method, but after changing it, I cannot login as it says "Details do not Match".

    final public function hashed($password)
    {
        return password_hash($password, PASSWORD_BCRYPT);
    }

The password does encrypt to bcrypt in the database, the only problem is – I cannot login!

 

[MayoMayn]

I'm unsure, lol. Never was good with PHP.

If you go to my class.users.php (

You must be registered for see links

) you'd understand better than I would and you can lead me in the right direction. As stated before, I have no clue.

Just change your userValidation function to this.

final public function userValidation($username, $password)
    {
       $query = mysql_query("SELECT `password`FROM `users` WHERE `username` = '".mysql_real_escape_string($username)."' LIMIT 1");
       $dbpass  = mysql_result($query, 0);
      return password_verify($password, $dbpass);
}

And change the if statement you had before to this, basically just without the hashing part.

if($this->userValidation($template->form->log_username, $template->form->log_password))

If this doesn't work, you're simply just doing something wrong. Did you truncate your users table, or did you hash all the existing md5 hashes with the bcrypt? Because, then thats why, if this doesn't work.

 

[JayC]

Just change your userValidation function to this.

final public function userValidation($username, $password)
    {
       $query = mysql_query("SELECT `password`FROM `users` WHERE `username` = '".mysql_real_escape_string($username)."' LIMIT 1");
       $dbpass  = mysql_result($query, 0);
      return password_verify($password, $dbpass);
}

And change the if statement you had before to this, basically just without the hashing part.

if($this->userValidation($template->form->log_username, $template->form->log_password))

How can you say mine was really badly coded, and than do the exact same thing just different formatting?

I am not familiar with this hash, so I didn't know if it hashed it the same way everytime or not. I use another method. I was providing an example of how to test it and login. The idea behind it was so that users who were already created would not notice any changes in the backend . Meaning when they logged in; it would update their passwords to the new encryption.

 

[Blasteh]

RevCMS isn't made for bcrypt, so I'd suggest you did some research, instead of just whining about scripts not working correctly, because you don't know how to integrate them. Sorry to say, but its the harsh truth.

Okay, so. I can create a new account and it works fine. Until I log out, and try to log back in. Before, it would let me create an account, but then not show an avatar or anything and when I reloaded the page; it'd take me to the index.

If bcrypt is an issue and isn't compatible; any other encryption methods?

 

[MayoMayn]

Okay, so. I can create a new account and it works fine. Until I log out, and try to log back in. Before, it would let me create an account, but then not show an avatar or anything and when I reloaded the page; it'd take me to the index.

If bcrypt is an issue and isn't compatible; any other encryption methods?

It's fine, I recoded RevCMS to PDO a year ago, which included bcrypt as password hashing. You're just doing it wrong.
Could you post an example of the hash in the password column inside the users table?
If its not something like this $2y$12$, in the start then you're definitely doing it wrong.

 

[Blasteh]

It's fine, I recoded RevCMS to PDO a year ago, which included bcrypt as password hashing. You're just doing it wrong. Could you post an example of the hash in the password column inside the users table?

Okay, I think this is what you mean.

$2y$10$kgPU.Pyj9xuuIXxHkTso.eGxpWOi7KjuQUBJ925v0P4kGNYSf0rpK

I'm on my localhost (PC), not my server hence the Apache.
 
Shit, wrong image.

You must be registered for see images attach

 

[MayoMayn]

Okay, I think this is what you mean.

$2y$10$kgPU.Pyj9xuuIXxHkTso.eGxpWOi7KjuQUBJ925v0P4kGNYSf0rpK

You must be registered for see images attach

I'm on my localhost (PC), not my server hence the Apache.

Definitely not the password verifying thats wrong with, I can tell you that.

EDIT:
All I can suggest, is getting a new cms that isnt deprecated as fuck.

 

[Blasteh]

Definitely not the password verifying thats wrong with, I can tell you that.

EDIT:
All I can suggest, is getting a new cms that isnt deprecated as fuck.

Thanks anyways Sent, much

 

[CosmoPeak]

What the hell kind of password validation is that lmfao. First query line, select password from users where username is post password? Wtf.
Either way, this wouldn't work, since you're not verifying the posted password, you're just hashing the input and checking it against the one in the database. By this reply, you clearly don't understand how hashing works. Every hash is different from one another, even though if the string is the same, so this wouldn't even be close to working at all.

1. Jay's example is designed to be backwards compatible with md5 passwords (which RevCMS uses) - If the password matches with an md5 hash, it's updated with a stronger hash using bcrypt.
2. That's EXACTLY how hashing works. If the strings are the same, the hashes will also be identical.

 

[MayoMayn]

1. Jay's example is designed to be backwards compatible with md5 passwords (which RevCMS uses) - If the password matches with an md5 hash, it's updated with a stronger hash using bcrypt.
2. That's EXACTLY how hashing works. If the strings are the same, the hashes will also be identical.

1. Jays reply wasn't even a correct way to verify password hashes with the built-in functions, as I've mentioned several times, but you clearly didn't bother to read before commenting.
2. Nope, it isn't, not if you apply a salt, as is recommended, and is a default by crypt, base64. mcrypt, openssl and so on.

Spoiler

You must be registered for see links

You must be registered for see links

You always should apply a salt when hashing passwords, to have a different hash even if you have the same password. This increases security by "preventing" people from using rainbow tables to crack the password.

Please do some research before posting shit like every other habtard does.

 

[CosmoPeak]

1. Jays reply wasn't even a correct way to verify password hashes with the built-in functions.
2. Nope, it isn't, not if you apply a salt, as is recommended, and is a default by password_hash(), crypt, base64 and mcrypt.

Spoiler

You must be registered for see links

You must be registered for see links

You always should apply a salt when hashing passwords, to have a different hash even if you have the same password. This increases security by "preventing" people from using rainbow tables to crack the password.

Please do some research before posting shit.

The only issue with Jay's post is not using password_verify, as using password_hash again will use a different salt.

Yes, salts are simply added on to the string you are hashing to prevent rainbow table attacks. The salted password will still have the exact same hash as the salted password in the database. That's the entire point of a hash.

 

[Brad]

Thread has been cleaned.