Support using pre-hashed passwords

[derekbrokeit]

Asyncpg should also support using HASH objects or pre-hashed strings. Also, I would suggest that once the authentication method has been identified (e.g. md5, sha, no-hash) then the password should be morphed. As it currently stands, the password can be retrieved in plain text by other libraries that have access to the Connection or Pool objects.

# malicious code can easily get away with this:
print(pool._connection_kwargs['password'])

[elprans]

This is impossible, I'm afraid. Most authentication methods rely on server-supplied salt, and, hence, cannot be pre-computed. This is actually a security feature to prevent the replay attacks.

[derekbrokeit]

Thanks for the response, but I don't see why this line cannot have the following part pre-hashed? It would seem that the implementation used here hashes the password and then hashes again after the salt arrives. Am I misunderstanding?

userpass = ((self.password or '') + (self.user or '')).encode('ascii')
hashlib.md5(userpass).hexdigest()

[elprans]

I stand corrected. At least for MD5 we can do that. Not that it would make your password much safer, MD5 is badly broken these days.

[derekbrokeit]

Thanks for checking. I agree on md5, it would also be important for whatever solution to also support #314

[elprans]

I'm looking at RFC5802 (SCRAM), and I don't think that it supports pre-hashed secrets, due to this bit:

First, the client sends the "client-first-message" containing:

o a GS2 header consisting of a flag indicating whether channel
binding is supported-but-not-used, not supported, or used, and an
optional SASL authorization identity;

o SCRAM username and a random, unique nonce attributes.

[snip...]

In response, the server sends a "server-first-message" containing the
user's iteration count i and the user's salt, and appends its own
nonce to the client-specified one.

So, unless I'm reading this incorrectly, the hash function parameters always come from the server at connection time, and the password must be passed into the function as plain text.

For this reason, I don't think it's worth it to support "hashed_password" in the connection parameters if it's only useful for MD5 auth.

Also, the stated premise of defense against a malicious script is pretty weak. If you've got unauthorized code running in your address space, that's game over anyway.

[derekbrokeit]

I have not looked into the scram-sha256 method, so if it is inherently incompatible, it is understandable to pass. The main use case was looking at extensible libraries that need to maintain one or more connections to a database could potentially be affected by a malicious extension, but users should be aware of hazards of using unkown code.

As I have found, which may or may not be the case for scram-sha256, the password is actually stored and easily accessed table when using md5, which is rather unsafe.

select rolname, rolpassword from pg_authid;
# rolpassword = 'md5' + hashlib.md5(password + username)

[elprans]

The hashing in pg_authid depends on the password_encryption setting

[derekbrokeit]

That's right, the hashed password is stored, which is why I suspected it would be best to keep the hashed password in asyncpg. I have not looked into or tested scram-sha256 much, but if the password is not stored as a sha256 hash or similar, then it may be more difficult to support this feature request.

[eirnym]

@derekbrokeit basically if an attacker has an access to your filesystem and ability to execute the code, he can find a password and/or SSL key. The only way to have protect from that kind of attack is a physical key/password storage which will be removed just after key was read.

Even if a client sends sha3 encrypted info, it works like a plain text password on the network level.

I can find good QA references if you're interested

[derekbrokeit]

Thanks @eirnym , I understand that the hashed password is just as good on the programmatic level for gaining access to the system. In that sense, I suppose there is no need to hide the password by hashing it. I guess, I just feel uncomfortable having a client's password floating around as raw text.

[eirnym]

@derekbrokeit I understand you. May we have a chat somewhere. I want to know if I able to propose something suitable for your situation.

[chris-allnutt]

@derekbrokeit I don't think pre-hashing solves your problem either if in fact the lib could authenticate to the database with it. I think the only way you can be certain this isn't happening with external libraries would be to:

1. Review all code of all external libs you're using to check for this maliciousness (could be an awk script that fails build)
2. Make a proxy service executing on a separate machine that handles ONLY your db requests and exposes them via API, but that's a lot more complexity in implementation.

Are there any examples of other libraries that do this? This is something I think is an issue of any and all dynamically typed languages without protected memory spaces or private member variables. Even using a prefix of __ by PEP8's standards won't stop someone from seeing the actual values and inferring what they are, such as in an exhaustive attack.