DB password stored in cache when using result cache #5898

Closed
opened 2026-01-22 15:21:29 +01:00 by admin · 4 comments
Owner

Originally created by @fullbl on GitHub (Feb 22, 2018).

Originally assigned to: @Ocramius on GitHub.

Hi!
Today I was debugging some problems with result cache and I noticed that data is saved like this:

connectionParams=a:12:{s:4:\"host\";s:9:\"localhost\";s:4:\"port\";N;s:6:\"dbname\";s:16:\"__DBNAME__\";s:4:\"user\";s:7:\"__USER__\";s:8:\"password\";s:20:\"__!!!REAL_PASSWORD!!!__\";s:7:\"charset\";s:4:\"UTF8\";s:6:\"driver\";s:9:\"pdo_mysql\";s:13:\"driverOptions\";a:1:{s:20:\"x_reconnect_attempts\";i:3;}

obviously, everything that starts and ends with __ is the real variable, so also password is saved in clear.

Isn't it a security issue? Shouldn't it be hashed?

Originally created by @fullbl on GitHub (Feb 22, 2018). Originally assigned to: @Ocramius on GitHub. Hi! Today I was debugging some problems with result cache and I noticed that data is saved like this: `connectionParams=a:12:{s:4:\"host\";s:9:\"localhost\";s:4:\"port\";N;s:6:\"dbname\";s:16:\"__DBNAME__\";s:4:\"user\";s:7:\"__USER__\";s:8:\"password\";s:20:\"__!!!REAL_PASSWORD!!!__\";s:7:\"charset\";s:4:\"UTF8\";s:6:\"driver\";s:9:\"pdo_mysql\";s:13:\"driverOptions\";a:1:{s:20:\"x_reconnect_attempts\";i:3;}` obviously, everything that starts and ends with __ is the real variable, so also password is saved in clear. Isn't it a security issue? Shouldn't it be hashed?
admin added the ImprovementQuestion labels 2026-01-22 15:21:30 +01:00
admin closed this issue 2026-01-22 15:21:30 +01:00
Author
Owner

@Ocramius commented on GitHub (Feb 22, 2018):

Isn't it a security issue?

No, cache is still part of your infrastructure here. If you get access to the ORM cache, you can already completely hijack an application here (password or no password).

Shouldn't it be hashed?

Hashing it is a possibility here. We need to add the parameters to disambiguate the backend where a query comes from. The generic problem that we had to solve is that multiple DB instances may be used by a single application, while a single cache still holds true.

If you want to propose a patch that just hashes these contextual parameters, I'd gladly factor it into the next major 👍

@Ocramius commented on GitHub (Feb 22, 2018): > Isn't it a security issue? No, cache is still part of your infrastructure here. If you get access to the ORM cache, you can already completely hijack an application here (password or no password). > Shouldn't it be hashed? Hashing it is a possibility here. We need to add the parameters to disambiguate the backend where a query comes from. The generic problem that we had to solve is that multiple DB instances may be used by a single application, while a single cache still holds true. If you want to propose a patch that just hashes these contextual parameters, I'd gladly factor it into the next major :+1:
Author
Owner

@fullbl commented on GitHub (Feb 22, 2018):

To be honest, cache could be on another machine!
However, I will try to see if hashing is possible when I have some spare time!

@fullbl commented on GitHub (Feb 22, 2018): To be honest, cache could be on another machine! However, I will try to see if hashing is possible when I have some spare time!
Author
Owner

@Ocramius commented on GitHub (Feb 22, 2018):

To be honest, cache could be on another machine!

Yes, it most likely is another machine: I already considered that :)

@Ocramius commented on GitHub (Feb 22, 2018): > To be honest, cache could be on another machine! Yes, it most likely is another machine: I already considered that :)
Author
Owner

@Ocramius commented on GitHub (Mar 29, 2018):

Handled via doctrine/dbal#3031

@Ocramius commented on GitHub (Mar 29, 2018): Handled via doctrine/dbal#3031
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5898