Thread: Bug #6337 Patch

Hi Florian

Following are the review comments:

• The "MAX_LOGIN_ATTEMPTS" parameter is not present in the config.py. It should be there with some default value maybe 3.
• Can be added like

##########################################################################

# MAX_LOGIN_ATTEMPTS which sets the number of failed login attempts that

# are allowed. If this value is exceeded the account is locked and can be

# reset by an administrator. By setting the variable to the value zero

# this feature is deactivated.

##########################################################################

MAX_LOGIN_ATTEMPTS = 3

• I have tested by specifying the above value, and it seems the logic is not correct. I can perform N number of unsuccessful attempts and when I provided the correct password it shows the flash message "Account locked".
• Once the account is locked, the pgAdmin4 server needs to restart, can we make it time-bound? I mean after N minutes user can try again, so no need to restart the pgAdmin4 server. 

Hi

On Mon, Jul 19, 2021 at 1:22 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Florian

Following are the review comments:

• The "MAX_LOGIN_ATTEMPTS" parameter is not present in the config.py. It should be there with some default value maybe 3.
• Can be added like

##########################################################################

# MAX_LOGIN_ATTEMPTS which sets the number of failed login attempts that

# are allowed. If this value is exceeded the account is locked and can be

# reset by an administrator. By setting the variable to the value zero

# this feature is deactivated.

##########################################################################

MAX_LOGIN_ATTEMPTS = 3

• I have tested by specifying the above value, and it seems the logic is not correct. I can perform N number of unsuccessful attempts and when I provided the correct password it shows the flash message "Account locked".
• Once the account is locked, the pgAdmin4 server needs to restart, can we make it time-bound? I mean after N minutes user can try again, so no need to restart the pgAdmin4 server. 

Isn't the point that any admin can unlock the account from the user management dialog?

--

Dave Page

VP, Chief Architect, Database Infrastructure
Blog: https://www.enterprisedb.com/dave-page
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

Hi Florian

Thanks, the patch applied. 

I have changed the flash string from 'Account locked' to 'Your account is locked. Please contact the Administrator.'

On Wed, Jul 21, 2021 at 7:40 PM Florian Sabonchi <sabonchi@posteo.de> wrote:

Hello Akshay,

Thanks for your message, I have adjusted your suggestion as discussed. I
hope now that everything works correctly so far.

On 21.07.21 15:02, Akshay Joshi wrote:
>  The explanation that you have mentioned above is correct, but when I
> tested your patch and enter the wrong password N number of times, I
> haven't got the "Account locked" message. When I enter the correct
> password then I got that message which is wrong.

--

Thanks & Regards

Akshay Joshi

pgAdmin Hacker | Principal Software Architect

EDB Postgres

Mobile: +91 976-788-8246

On Thu, Jul 22, 2021 at 12:27 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Florian

Thanks, the patch applied. 

I have changed the flash string from 'Account locked' to 'Your account is locked. Please contact the Administrator.'

I have a scenario.

I have only one user in pgAdmin.

What would happen then?

+ Does it lock that user too?

+ If yes - do we have information in the document to unlock that user?

I am also curious about another case. A hacker can use multiple users for the same.

Should we also lock/avoid requests from a particular ip-address/machine for X minutes/hours?

Hello Dave,

As you said, it doesn't make sense to ban ip addresses. Alternatively, a
captcha could be implemented that prevents an attacker from trying to
bruteforce an account.

On 22.07.21 10:31, Dave Page wrote:
> That's more difficult to deal with - there are common deployment
> scenarios where all connections might appear to come from a single IP,
> for example, when behind a load balancer (there are good reasons to do
> that, even with a single pgAdmin instance) or proxy. In such cases we
> may or may not get an X-Forwarded-For header, and even if we do it may
> not be reliable.

On Thu, Jul 22, 2021 at 9:19 AM Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Thu, Jul 22, 2021 at 12:27 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Florian

Thanks, the patch applied. 

I have changed the flash string from 'Account locked' to 'Your account is locked. Please contact the Administrator.'

I have a scenario.

I have only one user in pgAdmin.

What would happen then?

+ Does it lock that user too?

Yes.

 

+ If yes - do we have information in the document to unlock that user?

I hope so :-p

 

I am also curious about another case. A hacker can use multiple users for the same.

Should we also lock/avoid requests from a particular ip-address/machine for X minutes/hours?

That's more difficult to deal with - there are common deployment scenarios where all connections might appear to come from a single IP, for example, when behind a load balancer (there are good reasons to do that, even with a single pgAdmin instance) or proxy. In such cases we may or may not get an X-Forwarded-For header, and even if we do it may not be reliable.

 

--

Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, Jul 22, 2021 at 2:01 PM Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jul 22, 2021 at 9:19 AM Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Thu, Jul 22, 2021 at 12:27 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Florian

Thanks, the patch applied. 

I have changed the flash string from 'Account locked' to 'Your account is locked. Please contact the Administrator.'

I have a scenario.

I have only one user in pgAdmin.

What would happen then?

+ Does it lock that user too?

Yes.

 

+ If yes - do we have information in the document to unlock that user?

I hope so :-p

Akshay?

-- Ashesh 

 

I am also curious about another case. A hacker can use multiple users for the same.

Should we also lock/avoid requests from a particular ip-address/machine for X minutes/hours?

That's more difficult to deal with - there are common deployment scenarios where all connections might appear to come from a single IP, for example, when behind a load balancer (there are good reasons to do that, even with a single pgAdmin instance) or proxy. In such cases we may or may not get an X-Forwarded-For header, and even if we do it may not be reliable.

 

--

Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com