Saving the credentials by browser on login page

Alan Santos asantos at redhat.com
Wed Sep 26 15:35:43 UTC 2012


Yes, I believe so.

On Sep 26, 2012, at 11:32 AM, Charles Crouch <ccrouch at redhat.com> wrote:

> I misspoke, what I should have said is...
> 
> "Does the as7 console allow the browser to save your credentials when logging into it?"
> 
> ----- Original Message -----
>> It's not the console that let's you save the creds. It's the browser.
>> 
>> The only thing the console can do is to specifically PREVENT the
>> browser from
>> doing so (either using some markup or by using a messed up dynamic
>> HTML as we
>> do ;) ).
>> 
>> For example access.redhat.com (which I assume you'd agree is very
>> security
>> sensitive) doesn't prevent the browser from saving the creds for the
>> login
>> page.
>> 
>> I repeat, this is a feature of a browser, not any webapp.
>> 
>> On Wednesday, September 26, 2012 11:11:29 Charles Crouch wrote:
>>> does the AS7 console let you save cred's?
>>> 
>>> ----- Original Message -----
>>> 
>>>> 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-smar
>>>>> tgwt-widgets?rq=1 *
>>>>> http://stackoverflow.com/questions/12564518/wrapping-pre-made-elements-u
>>>>> sing-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/loginS
>>>>>>> avin
>>>>>>> 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/LoginSec
>>>>>>>>>> u
>>>>>>>>>> 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/Log
>>>>>>>>>>>>>>> i
>>>>>>>>>>>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> 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