struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Incze Lajos <in...@mail.matav.hu>
Subject Re: Automatic Form filing
Date Thu, 01 Feb 2001 02:32:10 GMT
On Wed, Jan 31, 2001 at 04:50:51PM -0800, Craig R. McClanahan wrote:
> Incze Lajos wrote:
> 
> > On Wed, Jan 31, 2001 at 01:55:46PM -0800, Joerg Beekmann wrote:
> > >
> > >
> > > > Is it really a security risk, though?  Remember that the
> > > > password displayed here
> > > > did *not* work (otherwise, the user would have been logged
> > > > in), so a potential
> > > > attacker is not learning anything new.  After all, they can
> > > > just try various
> > > > username and password combinations on your login screen, and
> > > > find out exactly the
> > > > same thing, even if the password text were not echoed.
> > > >
> > > I don't understand, seems to me the attacker is learning something.
> > > Two likely reasons for a failed login are:
> > > - simple typo; in this case trying a few variations or in many cases
> > > correcting the spelling will get the attacker in.
> > > - the user has multiple passwords and typed the wrong one. This
> > > might compromise other systems
> > >
> > > Joerg
> >
> > I fully understand to Joerg. Refrain the password (which can be seen
> > in hte HTML source view) is a bug.
> >
> > 1. As any sysadmin can tell you, users - if they can - will select
> >    meaningful passwords. I sight enough somtimes to know what the typo
> >    was, and what the real passowrd is.
> >
> > 2. Another issue is privacy. Users think what they type TOTALLY ENCRYPTED
> >    and you can get very inconvenient situations when something thought
> >    to be secret will be unveiled in clear text. So, it's simply HURTING
> >    A CONTRACT (that's why I'm calling it bug, not risk).
> >                                                                incze
> 
> These arguments make sense ... I just checked in a patch.
> 
> Note that doing this breaks a different contract ("all Struts form tags
> redisplay the previous values from the corresponding form bean property"),
> but in the case of conflicting goals security needs to win.
> 
> Craig
> 
I think not echoing the password is a better solution even in this respect.
You echo user input on purpose: she can see the value that was input by
her. But do you really give her this feedback in case of the password field?
Not, she can only see BULLETS, and the best she can do (if does not want to
mine after the error in the page source) to CLEAR ACTUALLY THE PASSWORD 
FIELD and retype the password. So, echoing back the wrong password is not
the same than echoing back a text input field. It is worse in the usability
or feedback point of view, also.                                    incze

Mime
View raw message