passwordcheck: Log cracklib diagnostics

Started by Peter Eisentrautover 5 years ago4 messageshackers
Jump to latest
#1Peter Eisentraut
peter_e@gmx.net

A user tried to use the cracklib build-time option of the passwordcheck
module. This failed, as it turned out because there was no dictionary
installed in the right place, but the error was not properly reported,
because the existing code just throws away the error message from
cracklib. Attached is a patch that changes this by logging any error
message returned from the cracklib call.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachments:

0001-passwordcheck-Log-cracklib-diagnostics.patchtext/plain; charset=UTF-8; name=0001-passwordcheck-Log-cracklib-diagnostics.patch; x-mac-creator=0; x-mac-type=0Download+6-3
#2Daniel Gustafsson
daniel@yesql.se
In reply to: Peter Eisentraut (#1)
Re: passwordcheck: Log cracklib diagnostics

On 25 Aug 2020, at 12:20, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:

A user tried to use the cracklib build-time option of the passwordcheck module. This failed, as it turned out because there was no dictionary installed in the right place, but the error was not properly reported, because the existing code just throws away the error message from cracklib. Attached is a patch that changes this by logging any error message returned from the cracklib call.

+1 on this, it's also in line with the example documentation from cracklib.
The returned error is potentially a bit misleading now, as it might say claim
that a strong password is easily cracked if the dictionary fails load. Given
that there is no way to distinguish between the class of returned errors it's
hard to see how we can do better though.

While poking at this, we might as well update the docs to point to the right
URL for CrackLib as it moved from Sourceforge five years ago. The attached
diff fixes that.

cheers ./daniel

Attachments:

cracklib_url.diffapplication/octet-stream; name=cracklib_url.diff; x-unix-mode=0644Download+1-1
#3Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Daniel Gustafsson (#2)
Re: passwordcheck: Log cracklib diagnostics

On Tue, 2020-08-25 at 13:48 +0200, Daniel Gustafsson wrote:

On 25 Aug 2020, at 12:20, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:

A user tried to use the cracklib build-time option of the passwordcheck module. This failed, as it turned out because there was no dictionary installed in the right place, but the error was not
properly reported, because the existing code just throws away the error message from cracklib. Attached is a patch that changes this by logging any error message returned from the cracklib call.

+1 on this, it's also in line with the example documentation from cracklib.
The returned error is potentially a bit misleading now, as it might say claim
that a strong password is easily cracked if the dictionary fails load. Given
that there is no way to distinguish between the class of returned errors it's
hard to see how we can do better though.

While poking at this, we might as well update the docs to point to the right
URL for CrackLib as it moved from Sourceforge five years ago. The attached
diff fixes that.

+1 on both patches.

Yours,
Laurenz Albe

#4Peter Eisentraut
peter_e@gmx.net
In reply to: Laurenz Albe (#3)
Re: passwordcheck: Log cracklib diagnostics

On 2020-08-25 15:32, Laurenz Albe wrote:

On Tue, 2020-08-25 at 13:48 +0200, Daniel Gustafsson wrote:

On 25 Aug 2020, at 12:20, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:

A user tried to use the cracklib build-time option of the passwordcheck module. This failed, as it turned out because there was no dictionary installed in the right place, but the error was not
properly reported, because the existing code just throws away the error message from cracklib. Attached is a patch that changes this by logging any error message returned from the cracklib call.

+1 on this, it's also in line with the example documentation from cracklib.
The returned error is potentially a bit misleading now, as it might say claim
that a strong password is easily cracked if the dictionary fails load. Given
that there is no way to distinguish between the class of returned errors it's
hard to see how we can do better though.

While poking at this, we might as well update the docs to point to the right
URL for CrackLib as it moved from Sourceforge five years ago. The attached
diff fixes that.

+1 on both patches.

Pushed both patches, thanks.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services