Saving the credentials by browser on login page

John Mazzitelli mazz at redhat.com
Tue Sep 25 15:11:41 UTC 2012


IMO, just publish the grease monkey script and be done with it.

----- Original Message -----
> I was under the impression that we had already decided that this was
> a risky proposition? Typically, something like this would get
> flagged in a code audit (manual or automated). The thing with
> security is that you may not fully understand what you are exposing
> as dangerous until you get hacked.   As JON can control other
> servers it could quickly become a severe issue for a customer. Once
> a product gets tainted by a serious security issue it is very hard
> to recover from that kind of publicity.
> 
> Is there a Red Hat security team that can advise on this? Perhaps
> standard practices...
> 
> 
> -- Mike
> 
> On Sep 25, 2012, at 6:59 AM, Jiri Kremser <jkremser at redhat.com>
> wrote:
> 
> > Hi,
> >  I've implemented the issue using the hidden form hack. I've found
> >  only one example of this on the web
> >  (http://borglin.net/gwt-project/?page_id=467, great blog btw.).
> >  However, the example doesn't use the SmartGWT but pure GWT. They
> >  actually use directly the hidden form for logging in by calling
> >  FormPanel.wrap(Document.get().getElementById(LOGINFORM_ID)) and
> >  rendering it. It wraps an existing element with pure GWT
> >  component. SmartGWT, unfortunately, doesn't support such
> >  functionality (I tried smartclient forum, stackoverflow and
> >  JavaDoc :]), so I had to "mirror" the values between the two
> >  forms (the hidden one and the SmartGWT one), and when submitting
> >  the visible form, the submit is invoked on the hidden form too
> >  which calls JSNI method for logging in.
> > 
> > It works without problems in Chrome21 and IE8. FF 10 asks for
> > saving the credentials, but fills it only if the user access the
> > page by pressing the logout (=> don't fill it if you access the
> > page directly, strange).
> > 
> > The changes are pushed in git branch jkremser/loginSaving
> > 
> > Concerning security:
> > * I had to expose the "doLogin()" function via JSNI in order to be
> > able to call it from Java Script. doLogin() reads the credentials
> > from the hidden form and with them performs the login(user,pass)
> > and subsequently sends POST to portal's struts action
> > (j_security_check.do). The only risk, I can see, is that attacker
> > can make the hidden form visible and type the credentials directly
> > to it (or from JavaScript) bypassing the form validation on the
> > proper login form. However, right now we validate only if the
> > username and password is not "".
> > 
> > * Credentials are NOT stored by the application logic. Browser asks
> > the user and stores it if he/she confirms, like many other web
> > application. Here, one can say, it is not a good practice and we
> > should avoid it. We can discuss it. It depends, If the online
> > banking app suggests me saving the password I would probably
> > change the bank. I am not saying RHQ is not so critical (it may be
> > in many cases), but don't forget it is only option. User can turn
> > it off or use it, it is up to him. Same thing holds for securing
> > the webapp with SSL + certificate. Because without running it on
> > SSL it is quite funny to talk about security aspects, and send the
> > password in plain text :]
> > 
> > * Other risk may come from the fact the login form (the hidden
> > variant) is now present in the static html content, so if the
> > webapp is hosted on public IP, some crawler or bot can potentially
> > mark this page as hackable. Counterargument could be that the same
> > thing is possible now after evaluating the JavaScript.
> > 
> > 
> > I've also prepared the Grease Monkey script for FF and placed it to
> > /etc/dev-utils. It fills the credentials if you press alt+c and it
> > works well also in Chrome with Tampermonkey add-on. I haven't
> > tried it with the IE yet.
> > 
> > JK
> > 
> > 
> > ----- Original Message -----
> > From: "Stefan Negrea" <snegrea at redhat.com>
> > To: rhq-devel at lists.fedorahosted.org
> > Sent: Wednesday, September 5, 2012 9:27:28 PM
> > Subject: Re: Saving the credentials by browser on login page
> > 
> > Hello,
> > 
> > 
> > This is a known issue with GWT applications and the fix is simple.
> > This section explains well the strategy:
> > http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ#auto-complete_and_GWT
> > 
> > 
> > Storing passwords or usernames in cookies is dangerous!
> > 
> > 
> > Thank you,
> > Stefan
> > 
> > ----- Original Message -----
> >> From: "Lukas Krejci" <lkrejci at redhat.com>
> >> To: rhq-devel at lists.fedorahosted.org
> >> Sent: Friday, August 31, 2012 8:16:53 AM
> >> Subject: Re: Saving the credentials by browser on login page
> >> 
> >> On Friday, August 31, 2012 09:03:58 John Mazzitelli wrote:
> >>> I would disagree that it is a "rather big" usability issue.
> >>> Relative to all
> >>> the other issues in the UI, I would put this low on the list.
> >>> 
> >> 
> >> Well, this one is right in the face of everybody using RHQ. It's
> >> the
> >> first
> >> thing they see and there's no going around that.
> >> Something along the lines of "they can't get right even such a
> >> simple
> >> thing as
> >> password completion? They suck!"
> >> 
> >>> I would agree that if some solution can simply enable the browser
> >>> to do "its
> >>> thing", that would be nice. But I heard things like "storing the
> >>> password
> >>> in a cookie" and things like that - that's what I say we should
> >>> not
> >>> even
> >>> entertain the thought.
> >> 
> >> +100
> >> 
> >>> If there is some magic to put some hidden dummy form
> >>> in the page to trick the browser to remember the info using its
> >>> normal
> >>> mechanisms, then that would be different.
> >>> 
> >> 
> >> I actually thought this was the plan.
> >> 
> >>> But again, relative to everything else, this would be low on the
> >>> list to
> >>> implement IMO as we've got lots of other stuff that would be
> >>> higher
> >>> priority (is there even a BZ on this?). As Jiri mentioned
> >>> earlier,
> >>> for
> >>> devs, it would probably be nice to have some a greasemonkey
> >>> script
> >>> to help
> >>> out here. That would be a good solution for devs whose fingers
> >>> hurt
> >>> typing
> >>> rhqadmin :}
> >>> 
> >>> ----- Original Message -----
> >>> 
> >>>> Well, this whole thing is not about us implementing some
> >>>> convenience
> >>>> for the users but about us NOT PREVENTING a convenience function
> >>>> that browsers implement.
> >>>> 
> >>>> I see a big difference there. It is a standard feature of all
> >>>> browsers to offer to "save passwords" on any page where people
> >>>> put
> >>>> in credentials. This is not possible on RHQ login page. It is
> >>>> not
> >>>> for us to answer the security aspects of this solution or to try
> >>>> to
> >>>> be "smarter" than the browsers are.
> >>>> 
> >>>> For me this is a rather big usability issue.
> >>>> 
> >>>> Lukas
> >>>> 
> >>>> ----- Original Message -----
> >>>> 
> >>>>> From: "John Mazzitelli" <mazz at redhat.com>
> >>>>> To: rhq-devel at lists.fedorahosted.org
> >>>>> Sent: Thursday, August 30, 2012 6:16:55 PM
> >>>>> Subject: Re: Saving the credentials by browser on login page
> >>>>> 
> >>>>> IMO, I would recommend staying far away from doing anything
> >>>>> "for
> >>>>> convenience" that has anything to do with security. This is
> >>>>> asking
> >>>>> for trouble.
> >>>>> 
> >>>>> It is best if something like "my password was hacked" can be
> >>>>> 100%
> >>>>> blamed on, say, the browser or a weak password (as opposed to
> >>>>> it
> >>>>> being blamed on RHQ :-)
> >>>>> 
> >>>>> Seriously, the minute you start attempting to implement
> >>>>> something
> >>>>> around security like this, you WILL get people looking very
> >>>>> closely
> >>>>> at your code and dollars to donuts, some hole some where will
> >>>>> be
> >>>>> found (which I can attest to with the "convenience" feature we
> >>>>> had
> >>>>> for the agent token stuff a while ago that we ended up
> >>>>> removing).
> >>>>> 
> >>>>> As the guy on that old TV cop show used to say, "Let's be
> >>>>> careful
> >>>>> out
> >>>>> there!"
> >>>>> 
> >>>>> P.S. Your fingers learn to type "rhqadmin" really fast after
> >>>>> you do
> >>>>> it for a while. :)
> >>>>> 
> >>>>> ----- Original Message -----
> >>>>> 
> >>>>>> IMO storing the password is a poor choice (even if done
> >>>>>> properly)
> >>>>>> and
> >>>>>> may not be welcomed as a feature by some organizations.
> >>>>>> However,
> >>>>>> storing the user name might be nice but even that should not
> >>>>>> be
> >>>>>> in
> >>>>>> plain text. Here is another link to complement the link
> >>>>>> below:
> >>>>>> http://crackstation.net/hashing-security.htm
> >>>>>> 
> >>>>>> 
> >>>>>> Obviously this is a sensitive area.
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> HTML5 local storage is another option to cookies. Cookies get
> >>>>>> sent
> >>>>>> with every request including images and gwt-rpc. This way the
> >>>>>> username would never leave the client (except for the actual
> >>>>>> login).
> >>>>>> FF and IE9 have support for it and there is a polyfill for
> >>>>>> web
> >>>>>> storage in IE8.
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On Aug 30, 2012, at 7:36 AM, Jiri Kremser <
> >>>>>> jkremser at redhat.com >
> >>>>>> wrote:
> >>>>>> 
> >>>>>> 
> >>>>>> Hi,
> >>>>>> I've found this page [1] and I am trying to get this idea
> >>>>>> working.
> >>>>>> Lukas suggested the values can be obtained from the hidden
> >>>>>> form
> >>>>>> by
> >>>>>> JS (DOM manipulation). But there will be probably necessary
> >>>>>> to do
> >>>>>> the other way i.e. to fill the form and submit it with some
> >>>>>> kind
> >>>>>> of
> >>>>>> no-op somehow on the background to let the browser to store
> >>>>>> it.
> >>>>>> Other option could be to use the cookies
> >>>>>> com.google.gwt.user.client.Cookies.{get|set}Value() but I am
> >>>>>> not
> >>>>>> sure about storing the password in plaintext somewhere in the
> >>>>>> cookie
> >>>>>> without asking the user.
> >>>>>> 
> >>>>>> Browser does basically the same, but at least it asks :]
> >>>>>> Yes, but this is not secure either.
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> [1]
> >>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecuri
> >>>>>> tyFAQ#auto-complete_and_GWT
> >>>>>> _______________________________________________
> >>>>>> rhq-devel mailing list
> >>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> rhq-devel mailing list
> >>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>> 
> >>>>> _______________________________________________
> >>>>> rhq-devel mailing list
> >>>>> rhq-devel at lists.fedorahosted.org
> >>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>> 
> >>>> _______________________________________________
> >>>> rhq-devel mailing list
> >>>> rhq-devel at lists.fedorahosted.org
> >>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>> 
> >>> _______________________________________________
> >>> rhq-devel mailing list
> >>> rhq-devel at lists.fedorahosted.org
> >>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >> 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list