Saving the credentials by browser on login page

mike thompson mithomps at redhat.com
Wed Sep 26 14:42:26 UTC 2012


Just backing up a step. Do any other competing products in our space do this now?




On Sep 26, 2012, at 7:08 AM, Jiri Kremser <jkremser at redhat.com> wrote:

> Hi,
>  thanks for responses.
> 
> "The typical GWT solution (from my email) uses one single form for the login process."
> 
> That was my first attempt and I agree it would be simpler. It worked but the UI was obviously different (in terms of look and feel), it can be styled by css to look same like SmartGWT, but we use also form validations and error notification area in the form. These are supported only by SmartGWT. If it doesn't mind, I can rewrite it to use the pure gwt for logging in, but I thought we wanted to move away from the pure GWT components.
> 
> I am sure the same can be done with SmartGWT.
> I didn't find the way. The problem is the SmartGWT don't provide any functionality for wrapping the existing HTML elements as I've written few mails ago.
> * http://stackoverflow.com/questions/9935328/wrapping-html-element-by-smartgwt-widgets?rq=1
> * http://stackoverflow.com/questions/12564518/wrapping-pre-made-elements-using-smartgwt
> * http://forums.smartclient.com/showthread.php?t=23739
> 
> ..and the login form created by SmartGWT is definitely not recognized by browser as a "login form", so it doesn't provide any saving options for credentials. No wonder, there are so many layers of "divs" and the buttons are represented as html tables, and so on.
> 
> 
> 1) Copying usernames and passwords is risky because the actual strings will be stored in memory variables.
> 
> The same thing is happening right now. The SmartGWT form fields are represented by java script variables and the text from it could be extracted right now. 
> Because of the fact the all client code can be fakeable (I hope it is a word:]), the most security checks including authN and authZ should be done completely on the server-side. Here is nice video of GWT security: http://www.youtube.com/watch?v=hKrvY42dw1A. He shows that obfuscation doesn't solve anything.
> 
> 2) Having a JSNI method for login is also exploitable. The login process will be at the fingertips of attackers armed with clever XSS attacks. This will enable silent login attempts with absolutely no warning to the user.
> 
> here is a code sniped from my compiled project (file 61B0DAF0F7EDA8CBC84C80FE3874EB2A.cache.html, but the name may differ): 
> 
>  if (statusCode == 200) {
>  ...  org_rhq_enterprise_gui_coregui_client_UserSessionManager_login__Ljava_lang_String_2Ljava_lang_String_2V(this.org_rhq_enterprise_gui_coregui_client_LoginView$9_val$username, this.org_rhq_enterprise_gui_coregui_client_LoginView$9_val$password);
>  ...
>  }
> 
> What stops me now from calling this function right now with the current version and why is JSNI login method a problem (btw. my exposed function has signature doLogin() no params here, the values are taken from the form).
> 
> 
> JK
> 
> 
> 
> ----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Wednesday, September 26, 2012 10:53:43 AM
> Subject: Re: Saving the credentials by browser on login page
> 
> On Tuesday, September 25, 2012 17:47:20 Stefan Negrea wrote:
>> I am concerned too with the security risk of this proposed approach. The
>> typical GWT solution (from my email) uses one single form for the login
>> process. I am sure the same can be done with smartGWT.
>> 
>> I see two problem with the current proposal:
>> 1) The extra copying between the HTML form and smartGWT form is exploitable.
>> Copying usernames and passwords is risky because the actual strings will be
>> stored in memory variables. 
> 
> Are they not stored in the HTML form, too? Like 
> document.getElementById("passwordField").value(); ? If the attacker can get 
> himself to manipulate the DOM on the page, he can extract any info the user 
> enters, no matter if the form is dynamic or static. And there needs to be no 
> copying for that to be possible.
> 
>> 2) Having a JSNI method for login is also
>> exploitable. The login process will be at the fingertips of attackers armed
>> with clever XSS attacks. This will enable silent login attempts with
>> absolutely no warning to the user.
>> 
> 
> Yes, the exposure of the login method through JSNI makes the attack attempts 
> easier. But the login method has always been there, only with a slightly more 
> obfuscated name. Anyone knowing GWT would be able to deduce the name easily 
> (like Jirka did when he wrote the JSNI impl).
> 
>> The solution: use just the HTML form and change the post address of that
>> form. Instead of showing the smartGWT form on the login page, make this
>> HTML form visible on the webpage. You should just manipulate the DOM to
>> change the location of the form in the tree. Rather than making the
>> solution more complicated (extra layers of forms), we should work on
>> removing any unnecessary elements/code/variables from the login process.
>> 
>> The idea is to use the browser infrastructure for the entire process. The
>> security concerns will then shift from our application to the browser
>> itself. And that is an acceptable security risk.
>> 
> 
> +1, that would be the ideal solution.
> 
>> 
>> Stefan Negrea
>> 
>> ----- Original Message -----
>> 
>>> From: "Lukas Krejci" <lkrejci at redhat.com>
>>> To: rhq-devel at lists.fedorahosted.org
>>> Sent: Tuesday, September 25, 2012 10:44:13 AM
>>> Subject: Re: Saving the credentials by browser on login page
>>> 
>>> What about constrained environments where users can't install their
>>> own
>>> browser addons?
>>> 
>>> I mean, c'mon. This is a very standard browser feature we're talking
>>> about
>>> here that we're preventing.
>>> 
>>> I personally can see no security threat to having a static HTML form
>>> to do the
>>> logging in. The server endpoints are still the same, the data passed
>>> to them
>>> is still the same. It's the server that does the authentication and
>>> no server
>>> logic is being changed here. Also, no data is stored on the client
>>> side.
>>> 
>>> Wrt XSS - maybe the exposure of the doLogin() method makes the
>>> potential
>>> breach a bit easier but that method always existed and was being
>>> translated
>>> into javascript by GWT compiler. So all Jirka did there was that he
>>> changed a
>>> a javascript function to have a "nicer name".
>>> 
>>> I am all for having another pair(s) of eyes on this, but I think
>>> we're being a
>>> bit paranoid here.
>>> 
>>> Take a look at the diff
>>> http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=jkremser/loginSavin
>>> g&id=36668b80ee7f8caef63bc3b6bdc10768038031e2
>>> 
>>> There is no new functionality there - it's just another way of
>>> calling the
>>> same method.
>>> 
>>> On Tuesday, September 25, 2012 11:11:41 John Mazzitelli wrote:
>>>> 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/LoginSecu
>>>>>> rity
>>>>>> FAQ#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/Logi
>>>>>>>>>>> nSec
>>>>>>>>>>> uri
>>>>>>>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> 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