pgadmin password length cannot be 13

[douggutaby]

The operator and postgres can handle passwords which is 13 chars long, but pgadmin cannot.

If I set a password: kubectl patch secret -n postgres-operator hippo-pguser-hippo -p '{"stringData":{"password":"1234567890123","verifier":""}}' in the sqlite database of the pgadmin it won't be hashed:

sqlite> select * from user;
1||||0|||internal
2|hippo@pgo|hippo@pgo|1234567890123|1||any|internal

and I cannot login to pgadmin with it. But if it is 12 or 14 long, it will be hashed and work.

I'm sorry, if I missed this it the docs, but I cannot find anything about pgadmin password length limit.

I thought it related to anyuid but it is not. I working on Openshift 4.12 and Crunchy 5.3.1 with openshift: true

[jmckulk]

Hi @douggutaby,

I have been able to replicate this in a local kube environment (without OpenShift). There shouldn't be any password length limitation that is specifically for 13 characters. This is a very odd issue that does seem like a bug. I'll make a story in our backlog to look into it further.

Thanks for submitting this issue!

[benjaminjb]

Hi @douggutaby, I wanted to update you on this issue, first with what I think is going on; and then with our current plans for pgAdmin4.

What is going on This isn't the whole story, but this is where I found some interesting behavior: the operator does some SQLAlchemy to save the users from the Postgrescluster.spec.users to the pgAdmin db here.

The pgAdmin4 User model used the flask_security UserMixin, which is where we get that verify_and_update_password func. And this is the func that will hash the password. So we could start with the hypothesis that a 13-character password isn't hitting that part of the func.

(This version of flask/pgAdmin4 isn't what we have in the 4.30 container, but I catted the files, and the funcs I need are the same.)

Long story short, I tested that hypothesis by running python with a lot of pgAdmin4 and other necessary modules, and here's what I got, using both a 13-char password and a non-13-char-password:

First, I'm going to see which length of password (12, 13, 14) returns true from use_double_hash:

>>> with create_app().app_context():
   flask_security.utils.use_double_hash("123456789012")
   flask_security.utils.use_double_hash("1234567890123")
   flask_security.utils.use_double_hash("12345678901234")
False
True
False

Well, that's interesting, 13 is being treated differently: 12- and 14-character passwords return false from use_double_hash and 13 returns true, so they get verified differently: the 12 and 14-character passwords get verified without the get_hmac func, while the 13 does -- but I'm going to throw in a check with the 13-character password without the get_hmac:

>>> with create_app().app_context():
   _security = LocalProxy(lambda: current_app.extensions["security"])
   _pwd_context = LocalProxy(lambda: _security.pwd_context)
   _pwd_context.verify('123456789012', '123456789012')
   _pwd_context.verify(flask_security.utils.get_hmac('1234567890123'), '1234567890123')
   _pwd_context.verify('12345678901234', '12345678901234')
   _pwd_context.verify('1234567890123', '1234567890123')
True
False
True
False

So the 13-character password is not verified -- and wouldn't be verified even if it weren't being treated differently in the use_double_hash func.

OK, so that experiment seems to prove the hypothesis: the 13-character password isn't being hashed when we call verify_and_update_password because it is not being verified (or identified) like other passwords.

We might be able to get around this if we instead used something like the hash_password function rather than the verify_and_update_password -- but I'm going to hold off making that change/recommendation because of our plans for pgAdmin4.

Our plans for pgAdmin4 We've recently released a new CRD specifically for pgadmin4 in order to decouple pgAdmin4 from the postgrescluster CRD. (For more on that, see these docs.)

The new implementation for pgAdmin4 doesn't sync users from the postgrescluster (since this pgAdmin4 is not associated with any postgrescluster). This means that we're not doing the password manipulation which resulted in this error when using a password of 13 characters.

Instead of syncing user, this new implementation gives you an admin user in pgAdmin4. As a test, I spun up a pgAdmin4 instance and (from the admin account) I created a user with a 13-character password. I was able to sign in with that user.

So, going forward with this situation: since we are not currently working on syncing users in the new implementation, this bug shouldn't come up. BUT since I've already gotten a lot of information on this topic, I'm writing up my notes in case we reconsider this behavior.

Just to make sure: does the behavior of the older pgadmin-per-postgrescluster implementation present a blocker for you? Can you upgrade to the newer implementation or avoid 13-character passwords?

(I'm going to leave this issue open in case anyone wants to add to the discussion.)

[ValClarkson]

Hi @douggutaby, Since we haven't heard back on this issue for some time, I am closing this issue. If you need further assistance, feel free to re-open this issue or ask a question in our Discord server.