On 4/22/19 6:42 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> OK, so I have something that sort of works, i.e:
>
>> if (strncmp(shadow_pass, "md5", 3) == 0 &&
>> strlen(shadow_pass) == MD5_PASSWD_LEN &&
>> strspn(shadow_pass, MD5_PASSWD_CHARSET) == MD5_PASSWD_LEN
>> )
>
>> where MD5_PASSWD_CHARSET = "mabcdef0123456789"
>
>> ...but you may notice something: the CHARSET contains an "m" as we store
>> that "md5" prefix on the md5 hashed passwords.
>
> Yeah, that's silly; why not
>
> strspn(shadow_pass + 3, MD5_PASSWD_CHARSET) == MD5_PASSWD_LEN - 3
>
> It's not like this code isn't very well aware of the first 3 characters
> being not like the others.
I like that :) Please see attached patch, which is diff'd from the one
upthread.
I tested using the following:
/* Log in with "abc" */
CREATE ROLE test1 PASSWORD 'md5cdde562ece166a02f5392b656dcf2502' LOGIN;
/* Logs in with "md5cdde562ece166a02f5392b656dcf250g" */
CREATE ROLE test2 PASSWORD 'md5cdde562ece166a02f5392b656dcf250g' LOGIN;
/* Logs in with "md5cdde562ece166a02f5392b656dcf250m" */
CREATE ROLE test3 PASSWORD 'md5cdde562ece166a02f5392b656dcf250m' LOGIN;
I debated adding a test...without being able to simulate a log in, I
don't know if it tests much other than "yes, you can store an invalid
md5 hash and it treats it as plaintext."
Thanks,
Jonathan