# struts-user mailing list archives

##### Site index · List index
Message view
Top
From "Andreas Solarik" <a.sola...@gesig.at>
Subject AW: SV: Form Validation
Date Mon, 15 Mar 2004 14:13:49 GMT
```Hi guys!

Just something I believe to be true:

Aren't most systems compromised by incorrect configuration? I believe the
second most common weakness must be the postponement of patches to buggy
software -> see for example the whole alphabet of worms working their way
through IIS and Outlook Express... The problems have been addressed and
resolved by Microsoft, but many people fail to update their software.

Having an intruder launch a brute-force attack will only happen *if* you
keep your system current and locked down.

And Cristoph, I agree with you. I didn't doublecheck the numbers, but a
brute force attack only gains meaningfull information by knowing the *max*
string length, and by knowing of characters that are excluded from the
mystery string. And assuming that one authentication attempt takes 3
seconds, the average guessing time for the 4 letter password is roughly a
week...
And the solution space for the function increases exponentially with
increasing string lengths...

So, assuming that your passwords are not contained in a 'dictionary', and
assuming that your system is current, you have little to fear. You do check

Andreas

-----Ursprungliche Nachricht-----
Von: Christoph Kutzinski [mailto:kutzi@gmx.de]
Gesendet: Montag, 15. Marz 2004 14:48
An: Struts Users Mailing List
Betreff: Re: SV: Form Validation

Max Cooper wrote:

> If the hacker thinks that 7 character passwords may be allowed, they might
> waste a considerable amount of time trying all 1-to-7 character
> combinations. If you tell them the minimum is 8 chars, they can save a lot
> of time by not trying those shorter passwords.

I still can't see that the point here.
If we have say only 26 characters and a minimum password length of 4
characters:

You have 26^4 variations for 4-char passwords = 456976
The cracker would just save
26 + 26^2 + 26^3 = 18278 variations if he knows that the min length is
4. That is nothing in comparison to the variations for 4 character alone.

If we have more characters, the differences are even bigger.

> Also, if the minimum length is really long (>8 chars), the hacker might
> guess that most people will use a password of that minimum length, and
might
> start trying words that are that length since people would be likely to
> choose something like that to meet the length requirement while still
being
> memorable.
>
> However, if your app allows people to register online, the hacker can
> probably find out the minimum password length anyway, so validating for
min
> password length on the login page for that kind of app would have little
> (i.e. hacker is not smart enough to try to register first to find out the
> minimum password length from the registration form) to no security
> consequences.

Agreed.

Christoph

>
> -Max
>
> ----- Original Message -----
> From: "Christoph Kutzinski" <kutzi@gmx.de>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> Sent: Monday, March 15, 2004 5:06 AM
> Subject: Re: SV: Form Validation
>
>
>
>>Joe Hertz wrote:
>>
>>
>>>Check the Bugzilla. I believe it works in the <html:errors> tag, but you
>>>won't get a javascript popup.
>>>
>>>If memory serves, there's a security concern about using minlength in
>>>password fields -- basically the logic goes something like, "Do you
>
> really
>
>>>want to be providing a front end validation that tells a cracker how
>
> long his
>
>>>randomly guessed password attempts must be".
>>
>>What should be the problem with this?
>>You are only telling him, how long they must be AT LEAST. Nothing about
>>how long the can be at most.
>>If you would say, it can be dangerous to expose the maxlength of the
>>password to the user then I could understand it. Though lots of sites do
>>exactely this in reality, so it cannot be such a big security danger.
>>
>>greets,
>>Christoph
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org