Alexander Kukushkin <cyberd...@gmail.com> writes: > I think I should add my two cents. > We at Zalando are using JWT tokens as passwords. JWT tokens are > self-contained and therefore quite huge (up to 700-800 bytes in our > case). Tokens have a limited lifetime (1 hour) and we are using PAM to > verify them. > Altogether the whole thing works like a charm. The only problem that > it is not possible to copy&paste the token into psql password prompt, > but there is a workaround, export PGPASSWORD=verylongtokenstring && > psql
I remain unconvinced that this is a good design, as compared to the alternative of hashing $large_secret_data down to a more typical length for a password. Quite aside from whether or not you run into any implementation restrictions on password length, using externally-sourced secret data directly as a password seems like a lousy idea from a pure security standpoint. What happens if somebody compromises your database, or even just your connection to the database, and is able to read out the raw password? The damage is worse than the ordinary case of just being able to get into your database account, because now the attacker has info about a formerly-secure upstream datum, which probably lets him into some other things. It's not unlike using the same password across multiple services. In the case you describe, you're also exposing that data to wherever the PAM mechanism is keeping its secrets, hence presenting an even larger attack surface. Hashing the data before it goes to any of those places would go a long way towards mitigating the risk. regards, tom lane