You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by rl...@apache.org on 2003/10/07 05:00:15 UTC
cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
rleland 2003/10/06 20:00:15
Modified: validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision Changes Path
1.3 +4 -3 jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Index: validateMaxLength.js
===================================================================
RCS file: /home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js 15 Aug 2003 20:22:03 -0000 1.2
+++ validateMaxLength.js 7 Oct 2003 03:00:15 -0000 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+ field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2]("maxlength"));
1.4 +4 -3 jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
Index: validateMinLength.js
===================================================================
RCS file: /home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js 15 Aug 2003 20:22:03 -0000 1.3
+++ validateMinLength.js 7 Oct 2003 03:00:15 -0000 1.4
@@ -13,6 +13,7 @@
var field = form[oMinLength[x][0]];
if (field.type == 'text' ||
+ field.type == 'password' ||
field.type == 'textarea') {
var iMin = parseInt(oMinLength[x][2]("minlength"));
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by Phil Steitz <ph...@steitz.com>.
FWIW, I agree with David.
I am neither a security expert nor a Validator committer, so please
accept this as just a comment. If client-visible javascript containing
password validation info is included in authentication pages (even just
max -- should *never* exist -- or min lengths) this can give an
advantage to hackers attempting dictionary attacks or using known info
about users (e.g. initials, birthdates, last 4 digits of SSN, other
short stupid stuff etc.) to hack into accounts on a system that has this
exposure. Any information that reduces the size of the valid password
search space gives an advantage to a hacker -- especically one who may
have info about the user whose account s/he is trying to break into.
Min length info *may* need to be communicated to users at enrollment
time (when passwords are created, if they are created by users online);
but it should *not* be made available to them on authentication pages or
in the error messages that they generate on authentication failure.
As I said above, this is just my HO, but I would not recommend enabling
this feature in Validator, since it could lead to developers unwittingly
introducing security exposure into their code. I think we should always
err on the side of conservatism when it comes to security issues and try
not to leave too much choice to developers, who may misunderstand the
docs or just make mistakes, resulting in exposure.
Phil
Robert Leland wrote:
> David Graham wrote:
>
>> My point is not that you shouldn't tell your users the rules; it's that
>> you shouldn't expose the validation algorithm to hackers. The less they
>> know about the password system, the better.
>>
>> David
>>
> That's Microsofts method security by obsecurity. We all know how well
> that works !
>
> I have been searching for articles saying that knowing
> minimum/maximum password lengths poses a security risk. I have not found
> such an article/blurb,
> either for or against. And it is impossible to not tell the user what
> the min/max's are in a usable system.
> The only place where min/max lengths helps out a little, very little, is
> in programs like jack the ripper, and this
> occures once the password file has been copied off the machine to
> another to be cracked.
>
> I also asked my co-worker who lives, and breathes cryptology and runs
> a respected crypto news site,
> and he said it isn't an issue. The only comment he made is that there
> should not be maximum limits.
> (he probably also would like a 15 digit zip code ;) )!
>
> I am trying to base decisions on facts, not FUD, and I see no references
> that would support a -1,
> I invite you to google for over an hour like I did.
>
> -Rob
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> David Graham wrote:
>
> >My point is not that you shouldn't tell your users the rules; it's that
> >you shouldn't expose the validation algorithm to hackers. The less
> they
> >know about the password system, the better.
> >
> >David
> >
> That's Microsofts method security by obsecurity. We all know how well
> that works !
>
> I have been searching for articles saying that knowing
> minimum/maximum password lengths poses a security risk. I have not found
>
> such an article/blurb,
> either for or against. And it is impossible to not tell the user what
> the min/max's are in a usable system.
> The only place where min/max lengths helps out a little, very little, is
>
> in programs like jack the ripper, and this
> occures once the password file has been copied off the machine to
> another to be cracked.
>
> I also asked my co-worker who lives, and breathes cryptology and runs
> a respected crypto news site,
> and he said it isn't an issue. The only comment he made is that there
> should not be maximum limits.
> (he probably also would like a 15 digit zip code ;) )!
>
> I am trying to base decisions on facts, not FUD, and I see no references
>
> that would support a -1,
> I invite you to google for over an hour like I did.
That's not how a veto works. We don't need a list of internet references
to support a -1. I believe exposing any details about password validation
implementation is a security flaw, no matter how small. Revealing min/max
lengths is a relatively minor issue but violates that general principle.
The implication that I support MS' security model or am trying to spread
FUD isn't fair. I'm trying to do the right thing and ship Validator that
complies with the Apache way of doing things.
If my reasons don't support a -1, so be it. I don't have the time nor
energy to continue debating this.
David
>
> -Rob
>
>
>
>
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>My point is not that you shouldn't tell your users the rules; it's that
>you shouldn't expose the validation algorithm to hackers. The less they
>know about the password system, the better.
>
>David
>
That's Microsofts method security by obsecurity. We all know how well
that works !
I have been searching for articles saying that knowing
minimum/maximum password lengths poses a security risk. I have not found
such an article/blurb,
either for or against. And it is impossible to not tell the user what
the min/max's are in a usable system.
The only place where min/max lengths helps out a little, very little, is
in programs like jack the ripper, and this
occures once the password file has been copied off the machine to
another to be cracked.
I also asked my co-worker who lives, and breathes cryptology and runs
a respected crypto news site,
and he said it isn't an issue. The only comment he made is that there
should not be maximum limits.
(he probably also would like a 15 digit zip code ;) )!
I am trying to base decisions on facts, not FUD, and I see no references
that would support a -1,
I invite you to google for over an hour like I did.
-Rob
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by David Graham <gr...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> Robert Leland wrote:
>
> > David Graham wrote:
> >
> >> The validation rules are only exposed if you use Struts'
> >> <html:javascript>
> >>
> >>
> > Not true they are exposed by server side validation also. The error
> > messages clearly state the min/max
> > values.
>
> But even that is only exposed if you use the validator framework's
> minLength checks. If I didn't want to expose the fact that I cared
> about such things, I'd use two different validation mechanisms:
>
> * On the login screen, I'd use nothing except (perhaps) a "required"
> validation.
>
> * On the admin screen that lets me change my own password, I'd write a
> custom validator
> method + appropriate JavaScript -- or, more likely, implemented this
> as a server side check
> that approved a proposed password (minimum length, appropriate mixture
>
> of letters and
> digits, not in a dictionary, ...) without exposing *anything* about
> why a password might
> get rejected.
>
> Of course, there's a usability issue here, too ... if you impose
> particular rules for passwords in the code but don't tell your users
> about what the rules are, you're bound to frustrate them when they try
> to set their own passwords to a new value, but don't know why you're not
>
> allowing the proposed value.
>
> Anyone who objects to exposing a "minimum password length" rule to the
> general public shoudn't be employing such a validation rule on their
> login screens in the first place.
My point is not that you shouldn't tell your users the rules; it's that
you shouldn't expose the validation algorithm to hackers. The less they
know about the password system, the better.
David
>
> >
> >>
> >> I'm still -1 on this last commit for the reasons stated. Please
> revert
> >> this change to not validate password fields in the javascript.
> >>
> >>
> >>
> > +1, will do it tomorrow.
>
>
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Robert Leland wrote:
> David Graham wrote:
>
>> The validation rules are only exposed if you use Struts'
>> <html:javascript>
>>
>>
> Not true they are exposed by server side validation also. The error
> messages clearly state the min/max
> values.
But even that is only exposed if you use the validator framework's
minLength checks. If I didn't want to expose the fact that I cared
about such things, I'd use two different validation mechanisms:
* On the login screen, I'd use nothing except (perhaps) a "required"
validation.
* On the admin screen that lets me change my own password, I'd write a
custom validator
method + appropriate JavaScript -- or, more likely, implemented this
as a server side check
that approved a proposed password (minimum length, appropriate mixture
of letters and
digits, not in a dictionary, ...) without exposing *anything* about
why a password might
get rejected.
Of course, there's a usability issue here, too ... if you impose
particular rules for passwords in the code but don't tell your users
about what the rules are, you're bound to frustrate them when they try
to set their own passwords to a new value, but don't know why you're not
allowing the proposed value.
Anyone who objects to exposing a "minimum password length" rule to the
general public shoudn't be employing such a validation rule on their
login screens in the first place.
>
>>
>> I'm still -1 on this last commit for the reasons stated. Please revert
>> this change to not validate password fields in the javascript.
>>
>>
>>
> +1, will do it tomorrow.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> David Graham wrote:
>
> >The validation rules are only exposed if you use Struts'
> <html:javascript>
> >
> >
> Not true they are exposed by server side validation also. The error
> messages clearly state the min/max
> values.
But those error messages are easily replaced, either globally or on the
field level so the server side checks can still be hidden.
David
>
> >
> >I'm still -1 on this last commit for the reasons stated. Please revert
> >this change to not validate password fields in the javascript.
> >
> >
> >
> +1, will do it tomorrow.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>The validation rules are only exposed if you use Struts' <html:javascript>
>
>
Not true they are exposed by server side validation also. The error
messages clearly state the min/max
values.
>
>I'm still -1 on this last commit for the reasons stated. Please revert
>this change to not validate password fields in the javascript.
>
>
>
+1, will do it tomorrow.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> David Graham wrote:
>
> >It is inherently insecure to reveal the specific details of password
> >validation in client side scripting. Validator and Struts should be as
> >secure as possible out of the box so I am -1 on this change. Please
> >revert the changes until we come up with a better solution. Bugzilla
> >isn't the easiest place to have this discussion so it might be better
> >suited for commons-dev.
> >
> >I thought that the length was only revealed in the error message but it
> is
> >indeed shown in snippets like:
> >this.maxlength='4'; this.minlength='4';
> >
> >I agree that the best solution at the moment is not to use validator on
> >password forms.
> >
> >David
> >
> >
> Also the server side validations reveal max/min lengths, there.
> Currently, the validator server side
> validations are loosely coupled. A solution would be to prevent the user
>
> from using max/min length
> checks either client or server side would increase coupling. One
> possible attempt to solve this
> by placing an optional attribute for the user to tell us that the field
> is
> a password so we could disallow maxlength or minlength would not work
> because they would just
> not mark the field as a 'password'.
>
> A proactive step might be to have the generated javascript create a
> dialog if the field is a
> 'password' field and it attempts to validate a max/minlength constraint.
>
> It would warn them that
> validating max/min fields is discouraged. A client side validation would
>
> be allowed by setting parameter
> in the <html:javascript> tag. This would catch both client side and
> server side cases, given that javascript
> is enabled.
>
> Generally though I believe it would be cleanest if the commons-validator
>
> didn't dictate what field types
> could/could not be validated. This decision could be left up to the
> enclosing framework, as I described
> above.
Validator won't be dictating anything; it just won't validate password
fields on the client side out of the box. Indeed, the options you mention
above would be dictating behavior to the client.
As we can see from the change you committed, adding password field
checking is trivial. It should be the developer's conscious decision to
patch the code and reveal password rules to the client, not Validator's.
Quoting from http://jakarta.apache.org/site/mission.html part of every
Apache project is, "security as a mandatory feature". We would violate
this principal if we reveal password validation rules on the client side.
The validation rules are only exposed if you use Struts' <html:javascript>
tag on the form. You can still use Validator for password fields if you
don't include javascript validation and use only server side checks. A
warning in the Struts user's guide may be the best we can do because
Validator has no real way of knowing what fields are passwords.
I'm still -1 on this last commit for the reasons stated. Please revert
this change to not validate password fields in the javascript.
David
>
> >--- rleland@apache.org wrote:
> >
> >
> >>rleland 2003/10/06 20:00:15
> >>
> >> Modified:
> >>validator/src/javascript/org/apache/commons/validator/javascript
> >> validateMaxLength.js validateMinLength.js
> >> Log:
> >> Bug#: 12473
> >> Let max/min length also cover passwords fields.
> >> If users don't want the password min/max parameters
> >> revealed then they shouldn't use the validator.
> >> Currently in struts the min/max values are still
> >> in the html, anyway. There is no easy/clean workaround.
> >>
> >> Just don't use validator.
> >>
> >> Revision Changes Path
> >> 1.3 +4 -3
> >>
> >>
> >>
>
>jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
> >
> >
> >>
> >> Index: validateMaxLength.js
> >> ===================================================================
> >> RCS file:
> >>
> >>
> >>
>
>/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
> >
> >
> >> retrieving revision 1.2
> >> retrieving revision 1.3
> >> diff -u -r1.2 -r1.3
> >> --- validateMaxLength.js 15 Aug 2003 20:22:03 -0000 1.2
> >> +++ validateMaxLength.js 7 Oct 2003 03:00:15 -0000 1.3
> >> @@ -13,6 +13,7 @@
> >> var field = form[oMaxLength[x][0]];
> >>
> >> if (field.type == 'text' ||
> >> + field.type == 'password' ||
> >> field.type == 'textarea') {
> >>
> >> var iMax = parseInt(oMaxLength[x][2]("maxlength"));
> >>
> >>
> >>
> >> 1.4 +4 -3
> >>
> >>
> >>
>
>jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
> >
> >
> >>
> >> Index: validateMinLength.js
> >> ===================================================================
> >> RCS file:
> >>
> >>
> >>
>
>/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
> >
> >
> >> retrieving revision 1.3
> >> retrieving revision 1.4
> >> diff -u -r1.3 -r1.4
> >> --- validateMinLength.js 15 Aug 2003 20:22:03 -0000 1.3
> >> +++ validateMinLength.js 7 Oct 2003 03:00:15 -0000 1.4
> >> @@ -13,6 +13,7 @@
> >> var field = form[oMinLength[x][0]];
> >>
> >> if (field.type == 'text' ||
> >> + field.type == 'password' ||
> >> field.type == 'textarea') {
> >>
> >> var iMin = parseInt(oMinLength[x][2]("minlength"));
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >The New Yahoo! Shopping - with improved product search
> >http://shopping.yahoo.com
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>It is inherently insecure to reveal the specific details of password
>validation in client side scripting. Validator and Struts should be as
>secure as possible out of the box so I am -1 on this change. Please
>revert the changes until we come up with a better solution. Bugzilla
>isn't the easiest place to have this discussion so it might be better
>suited for commons-dev.
>
>I thought that the length was only revealed in the error message but it is
>indeed shown in snippets like:
>this.maxlength='4'; this.minlength='4';
>
>I agree that the best solution at the moment is not to use validator on
>password forms.
>
>David
>
>
Also the server side validations reveal max/min lengths, there.
Currently, the validator server side
validations are loosely coupled. A solution would be to prevent the user
from using max/min length
checks either client or server side would increase coupling. One
possible attempt to solve this
by placing an optional attribute for the user to tell us that the field is
a password so we could disallow maxlength or minlength would not work
because they would just
not mark the field as a 'password'.
A proactive step might be to have the generated javascript create a
dialog if the field is a
'password' field and it attempts to validate a max/minlength constraint.
It would warn them that
validating max/min fields is discouraged. A client side validation would
be allowed by setting parameter
in the <html:javascript> tag. This would catch both client side and
server side cases, given that javascript
is enabled.
Generally though I believe it would be cleanest if the commons-validator
didn't dictate what field types
could/could not be validated. This decision could be left up to the
enclosing framework, as I described
above.
>--- rleland@apache.org wrote:
>
>
>>rleland 2003/10/06 20:00:15
>>
>> Modified:
>>validator/src/javascript/org/apache/commons/validator/javascript
>> validateMaxLength.js validateMinLength.js
>> Log:
>> Bug#: 12473
>> Let max/min length also cover passwords fields.
>> If users don't want the password min/max parameters
>> revealed then they shouldn't use the validator.
>> Currently in struts the min/max values are still
>> in the html, anyway. There is no easy/clean workaround.
>>
>> Just don't use validator.
>>
>> Revision Changes Path
>> 1.3 +4 -3
>>
>>
>>
>jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
>
>
>>
>> Index: validateMaxLength.js
>> ===================================================================
>> RCS file:
>>
>>
>>
>/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
>
>
>> retrieving revision 1.2
>> retrieving revision 1.3
>> diff -u -r1.2 -r1.3
>> --- validateMaxLength.js 15 Aug 2003 20:22:03 -0000 1.2
>> +++ validateMaxLength.js 7 Oct 2003 03:00:15 -0000 1.3
>> @@ -13,6 +13,7 @@
>> var field = form[oMaxLength[x][0]];
>>
>> if (field.type == 'text' ||
>> + field.type == 'password' ||
>> field.type == 'textarea') {
>>
>> var iMax = parseInt(oMaxLength[x][2]("maxlength"));
>>
>>
>>
>> 1.4 +4 -3
>>
>>
>>
>jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
>
>
>>
>> Index: validateMinLength.js
>> ===================================================================
>> RCS file:
>>
>>
>>
>/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
>
>
>> retrieving revision 1.3
>> retrieving revision 1.4
>> diff -u -r1.3 -r1.4
>> --- validateMinLength.js 15 Aug 2003 20:22:03 -0000 1.3
>> +++ validateMinLength.js 7 Oct 2003 03:00:15 -0000 1.4
>> @@ -13,6 +13,7 @@
>> var field = form[oMinLength[x][0]];
>>
>> if (field.type == 'text' ||
>> + field.type == 'password' ||
>> field.type == 'textarea') {
>>
>> var iMin = parseInt(oMinLength[x][2]("minlength"));
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Shopping - with improved product search
>http://shopping.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
[validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Posted by David Graham <gr...@yahoo.com>.
It is inherently insecure to reveal the specific details of password
validation in client side scripting. Validator and Struts should be as
secure as possible out of the box so I am -1 on this change. Please
revert the changes until we come up with a better solution. Bugzilla
isn't the easiest place to have this discussion so it might be better
suited for commons-dev.
I thought that the length was only revealed in the error message but it is
indeed shown in snippets like:
this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on
password forms.
David
--- rleland@apache.org wrote:
> rleland 2003/10/06 20:00:15
>
> Modified:
> validator/src/javascript/org/apache/commons/validator/javascript
> validateMaxLength.js validateMinLength.js
> Log:
> Bug#: 12473
> Let max/min length also cover passwords fields.
> If users don't want the password min/max parameters
> revealed then they shouldn't use the validator.
> Currently in struts the min/max values are still
> in the html, anyway. There is no easy/clean workaround.
>
> Just don't use validator.
>
> Revision Changes Path
> 1.3 +4 -3
>
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
>
> Index: validateMaxLength.js
> ===================================================================
> RCS file:
>
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- validateMaxLength.js 15 Aug 2003 20:22:03 -0000 1.2
> +++ validateMaxLength.js 7 Oct 2003 03:00:15 -0000 1.3
> @@ -13,6 +13,7 @@
> var field = form[oMaxLength[x][0]];
>
> if (field.type == 'text' ||
> + field.type == 'password' ||
> field.type == 'textarea') {
>
> var iMax = parseInt(oMaxLength[x][2]("maxlength"));
>
>
>
> 1.4 +4 -3
>
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
>
> Index: validateMinLength.js
> ===================================================================
> RCS file:
>
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- validateMinLength.js 15 Aug 2003 20:22:03 -0000 1.3
> +++ validateMinLength.js 7 Oct 2003 03:00:15 -0000 1.4
> @@ -13,6 +13,7 @@
> var field = form[oMinLength[x][0]];
>
> if (field.type == 'text' ||
> + field.type == 'password' ||
> field.type == 'textarea') {
>
> var iMin = parseInt(oMinLength[x][2]("minlength"));
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org