Can't access to backofice in a new installation

[danwarrior]

Hi, guys!

I've just installed TB 1.5 and I can't access to any of the users I create. At first I though it could be wrong password, but I've reseted it several times, even create more users (from PHPMyAdmin, of course), and it's not working. It always says 

Hay un error.

1. The employee does not exist, or the password provided is incorrect.

I'm using the cookie key + MD5 method, this one:

Am I wrong?

I have PHP 7.4 on my server... I don't see any of you is having this issue, weird.

Thanks so much for guiding me.

Edited November 9, 2023 by danwarrior

[led24ee]

I don't understand why is there need to create user via MyAdmin ? This is some kind of joke or what's the point of this ? And maybe I'm wrong but there is no actual password in database, there is checksum which is combined from password. Password is only the name of this cell or row. For me it looks like dentistry through the butthole.

Edited November 10, 2023 by led24ee

[danwarrior]

2 hours ago, led24ee said:

I don't understand why is there need to create user via MyAdmin ? This is some kind of joke or what's the point of this ? And maybe I'm wrong but there is no actual password in database, there is checksum which is combined from password. Password is only the name of this cell or row. For me it looks like dentistry through the butthole.

Hahahaha, you made me laugh xD I don't know, honestly, I just tried things that used to work for me in PS. Wich may I'm wrong, that's why I'm asking here. The thing is it's a clean installation and I can't access with the pw I created, so... 🙇‍♂️

[datakick]

Yes, that means our security fix works properly and as designed.

For security reasons, thirty bees 1.5 makes HMAC-SHA256 signature of employee security-critical fields (Employee ID, Permission profile ID, Email, Password) and stores this signature inside new column database signature.

If somebody changes any of these fields externally, without re-calculating signature, the employee record will be invalid.

The reason behind this change is to prevent elevation of (possible) SQL injections vulnerabilities into absolute access to the system. 

Imagine your system contains some SQL Injection vulnerability (we don't know about any in core or native modules, but we know about lot in third party modules). Attacker could use such vulnerability to change password and email of any employee, or even insert a new super-admin employee into database. Then, attacker can simply login to back office with full access privileges. 

SQL Injection vulnerability itself is absolutely critical problem, of course. But giving attacker back office admin access is much worse - because attacker is able to install custom module, and therefore execute arbitrary PHP scripts.

This employee signature block this. 

You should create employees account them in standard way (back office or via webservice).