On 11/1/17, 9:33 PM, "Peter Eisentraut"
wrote:
> On 9/25/17 14:04, Bossart, Nathan wrote:
>> I'd like to use this thread to gauge community interest in adding this
>> functionality to this module. If there is interest, I'll add it to the next
>> commitfest.
>
> This thread has no patch, which is
On 9/25/17 14:04, Bossart, Nathan wrote:
> I'd like to use this thread to gauge community interest in adding this
> functionality to this module. If there is interest, I'll add it to the next
> commitfest.
This thread has no patch, which is not really the intended use of the
commit fest, so I'm c
On Fri, Sep 29, 2017 at 3:17 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
> > Client commands may be run on a trusted network as well, let's not
> > forget that.
>
> I've never seen this "trusted network" thing of which you speak. Is it
> nice?
>
I believe it's usually referred to as "l
Michael Paquier wrote:
> Client commands may be run on a trusted network as well, let's not
> forget that.
I've never seen this "trusted network" thing of which you speak. Is it
nice?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
Michael Paquier wrote:
> On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera
> wrote:
>> I think the passwordcheck module as a whole is a dead end, security-
>> wise. Myself, I've never seen the point in it. It runs at the wrong
>> time, and there's no way to fix that.
>
> Client commands may be
On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera
wrote:
> I think a password strength check must live at the end that does the
> encryption -- something like in psql when you do the \password command,
> *before* the encrypted password is sent to the server. Then you can do
> all sort of stuff (..
Bossart, Nathan wrote:
> On 9/27/17, 7:41 AM, "Peter Eisentraut"
> wrote:
> > On 9/25/17 23:10, Bossart, Nathan wrote:
> >> One interesting design challenge will be how to handle pre-hashed
> >> passwords, since the number of checks we can do on those is pretty
> >> limited. I'm currently thinki
On 9/27/17, 7:41 AM, "Peter Eisentraut"
wrote:
> On 9/25/17 23:10, Bossart, Nathan wrote:
>> One interesting design challenge will be how to handle pre-hashed
>> passwords, since the number of checks we can do on those is pretty
>> limited. I'm currently thinking of a parameter that can be used
On 9/25/17 23:10, Bossart, Nathan wrote:
> One interesting design challenge will be how to handle pre-hashed
> passwords, since the number of checks we can do on those is pretty
> limited. I'm currently thinking of a parameter that can be used to
> block, allow, or force pre-hashed passwords.
Pre
On Wed, Sep 27, 2017 at 6:05 PM, Albe Laurenz wrote:
> I had the impression that the reasons why database passwords are
> not the best option for high security were:
> 1) The password hash is stored in the database and can be stolen and
>cracked (don't know if dictionary attacks are harder wit
Nathan Bossart wrote:
>> As was pointed out in the original discussion
>> d960cb61b694cf459dcfb4b0128514c203937...@exadv11.host.magwien.gv.at
>> the weak point of "passwordcheck" is that it does not work very well
>> for encrypted passwords.
>> The only saving grace is that you can at least check a
On 9/26/17, 2:38 AM, "Albe Laurenz" wrote:
> Nathan Bossart wrote:
passwordcheck.force_new_password
>>> Does it mean a password different from the old one? +1. It could be
>>> different from the last 3 passwords but we don't store a password
>>> history.
>>
>> Yes. As Michael p
Nathan Bossart wrote:
>>> passwordcheck.force_new_password
>>>
>> Does it mean a password different from the old one? +1. It could be
>> different from the last 3 passwords but we don't store a password
>> history.
>
> Yes. As Michael pointed out, this might be better to do as a separate
On 9/25/17, 8:31 PM, "Michael Paquier" wrote:
> Yes, I have developped a couple of years back a fork of passwordcheck
> which had much similar enhancements, so getting something more modular
> in upstream would be really welcome.
Awesome.
> On top of that I think that you should have a parameter
2017-09-25 15:04 GMT-03:00 Bossart, Nathan :
> Currently, the passwordcheck module provides a few basic checks to strengthen
> passwords. However, any configuration must be ready at compile time, and many
> common password requirements cannot be enforced without creating a custom
> version of this
On Tue, Sep 26, 2017 at 3:04 AM, Bossart, Nathan wrote:
> Currently, the passwordcheck module provides a few basic checks to strengthen
> passwords. However, any configuration must be ready at compile time, and many
> common password requirements cannot be enforced without creating a custom
> ver
Hi hackers,
Currently, the passwordcheck module provides a few basic checks to strengthen
passwords. However, any configuration must be ready at compile time, and many
common password requirements cannot be enforced without creating a custom
version of this module. I think there are a number of
17 matches
Mail list logo
