Skip to content

Include password in persistent hash key #19

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

Merged
merged 6 commits into from
Mar 10, 2022

Conversation

NattyNarwhal
Copy link
Member

Matches behaviour of other database extensions, and removes some surprise that the extension doesn't check for a valid password when reusing a connection. Of course, that must be the password the connection was created with, but that's the same for the others too.

Fixes GH-18

XXX: Would like to include options, but not sure how to do this cleanly.

Matches behaviour of other database extensions, and removes some
surprise that the extension doesn't check for a valid password when
reusing a connection. Of course, that must be the password the
connection was created with, but that's the same for the others too.

Fixes GH-18

XXX: Would like to include options, but not sure how to do this cleanly.
ibm_db2.c Outdated
@@ -2354,10 +2354,11 @@ static int _php_db2_connect_helper( INTERNAL_FUNCTION_PARAMETERS, conn_handle **
/* Check if we already have a connection for this userID & database combination */
if (isPersistent) {
zend_resource *entry;
hKeyLen = strlen(database) + strlen(uid) + 8;
hKeyLen = strlen(database) + strlen(uid) + strlen(password) + 9;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hKeyLen = strlen(database) + strlen(uid) + strlen(password) + 9;
hKeyLen = strlen(database) + strlen(uid) + strlen(password) + sizeof("__db2_");

Would be a bit more clear what the 9 means.

@tessus
Copy link
Member

tessus commented Dec 6, 2021

Ooops, I've commented on the issue. I'll copy and paste it here as well:

I am not so sure that I like the fact that the password is available in clear text in memory. We don't need a cryptagraphic hash function. Most of the time only one user/password combination is used in web applications.

This is also the reason why I only used a sub string of the hash and not the entire hash back then. e.g. CRC32 is more than enough.

@NattyNarwhal
Copy link
Member Author

Yeah, I found the fact everyone else leaves it out in the open a little surprising (Maybe worth discussing with internals@....). I was going to hash it if it was easy, though I didn't want to vendor/take an additional dependency for something even as trivial as CRC32....

@tessus
Copy link
Member

tessus commented Dec 7, 2021

Murmur has about the same collision rate as crc32 and does have an easy implementation:

uint32_t inline MurmurOAAT32 (const char * key)
{
  uint32_t h(3323198485ul);
  for (;*key;++key) {
    h ^= *key;
    h *= 0x5bd1e995;
    h ^= h >> 15;
  }
  return h;
}

uint64_t inline MurmurOAAT64 (const char * key)
{
  uint64_t h(525201411107845655ull);
  for (;*key;++key) {
    h ^= *key;
    h *= 0x5bd1e9955bd1e995;
    h ^= h >> 47;
  }
  return h;
}

I'd just pick either the 32 or 64 bit version and be done with it....

@tessus
Copy link
Member

tessus commented Dec 7, 2021

I can change the PR to use murmur, if you want me to.

Not cryptographic, but obfuscates the password for the purpose of a hash
key for internal usage.
@NattyNarwhal
Copy link
Member Author

Some missed opportunities, with array hashing, but those can be addressed later. I'd rather have this merged than sitting around.

@NattyNarwhal NattyNarwhal merged commit e103c68 into master Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pconnect doesn't check for valid password after a connection has been made
3 participants