struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Gin" <Gin_C...@tvratings.com>
Subject RE: ClientSide Validation Javascript Password field
Date Wed, 13 Nov 2002 01:37:11 GMT
Following this.. then your validation shouldnt even have a max length.
You should allow unlimited length (albeit unpractical) and require:
min length > 3
at least 1 number/special char
case sensitivity.
or better yet.. dont add password validation and post what you just wrote on
the help. ;)
-Tim

-----Original Message-----
From: Mark Ayad [mailto:mark@javamark.com]
Sent: Tuesday, November 12, 2002 8:22 PM
To: Struts Users Mailing List
Subject: Re: ClientSide Validation Javascript Password field


However if you have a min of 10 and a max of 15 then you ensure a key of
length 10-15,

Thinking about it, unless you script alerts the hacker that the password
lenght min is 3 and max is 5 then there not much you can do. Its better to
put the limits higher such a min of 10 and a max of 15, and enforce upper /
lower [strong] .

Anyhow  slightly off-topic:

Key length

In general, the longer the key, the more reliable is the password. Having a
password with 2 characters is as good as using no password. Assuming that
the key space consists of only lowercase alphabets, there are only 26^2
combinations of possible passwords. Therefore, by increasing the number of
characters in a password, it becomes more secure.

Key space

While having a longer password improves security, the quantity of the
character set used is also important. A 10 characters password with its key
space consisting only of lowercase alphabets is less secure than a similar
length password with a key space consisting of both upper and lower case
alphabets.

Therefore, by improving the key space to that consisting of uppercase
alphabets, lowercase alphabets, numeric digits, punctuations and other
symbols, the security of the password increased. The number of possible
passwords is thus Keyspace^Keylength.

How do I make my password more secure?

In general, your password is effective if your make it more expensive in
terms of time and cost a hacker need to spend than the benefits obtainable
from breaking your password. This will definitely discourage attempts to
break your password. General suggestions for a good password are:

Longer length password with 8 or more characters.
Use a good mix of letters, numbers, punctuations and other symbols.
Use both upper and lower case letters.
Don't use popular names or words from any dictionary.
Change your password often and don't reuse old passwords.


Mark

----- Original Message -----
From: "Mark Ayad" <mark@javamark.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Sent: Wednesday, November 13, 2002 2:11 AM
Subject: Re: ClientSide Validation Javascript Password field


> Ahh but all it takes is for a crafty hacker to creating their record
you're
> just going to give him the min-max here. So infact you can't keep this a
> secret so whats the point then ?
>
> The problem is just a moving target is it not ?
>
> Mark
>
> ----- Original Message -----
> From: "Karr, David" <david.karr@attws.com>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> Sent: Wednesday, November 13, 2002 1:56 AM
> Subject: RE: ClientSide Validation Javascript Password field
>
>
> You don't do any formatting validation when they are attempting to
> authenticate, only when they are creating their record.  It's at that
point
> that you enforce password constraints, and you should do that on the
server
> side.
>
> > -----Original Message-----
> > From: Mark Ayad [mailto:mark@javamark.com]
> > Sent: Tuesday, November 12, 2002 4:56 PM
> > To: Struts Users Mailing List
> > Subject: Re: ClientSide Validation Javascript Password field
> >
> >
> > Martin
> >
> > That being said then the serverside validation shows you what
> > the clientside
> > doesn't
> >
> > But now there is a problem, if you're not validate on min /
> > max length for a
> > password field at all how are we going to enforce strong passwords ?
> >
> > Surely you have to define the keyspace somehow to enforce it ?
> >
> > Mark
> >
> >
> >
> > ----- Original Message -----
> > From: "Martin Cooper" <martinc@apache.org>
> > To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > Sent: Wednesday, November 13, 2002 1:34 AM
> > Subject: Re: ClientSide Validation Javascript Password field
> >
> >
> > >
> > >
> > > On Wed, 13 Nov 2002, Mark Ayad wrote:
> > >
> > > > Well is that expected behaviour is logical ??
> > >
> > > Yes. Did you read the explanation in the bug report I referenced?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > >
> > > > Enforcing length of a password field ?
> > > >
> > > > Or is it that this is best left to be serverside validation ?
> > > >
> > > > Mark
> > > >
> > > > ----- Original Message -----
> > > > From: "Martin Cooper" <martinc@apache.org>
> > > > To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > > > Sent: Wednesday, November 13, 2002 1:25 AM
> > > > Subject: Re: ClientSide Validation Javascript Password field
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Wed, 13 Nov 2002, Mark Ayad wrote:
> > > > >
> > > > > > I've noticed that the alertbox for clientside
> > validation of a simple
> > > > usename / password **never** shows alers for the password field.
> > > > > >
> > > > > > Is this a known issue, or expected behaviour ?
> > > > >
> > > > > It's expected behaviour. See:
> > > > >
> > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=12473
> > > > >
> > > > > --
> > > > > Martin Cooper
> > > > >
> > > > >
> > > > > >
> > > > > > Mark
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:struts-user-help@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message