Link to home
Start Free TrialLog in
Avatar of IT-Monkey-Dave
IT-Monkey-DaveFlag for United States of America

asked on

Google Apps Login, Browsers Caching User Credentials

We've signed up for the 30 day trial of Google Apps for Business.  When you create your domain you get a unique login url like "www.google.com/a/ourdomain.com".

By default the browser offers to cache the user's credentials, whether they login at that url or at just plain old www.google.com or www.gmail.com.  There is no practical way to prevent browsers from offering to cache user credentials at all those portals.  I cannot depend on my users to login at our custom portal -- I have to assume they will login wherever it is most convenient, and let the browser cache their credentials, whether they're at home, at Starbucks, at a hotel, etc.

Google support says they can't change this except on our custom login page, which they did at my request (but I don't have direct control over that).  They want me to lock down the browsers, which is impractical.

Anyone know how to make this more secure?  Do I need to be looking at SSO and Active Directory Federation Services?  Or would SSO only work on our custom login page and not all the other potential Google login portals?
Avatar of IT-Monkey-Dave
IT-Monkey-Dave
Flag of United States of America image

ASKER

So I'm thinking that if I can implement SSO on our "custom" google login page, and have that authenticate users to our Active Directory via AD Federation Services, I could then prevent the users from logging in via any other Google portal by changing the Google-side passwords so they no longer work.  The only way the user could get in is via the custom google login page and AD authentication.

Thoughts?  
This is exatcly why Cloud Computing is going to be a disaster,.....but everyone is jumping on the bandwagon because it is the latest "thing" and the lastest "buzzword".  Personally I think the IT Industry is headed for "Security Armegeddon" with this cloud stuff,...but that's just me.
If this was Microsoft instead of Google, there would be an outcry of public ridicule over how insanely insecure this is out of the box.  I have no doubt it can be locked down somehow but it's not obvious how.  Google is so far unable to assist me.  I find very little information about this in web searching.  And I can't believe nobody on EE has any ideas.  Maybe I posted my quesion in the wrong Zones?
Why would we have ideas!?!?,...we didn't do it,...we didn't invent it,...we didn't design the Google's apps you are using to even know how in the world they designed/built it.  We are just IT people just like you,...we are volunteers here,...we don't work for EE, are not trained by EE, and are not paid by EE (apart from a T-shirt once in a while).

As far as the technology,...browsers are not designed to be used in the way this "mad-dash-to-the-cloud"  is pushing things to be used.  This whole cloud stuff has not had the R&D put into it that it should,...existing technology (particularly browsers) are not really "ready" for it.  

But everyone wants to "make a buck" and also have control over what a business does and have access to a business's data and business habits,...so  nobody really cares about security (or it isn't their first thought anyway),...they just want to sell you the service.  Does anyone really believe that any "cloud provider" locks themselves out of their own Applications that they own but you pay to use, so that they cannot see what you are doing within the Applications?  Does anyone really believe they won't at a minimum do data mining to at least view "trends" and "habits" in order to target you with more "marketing"?,...the SPAM of the future.
I didn't mean to slam EE, far from it.  I'm just a little, uh, surprised that little old me is the only person here who has looked at Google's solution and noticed it seems riddled with security holes out of the box.  Don't take my comment personally.  ;)
No problem.

I haven't look closely at Google specifically themselves.  I'm just viewing the whole cloud concept as "one big thing" no matter who is involved,...and I don't trust it.  I was out at MS's HQ last week and no one could complete a sentence without using the word "cloud" at least twice,...it was really depressing.  Also no one wanted to talk about (or down-played) the IT people who would loose their jobs because the Apps they were paid to manage ceased to exist locally and became provided and managed by third parties off-site.
What do u mean by "Google support says they can't change this except on our custom login page, which they did"? Do u mean now (on the custom page) u never get prompted to save credentials BY the browser?
By default the custom login page offers to save the user's credentials.  Google supposedly disabled that for me.  However I noticed today that their fix doesn't work with all browsers.  IE9 still offers to cache my password if I use that login portal.  Caching of credentials at other login portals like www.gmail.com are not controllable except by locking down the browsers which is not realistically possible.
Yea, I believe it is two separate caches.  The one the Sites use is a Cookie in the local users Profile,...the other is a cache within the browser itself.

So the Cookie is related to the "Remember me" Checkbox you see on a lot of Sites.  But the other form of it is stored in the Browser's Protected Storage which can be viewed with tools such as this:

Protected Storage PassView v1.63: Recover Protected Storage passwords
http://www.nirsoft.net/utils/pspv.html
(Note this product may be falsely detected as a virus so you may have to turn off your AV before you can do anything with it)

So are dealing with two differnt things. This Protected Storage of the Browsers is kida what I mean when I say that browser design just is not technilogically "ready" from a security perspective with all this "Cloud" bandwagon that the industry is jumping on.
The example I would offer is banks and online banking: No matter what browser you use or what system you're on, the bank has a single login portal and that portal prevents browser-side caching of user credentials.  This clearly works.  Why can't Google offer something like that for corporate users concerned about their cloud-based data security?

I'm continuing to pursue this through Google channels but so far they haven't offered me anything except platitudes like "Well it's better than users carrying around flash drives to share their data".
Good point.  My bank works like that,...I think.  
At least it does not cache it as a cookie. But I think tonight when I get home I am going to try a couple of those password Tools in the browser and see if it shows the credentials for my banking site just to be sure.
Heh, I'd be interested to hear what you discover.  
Sign up for a BPOS trial... its a much better service :)
Though not a direct solution towards the caching of user name and password. Possibly the two step verification would improve user awareness on the sensitivity of the information they accessing on unknown PC's: http://www.google.com/support/a/bin/answer.py?answer=175197&hl=en

Also it would be wise to educate your users to basic Google Apps knowledge. For example you can check if you are logged in in a different location and logout of that session. (at the bottom of the Google mail page, where the IP address is stated.)
Update...

I think I might be able to accomplish what I want with a combination of enabling Single Sign-On (SSO) on the Google side, and pointing it at our ISA server.  The ISA box would have a web listener that uses forms-based authentication, just like Outlook Web Access.  That method prevents browser-side caching.  Theoretically the ISA server authenticates the user and acts as a proxy between Google and our Active Directory Federation Services server which will handle the LDAP query from Google.

Unfortunately Google support has been of almost no assistance to me on this.  They can't tell me whether enabling SSO on our Google account will redirect all possible Google logins to our SSO login.  I did some initial testing yesterday and SSO propagated to two Google login portals, but I had to turn SSO off again because it was disrupting the users.  I may have to do my testing after hours because it can take hours for a Google-side configuration change like enabling SSO to propagate through the entire Google cloud.  Ack.

The other piece of this puzzle is whether I can prohibit users from changing their Google-side password.  That's the latest question I've posed to Google, am awaiting a response.

I don't know why I didn't think of using the ISA server before...
Heh, I'd be interested to hear what you discover.  
I tried it.  The credentials were not cached,...so the banking site does what it is supposed to do,...so like you said,...Google should be able to do it too.

I don't how how ISA is going to do what you want.  Using FBA is meant for Publishing Rules which are inbound,...it is not for outbound access which is what Google would be.
I can't blame Google for not being much help there,...I'm an MVP for Fronfront (ISA, TMG) and I sure can't help you with trying what you are trying with ISA.
I've been messing with this off and on, can't get it to work.  I know what I want to have happen but don't know how to get there.  All I can do for now is make management aware of this as a security issue (in my opinion anyway) and try to educate the users, while acknowledging some of them will not pay attention.

It's just my editorial opinion that with the resources Google has, they should be able to provide their paying business customers with more assistance on this issue.  Oh well.  

Will request that the question be closed.
It's just my editorial opinion that with the resources Google has, they should be able to provide their paying business customers with more assistance on this issue.  Oh well.  
I completely agree with that.
Its been my experience that Google support is very uninterested in assisting their customers.  I can't count the number of times they have refused to answer serious questions about their services,

saying and I quote "That is our magic"

We joke around the office that they must only be interested in what ever the next shiny new thing is...

We had intentions(we were forced to at least try it) of using Google sites for an external customer portal, but our legal department killed that.  Mainly due to Google TOS.  

Google support also does not consider a service outage of less than 10mins actual downtime.  

They claim all 9's on SLA uptime, but if you average the last year, I doubt you will get all 9's.

To that end, for a small business, that doesn't have to worry about compliance, auditing, governance, and all the "big corp" issues, Google does provide a very basic service that is more cost effective that most hosted services.

I like to call Google the AOL of the next generation.  It quick, easy to use, but far too simple for advanced users.

Just my 2 cents.
saying and I quote "That is our magic"

they're arrogance is disgusting

We joke around the office that they must only be interested in what ever the next shiny new thing is...

The whole industry is like that anymore. If I hear the word "cloud" one more time I am going to throw up.
That's why I get in so many arguments with people in web forums.  Nobody cares about quality anymore.    Things aren't any better on the business end-user side,...there are too many network-admin-wannabees where the business grabbed the first employee that was "good with computers" and decared them the "IT guy".  They run down to the local retail store and buy a home-user "router" that isn't even a real router,...it's a low-buck NAT Firewall slaps in on a CableTV Internet Service that the Cable Company arbitraily declared it a "business class" account that isn't any different technically than a home user account,....and they think they are running a business network.   Then when it gets more complex and they have to toos in a VPN or two and the whole things comes crashing down around them and they can't understand why.  Then when I explain the right way it has to be done,...all they want to do is argue with me,...and say they don't want to spend the money.  Well it isn't my problem if they won't spend the money, listen to me, and do it right.

We need a "Holmes on Homes" style TV show for the IT industry.

I agree with your 2 cents perfectly and bump it up to the 2 bucks level.
One part of me says Google Cloud is insecure, we lose control, if Google has a problem I won't even be able to send out an internal email to my users explaining that there's a problem.  We got NOTHING if Google's cloud bursts.  We are so dependent on reliable email etc. how can we even be considering doing this?  I'll have users leaving cookie trails all over in the wild leading into company Google accounts and apparently Google considers that acceptable.  I'm guessing we could probably mitigate that issue using Google APIs but we don't have the resources to do that so we use the tools Google offers us and that's all for now.

Then the other part of me says, You know what?  Off-load our Exchange-based stuff to Google.  It will no longer be my responsibility to back it up and have a disaster recovery plan and keep the server running.  Email problem?  Well our Internet connection is fine so all I can do is open a trouble ticket with Google and hope they have a solution.  Oh, the city accidentally ran a backhoe through the copper and fiber links servicing this building?  Well don't worry, I'll run around and tell everyone verbally what the problem is.  Would send an email but hey, we no long have an internal email system, remember?

Bah.
Oh and if you take a 5-year view of things and amortize the costs of doing Exchange here, including a new server, licensing, etc., and amortize that over the 5 years, it works out to be no more than paying Google $50 per user per year, and probably less.  Exchange administration expenses are a non issue for a company our size since we're not near large enough to have a dedicated Exchange administration.  And once Exchange is up and running, it requires very little attention.  So don't believe Google's estimate of $40,000 a year or more to administer a local Exchange server.  It might be true if you are very large but it's not true for us.
If I could sing we could be a Choir,...but,...you don't want me to sing,...trust me.    :-)
ASKER CERTIFIED SOLUTION
Avatar of IT-Monkey-Dave
IT-Monkey-Dave
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
No solution found