From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Zaur Hajili <zaurhajili(at)gmail(dot)com>, pgsql-www(at)postgresql(dot)org |
Cc: | nigarsalman7(at)gmail(dot)com |
Subject: | Re: passwordcheck module problem |
Date: | 2024-02-15 12:45:31 |
Message-ID: | b3c48e1e-4f82-4131-b7de-af1896c32dd8@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-www |
Hi,
First, please note that this mailing list is for reporting issues
related to the web properties of PostgreSQL. For general discussion
items, please use pgsql-general@
On 2/15/24 7:20 AM, Zaur Hajili wrote:
> Hi,
>
> recently one of dba course students informed me about problem of
> passwordcheck module.
>
> I cannot imagine that it is not a known issue, but if this is the known
> issue, then passwordcheck module loses all its functionality.
>
> Problem is, when a user changes its password via*\password *(psql meta
> command) command, it can set any simple password successfuly.
>
> Tested in versions 14,15,16. same behavior.
You're seeing the SCRAM hash, which is due to switch to using SCRAM as
the default hashing method from PostgreSQL 14+. Prior to that, it was
md5, which would still generate a md5 hash using \password.
> Postgres must check the password before converting to hash, it is clear
> that after hash it cannot detect the weakness.
This can get into a long debate about the value of checking the strength
of a plaintext password by enforced requirements. However, with a hash,
you can still check if the hashed password is in a common dictionary of
passwords with the tradeoff that this computation can take some time
depending on how large the dictionary is.
Thanks,
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-02-15 12:45:52 | Re: passwordcheck module problem |
Previous Message | Zaur Hajili | 2024-02-15 12:20:17 | passwordcheck module problem |