On 31/08/2015 20:28, George Sexton wrote:
>
>
> On 8/31/2015 8:54 AM, Christopher Schultz wrote:
>> You also tell them how long they have to wait before they can resume
>> their brute-force attack without wasting their own time.
>>> Must better to let a brute force attacker pound away at a locked
On 01/09/2015 08:11, Ognjen Blagojevic wrote:
> Mark,
>
> On 31.8.2015 12:42, Mark Thomas wrote:
>>> I experienced situations where the user calls the first level service
>>> desk and a ticket goes all its way to someone who can read the server
>>> logs and understand the issue... Not exactly opti
Mark,
On 31.8.2015 12:42, Mark Thomas wrote:
I experienced situations where the user calls the first level service desk and
a ticket goes all its way to someone who can read the server logs and
understand the issue... Not exactly optimal.
I agree. That is why most organisations provide self-
The points you raise are, of course real and important.
I would probably decide the same as you for a high profile, publicly available
application.
I however most often have to develop complex apps only used by, at most, 100s
of corporate users.
I know perimetric security is less and less fashi
On 8/31/2015 8:54 AM, Christopher Schultz wrote:
You also tell them how long they have to wait before they can resume
their brute-force attack without wasting their own time.
Must better to let a brute force attacker pound away at a locked
account wasting their resources and probably tripping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 8/31/15 6:42 AM, Mark Thomas wrote:
> On 31/08/2015 07:32, Ludovic Pénet wrote:
>> I can't see what would be the risks with being able to explain
>> "This account is locked for X minutes"...
>
> An attacker performing a brute force attack
On 31/08/2015 07:32, Ludovic Pénet wrote:
> I can't see what would be the risks with being able to explain "This account
> is locked for X minutes"...
An attacker performing a brute force attack has zero knowledge. They
have to guess both user names and passwords. Telling an attacker an
account i
I can't see what would be the risks with being able to explain "This account is
locked for X minutes"...
I experienced situations where the user calls the first level service desk and
a ticket goes all its way to someone who can read the server logs and
understand the issue... Not exactly opti
In your opinion would a security framework help in doing this ? Like Apache
Shiro ?
On Sun, Aug 30, 2015 at 9:51 PM, Mark Thomas wrote:
> On 29/08/2015 21:51, Sreyan Chakravarty wrote:
> > Is there any way I can tell the user that what number of login attempt he
> > is on ? While using the LockO
On 29/08/2015 21:51, Sreyan Chakravarty wrote:
> Is there any way I can tell the user that what number of login attempt he
> is on ? While using the LockOutRealm any way to display his login attempt
> on an html or jsp page ?
With the LockOutRealm as currently written, no.
If you extend it and wr
Is there any way I can tell the user that what number of login attempt he
is on ? While using the LockOutRealm any way to display his login attempt
on an html or jsp page ?
On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sreyan,
On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
> I am confused with the functioning of LockOutRealms in Tomcat.
>
> My questions are as follows-:
>
>
> 1. Say user at IP 10.10.10.1 has reached the maximum number of
> invalid login attempt
I am confused with the functioning of LockOutRealms in Tomcat.
My questions are as follows-:
1. Say user at IP 10.10.10.1 has reached the maximum number of invalid
login attempts and is locked out. Now say a user from 10.10.10.2 attempts
to login, will Tomcat stop him too since he is tr
13 matches
Mail list logo