Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A 64-char hex string should be allowed for the blowfish_secret config directive #19096

Open
jasonmacer opened this issue Apr 4, 2024 · 4 comments
Assignees

Comments

@jasonmacer
Copy link

Describe the bug

When using a clean install of phpMyAdmin-5.2.1-english and cookie encryption login, when using a 32 byte (64 character) blow_fish secret the error "The cookie encryption key in the configuration file is longer than necessary. It should only be 32 bytes long. Please refer to the documentation."

To Reproduce

Steps to reproduce the behavior:

  1. Download and unpack phpMyAdmin-5.2.1-english
  2. move files to /usr/share/phpMyAdmin
  3. create tmp directory at /usr/share/phpMyAdmin/tmp
  4. chown -R apache:apache /usr/share/phpMyAdmin
  5. chmod 777 /usr/share/phpMyAdmin/tmp
  6. cp /usr/share/phpMyAdmin/config.sample.inc.php /usr/share/phpMyAdmin/config.inc.php
  7. generate a random 32 byte string
  8. nano /usr/share/phpMyAdmin/config.inc.php
  9. insert random string from (7) above into $cfg['blowfish_secret'] = '<STRING_HERE>';
  10. save file then restart apache
  11. access phpMyAdmin at HTTP://IP_ADDRESS/phpMyAdmin
  12. Error appears at bottom stating: "The cookie encryption key in the configuration file is longer than necessary. It should only be 32 bytes long. Please refer to the documentation."

Expected behavior

According to the error message AND the documentation referenced in the error, this string should be 32 bytes in length which is 64 characters; however, 64 characters returns an error.

Screenshots

Logged On Error Message
image

Documentation
image

config.inc.php file (I have changed my key since this)
image

Server configuration

  • Operating system: Oracle Linux 9.3
  • Web server: Apache 2.4.57
  • Database version: Percona 8.0.36-28
  • PHP version: 8.2
  • phpMyAdmin version: 5.2.1

Client configuration

  • Browser: Brave && Chrom && Firefox
  • Operating system: Windows 10

Additional context

I can cut the string in half to a 16 byte string (32 characters) and the error goes away.

@M393
Copy link
Contributor

M393 commented Apr 4, 2024

32 characters are 32 bytes! Why do you think it is 16 bytes?

In the documentation the function sodium_hex2bin is used which converts the 64 hex characters to 32 bytes. But you aren't using it in your config, so there it is 64 bytes.

@jasonmacer jasonmacer changed the title Cookie Authentication - 'blowfish_secret' length requirements [RESOLVED]Cookie Authentication - 'blowfish_secret' length requirements[/RESOLVED] Apr 11, 2024
@MauricioFauth
Copy link
Member

I think accepting a 64-char hex string and then phpMyAdmin converts it to binary internally is reasonable.
What do you think @williamdes?

@williamdes
Copy link
Member

I think accepting a 64-char hex string and then phpMyAdmin converts it to binary internally is reasonable. What do you think @williamdes?

I agree, let's be more flexible

@MauricioFauth MauricioFauth changed the title [RESOLVED]Cookie Authentication - 'blowfish_secret' length requirements[/RESOLVED] A 64-char hex string should be allowed for the blowfish_secret config directive Apr 16, 2024
@StefanRacoveanu
Copy link

I see that the check that produced the error is here:

} elseif ($encryptionKeyLength > SODIUM_CRYPTO_SECRETBOX_KEYBYTES) {

The above check is called by the __invoke() function in the HomeController:
$this->checkRequirements();

I believe that the best course of action is to add a check if the string is 64 characters long after which check if the string is hexadecimal using the ctype_xdigit() function. If this check is also true, then use the hex2bin() function to convert the string and override the original blowfish_secret. If any of the checks fail the blowfish_secret should remain unchanged.

Also, the documentation should be changed to reflect the change in behaviour. Should I change that in the same PR?

@MauricioFauth What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants