Main Nav

4 years ago when we implemented Google Apps we took the approach that we would have a separate password for Google than for our enterprise systems. Most students were expected to access GA through web SSO anyway so a second password would only be an inconvenience for the few using POP (IMAP wasn't supported until a month before we went live). A lot has changed since then and there is a movement toward giving our enterprise password to Google rather than maintaining a separate password. I would like to know if there remain schools who are maintaining separate passwords rather than synching their passwords to Google. I know there were some who followed our lead back in 2008, but I don't know if they later changed their approach. If you have Google Apps but do not sync your enterprise password with Google, please respond. Thanks. Regards, Brendan Bellina Mgr, IdM USC ITS

Comments

We sort of do both. 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

--- Eric

That’s pretty much what Clemson does, although we hadn’t developed such nice vocabulary to describe.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Goodman
Sent: Wednesday, February 01, 2012 5:22 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

We sort of do both. 

 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

 

--- Eric

 

Yes, and that's something we'd like to do. Lacking the second factor, we opted for the "second password" approach, but we agree with your logic that one password and a second factor would also be a good (likely better) option.

--- Eric

Message from csr2@st-andrews.ac.uk

On Wed 01 Feb 2012 at 22:13:31 +0000, Brendan Bellina wrote: > > 4 years ago when we implemented Google Apps we took the approach that we > would have a separate password for Google than for our enterprise systems. > Most students were expected to access GA through web SSO anyway so a second > password would only be an inconvenience for the few using POP (IMAP wasn't > supported until a month before we went live). A lot has changed since then > and there is a movement toward giving our enterprise password to Google > rather than maintaining a separate password. > > I would like to know if there remain schools who are maintaining separate > passwords rather than synching their passwords to Google. I know there were > some who followed our lead back in 2008, but I don't know if they later > changed their approach. > > If you have Google Apps but do not sync your enterprise password with > Google, please respond. Thanks. We also expect the majority of our students to access Google Apps through the web interface, and they authenticate via Shibboleth using their main University credentials. Those students who do wish to connect via IMAP are required to maintain a separate password for that purpose. We weren't comfortable syncing our enterprise passwords with Google at the time, and nothing has happened since then to make us reconsider this position. Regards, Chris -- The University of St Andrews is a charity registered in Scotland : No SC013532

When I saw this response, I was a bit confused. But I think what you are doing might be the same as what we are doing. But maybe not.

 

What we do is:

-Have federated authN with GA for browser based access. No password stored at Google.

-Have the ability for GA users to set an *optional* additional, different password for non-browser based access to GA

 

So no "enterprise" password stored at Google at all. But there is a capability for users to get access to their stuff via non-browser based methods via some other password they set via our IdM portal.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Goodman
Sent: Wednesday, February 01, 2012 2:22 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

We sort of do both. 

 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

 

--- Eric

 

We currently maintain separate passwords for Google Apps.  We will be integrating with our enterprise password shortly.  

Does giving the enterprise passwords to Google violate InCommon Silver?

Regards,

Brendan

On Feb 1, 2012, at 2:22 PM, Eric Goodman wrote:

We sort of do both. 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

--- Eric

John,

Sounds like we may be in a similar boat then. Can you disclose some of reasoning for the switch?  In our case it seems to be imply a fear of inconveniencing faculty when we allow them to start using GA.

Regards,

Brendan

On Feb 1, 2012, at 2:50 PM, John Heartlein wrote:

We currently maintain separate passwords for Google Apps.  We will be integrating with our enterprise password shortly.  

On Wed, Feb 1, 2012 at 16:13, Brendan Bellina <bbellina@usc.edu> wrote:
I would like to know if there remain schools who are maintaining separate passwords rather than synching their passwords to Google. I know there were some who followed our lead back in 2008, but I don't know if they later changed their approach.

We moved to Google Apps last summer, and decided to maintain a separate "Google Sync Password" for those needing to sync mobile devices. This password is randomly generated by our IDM system when a user requests it (through our account management site), and is not something the user picks. Most users just authenticate to Google Apps on the web using SAML integration with our local authentication system.

--
Jeremy Mooney
ITS - Bethel University

On 2/1/2012 5:08 PM, Scotty Logan wrote: >
When I saw this response, I was a bit confused. But I think what you are doing might be the same as what we are doing. But maybe not.

To clarify this, no; we are doing something different than what you describe. Sorry for the confusing description

We actually maintain two different enterprise passwords. 

- One is used for federated authN and other "high risk" systems. 
- The other is used for other "lower risk" purposes. 

We share the latter with Google. Our Google system is not integrated in any way with our standard, federated authN. We don't use Shibboleth, even for web logins, and all authentication is through the "lower risk" password. The "lower risk" password we share with Google is also used by many on campus systems for local authentication.

This is partly historically motivated. At the time we were deploying our campus IDM system, our email system and several other applications relied on our then "enterprise" password, but we knew that it was being handled insecurely; many apps did not use or require SSL, and many (perhaps most) users had that password stored in insecure formats in their email clients. We decided that there was too much pre-existing insecurity for the federated authN password to meet emerging requirements (this was pre-Silver assurance) and so deployed a new, more tightly controlled, password for use with InCommon and other federations. However, we continue to manage the other "lower risk" password as a form of legacy support.

When we moved to Google, it was agreed that syncing this "lower risk" password to Google was better than deploying a third new password as the "Google only" password. 

Again, if we had widespread support for two factor authentication, we would probably only provide one enterprise password (and would be having the same debate that Brendan is having about sharing it with Google). 

--- Eric

I assume you are doing Shibboleth with GA.  This seems like the perfect solution to me.

What non-browser based use cases have you come across?

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Arkills
Sent: Wednesday, February 01, 2012 5:00 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

When I saw this response, I was a bit confused. But I think what you are doing might be the same as what we are doing. But maybe not.

 

What we do is:

-Have federated authN with GA for browser based access. No password stored at Google.

-Have the ability for GA users to set an *optional* additional, different password for non-browser based access to GA

 

So no "enterprise" password stored at Google at all. But there is a capability for users to get access to their stuff via non-browser based methods via some other password they set via our IdM portal.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Goodman
Sent: Wednesday, February 01, 2012 2:22 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

We sort of do both. 

 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

 

--- Eric

 

USC was the first to use Shibboleth with GA and we still do. However there have always been other ways into components of GA. Initially access to email via POP was the only one. Then they added IMAP. With the iPhone explosion there are a lot more students using IMAP to access their email than there used to be. 4 years ago we were told Google was storing the passwords non-encrypted, so we developed the external password solution which is compatible with SSO but allows a different password to be used for access to Google other than through our SSO. At the time IMAP and POP. 

Last summer though Google added an enhancement.  They added a back door so that any GA user, even those at schools that are using SAML, can login to GA via a Google page instead of going through the school SSO. For that the user provides a password that is hashed by Google and compared to the SHA-1 hash they have stored. While this is browser based, it is not controllable by us and can operate independently of our SSO.

So if you choose to allow Google to have the SHA-1 hash of your enterprise passwords you cannot also prevent users from typing the password directly into the Google website as well as passing it via IMAP or POP.  There are risks to the convenience of having the password at Google be your enterprise password. Whether or not the risks outweigh the user convenience is for each school to decide for themselves I guess. I tend to be risk averse myself, but that is just my view. 

Regards,

Brendan

On Feb 1, 2012, at 11:11 PM, "Jones, Mark B" <Mark.B.Jones@UTH.TMC.EDU> wrote:

I assume you are doing Shibboleth with GA.  This seems like the perfect solution to me.

What non-browser based use cases have you come across?

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Arkills
Sent: Wednesday, February 01, 2012 5:00 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

When I saw this response, I was a bit confused. But I think what you are doing might be the same as what we are doing. But maybe not.

 

What we do is:

-Have federated authN with GA for browser based access. No password stored at Google.

-Have the ability for GA users to set an *optional* additional, different password for non-browser based access to GA

 

So no "enterprise" password stored at Google at all. But there is a capability for users to get access to their stuff via non-browser based methods via some other password they set via our IdM portal.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Goodman
Sent: Wednesday, February 01, 2012 2:22 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

We sort of do both. 

 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

 

--- Eric

 


Well stated Brandon,  We are using a separate password for GAE for use with direct web login, IMAP and POP clients that is forced to be different from our institutional passwords for SSO.  Google also has had an OTP solution for a while that appears to be maturing

Barry



On 02/02/2012 01:11 AM, Jones, Mark B wrote:

I assume you are doing Shibboleth with GA.  This seems like the perfect solution to me.

What non-browser based use cases have you come across?

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Arkills
Sent: Wednesday, February 01, 2012 5:00 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

When I saw this response, I was a bit confused. But I think what you are doing might be the same as what we are doing. But maybe not.

 

What we do is:

-Have federated authN with GA for browser based access. No password stored at Google.

-Have the ability for GA users to set an *optional* additional, different password for non-browser based access to GA

 

So no "enterprise" password stored at Google at all. But there is a capability for users to get access to their stuff via non-browser based methods via some other password they set via our IdM portal.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Goodman
Sent: Wednesday, February 01, 2012 2:22 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Google Apps and passwords

 

We sort of do both. 

 

We maintain 2 passwords for each user; one is intended for InCommons Silver-type use and one for "less sensitive" uses. We sync that "less sensitive" password to Google Apps. 

 

So it is an enterprise password that is synced to Google, but it's not "the" enterprise password.

 

--- Eric

 

At Brown, our regular authentication id is an 8 character string that is usually associated with your name, but with a common name, may be abbreviated and have a number attached to it:
smithj; js8
and that id is affiliated with an enterprise password.

Google uses an authentication id that is your mail address e.g John_Smith

When Brown introduced GAE, the options seemed:
1) some services SAML based using the campus credential, and then some Google login based, chat was the tool that seemed like it would be the biggest use case, but also POP/IMAP.  This was dismissed as possibly confusing.  Sometimes I log on with X, and sometimes with Y identifier.  This seemed like it would generate a lot of helpdesk traffic

2) Align local user ID with Google,  This was dismissed as too disruptive since email addresses were often significantly longer than our regular login ID.

3) Separate ID/Password.  This seemed to present to the user with a clear distinction: Brown stuff use X username/password combo and Google stuff use Y username/password combo.  Within this model, we do not monitor what password they set for Google. 



We implemented our integration with GA in a similar manner to USC for alumni only in late 2009.  We actually use Shib, but put CAS in front of Shib for a consistent user experience with many other enterprise apps that use CAS.  If we want to call ourselves a trusted identity provider, and we give another IdP/SP our shared secrets (those shared with our users who trust us), it is up to us make sure we've protected the trust between us and those that trust us with their identities.  So, how do we do that in this case? 

Here are some of the issues that have risen out of our implementation:
-kiosk users and shared machine users (i.e. spouses) have difficulty killing off a Shib session with GA.  So, switching users on the same machine is sometimes difficult
-we, too, have seen the mobile explosion make this difficult for users using the GA-only password
-we have spent much time in the last two years increasing security around our enterprise passwords (expirations, changing complexity rules, limiting access to ldap for authn and replacing it with CAS, etc.), which should make us not want to share them with Google as that would be taking a step back.
-older protocols like imap, pop, and xmpp (gtalk) were not implemented to use "SSO" concepts and we don't see a way of changing that.
-setting a random password for the GA account during account creation has made some of us uneasy about the liability of setting a GA password for a user if they don't know it.  So, we force them to set it during user-driven GA account creation time that cannot be the same as our enterprise passwords.  This was more appropriate for alumni, but as we move more people over, it may be more difficult to rely on user-driven account creation.
-since implementation, we have created a one-time password service that is used for account recovery, and we are considering ways to use that "second" factor for systems like GA.

In the next year we will be creating GA accounts for most Virginia Tech people.  As of right now, we won't be sharing our enterprise passwords with Google.  Since Google won't/can't trust our IdP for imap/pop/xmpp, it may be in our users' best interests to not use our IdP for any of it, and create a password for all of GA and perhaps certain other low-risk local services, but that always invites the "too many passwords" argument.

Thank you for starting this thread Brandon, perfect timing.  Sorry for the length post, but we are in the thick of this at this very moment.

--
Kevin Rooney
Technical Lead
Identity Management Services
Virginia Tech

We've synced passwords with Google (we send the SHA hash) since we moved students over almost 4 years ago.    During the implementation I laid out all of the pros and cons for the Data Security Manger and the CIO and ultimately, ease of use won out.  In addition to user convenience, we also had a public-relations motive.  GA was our first application using SSO, so announcing that we have this great new system that you only need to remember one password for and then requiring a second password for IMAP/POP didn't make sense.  As far as InCommon Silver eligibility goes, when/if we are presented with an application that needs Silver, the users for that app will be required to use two-factor authentication.



Brendan We do not sync our enterprise password with Google. A "vendor" password is created and sent to Google for account creation. Tina Tina Meier Director, Server Administration Information Technology Oklahoma State University System 003 Math Sciences Stillwater, OK  74074 tina.meier@okstate.edu 405-744-9375
List peoples... So... This thread is very timely for my institution since we are in the middle of looking at a new email solution... To make things easier, I tried to consolidate responses in a simple spreadsheet. If I have something incorrect or folks don't want it reported, let me know. I will update as responses come in... https://docs.google.com/spreadsheet/ccc?key=0AnyxSQbNqfbvdEh2cFk5QXRDY3d... Please advise or scream... Mark ------------------------------------------ Mark Rank - IAM Program Manager University Information Technology Services UW-Milwaukee Email: rankm@uwm.edu Phn: 414-229-3706 ------------------------------------------
We do both as well, but in a little bit different way from what others have mentioned. The majority of users access access the web interface & are authenticated via Web SSO. For those that want to use IMAP/POP, we have them configure their clients to point to a local (SSL only) IMAP/POP service. These services serve all campus members - both those on GA & those whose email is provided locally. For the users on GA, it acts as a proxy & authenticates to GA with a separate passwd on their behalf that we've set. The users never know the second passwd exists & should we need to migrate them to/from GA, they don't have to change their IMAP/POP client settings. There were some concerns before deploying it over performance when proxying like this, but it hasn't become an issue to my knowledge. -Mark
Columbia University is in the process of migrating email to Google Apps (so this thread is very timely for Columbia as well). We are implementing CAS to authenticate browser-based users to Google Apps. For users with IMAP clients and other mobile devices, we are considering the following options, - Generate a randomly generated 8-digit password to send to Google. This password will be displayed to the user, but not stored at our end. Not storing the password is an obvious pro, but this requires the user to 'remember' (read, write down) the password for later use - like configuring another device or IMAP client. If the user forgets this password, the user has no other choice but to get another password and re-configure all of the previously configured clients/mobile devices. - A variation of the above solution is also under consideration - Generate a randomly generated 8-digit password to send to Google, but also store this password at our end to replay to the user at a later date. Storing the password is an obvious con, but there are benefits to the user. - Allow user to set a password of their choice. Again, this password will only be sent to Google Apps, but not stored at our end. With this solution the user is more likely to remember the password and so the expectation is that configuring additional devices or IMAP clients will be straight-forward. However, there is nothing to prevent the user from selecting their UNI (Columbia net ID) password as their Google Apps password. This undermines the rationale behind using SSO (which is, to not give Google our UNI password). - A third solution on the table is to figure out a way to automatically push out the randomly generated 8-digit password OR user selected password to the user's 'registered' device. This solution has potential. But I am not sure about how our HelpDesks might react to the potential increase in HelpDesk call volumes. Also, this solution does nothing for IMAP clients. Users with IMAP clients will have to configure them manually. We are having a lot of debate, internally, about these options. It will be very helpful to get your opinion on these options or add to the list of options, etc. Thanks and regards, Rama Balasubramanian Director for Identity and Access Management Columbia University Information Technology 212-851-7262 (W) | 347-753-1512 (C) | rb2684@columbia.edu
* Rama Balasubramanian [2012-02-02 16:00]: > - Allow user to set a password of their choice. Again, this password will only be sent to Google Apps, but not stored at our end. > With this solution the user is more likely to remember the password > and so the expectation is that configuring additional devices or > IMAP clients will be straight-forward. However, there is nothing to > prevent the user from selecting their UNI (Columbia net ID) password > as their Google Apps password. This undermines the rationale behind > using SSO (which is, to not give Google our UNI password). Sure there is. You have the new password and (hash and) compare it to the enterprise password you have on record. Several mentioned they were doing this, so it must be possible ;) -peter
NYU implemented Google Apps last spring.

• we implemented SSO for browser-based access (using our OpenSSO service)
• we chose to have users set separate passwords for non-browser access at our password reset site, encouraging, but not requiring, them to use a password different from their standard NYU password
• both the password reset site and our admin interface to Identity Services stuff display if and when a person set a "Google password"
• we do not require Google password reset (unlike our annual regular password change requirement)
• the only notable (though rare) problem that has arisen is if a person turns on "2-step verification", doesn't know what they're doing, and then POP/IMAP access breaks.

- Gary Chapman, Program Director for Identity Services, NYU/ITS
a tree falls in the forest. nobody is there to hear it. you know the rest. /mrg On Feb 2, 2012, at 10:16, Scotty Logan wrote: >
Message from jethro.binks@strath.ac.uk

On Thu, 2 Feb 2012, Peter Schober wrote: > * Rama Balasubramanian [2012-02-02 16:00]: > > - Allow user to set a password of their choice. Again, this password will only be sent to Google Apps, but not stored at our end. > > With this solution the user is more likely to remember the password > > and so the expectation is that configuring additional devices or > > IMAP clients will be straight-forward. However, there is nothing to > > prevent the user from selecting their UNI (Columbia net ID) password > > as their Google Apps password. This undermines the rationale behind > > using SSO (which is, to not give Google our UNI password). > > Sure there is. You have the new password and (hash and) compare it > to the enterprise password you have on record. Several mentioned > they were doing this, so it must be possible ;) Or just try an authentication with it? But, presumably nothing stops the user setting their enterprise password to be the same as the one they were given/used for Google Apps IMAP/etc, unless the enterprise password changing mechanisms are modified to include a check against that. Probably possible in some enviroments, and probably not in others... Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.
On 2/2/2012 9:49 AM, Jethro R Binks wrote: > On Thu, 2 Feb 2012, Peter Schober wrote: >> Sure there is. You have the new password and (hash and) compare it >> to the enterprise password you have on record. Several mentioned >> they were doing this, so it must be possible ;) > > But, presumably nothing stops the user setting their enterprise password > to be the same as the one they were given/used for Google Apps IMAP/etc, > unless the enterprise password changing mechanisms are modified to include > a check against that. Probably possible in some enviroments, and probably > not in others... FWIW, we check in both directions; you can't set your Google Apps password (we call it the "Google Desktop/Mobile password") to be the same as your regular password, and you can't set your regular password to be the same as your Google Apps password. -- %% Christopher A. Bongaarts %% cab@umn.edu %% %% OIT - Identity Management %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %%
Yale does the same.  Federated authN for browser based; Google password for non-browser based with password change hosted by us that prevents setting it the same.

Rod

On Feb 1, 2012, at 6:08 PM, Scotty Logan wrote:

Regarding the addition of a second factor for Silver compliance...

The Silver IAP references NIST 800-63, which outlines requirements for authentication at different levels of assurance.  Passwords that meet certain criteria are OK for LoA-2/Silver, and two-factor systems that meet certain criteria are OK for LoA-3 (and, therefore, LoA-2/Silver).  In the context of 800-63, adding a second factor to a not-quite-LoA-2 password is certainly good enough for Silver, assuming the combination of factors meets LoA-3.

I believe that most institutions, however, are not looking to achieve LoA-3 authentication through the addition of a second factor.  They're looking at combining a not-quite-LoA-2 password with a not-quite-LoA-3 second factor to achieve something that's good enough for LoA-2.  That's a reasonable approach, but 800-63 doesn't provide much guidance, other than identifying the risks that must be mitigated by the authentication technology, so those institutions are blazing a new trail.  I believe they'll be successful, though, and we'll have a good body of common practice in the not too distant future.

David Walker

On Wed, 2012-02-01 at 18:28 -0500, Tom Scavo wrote:
I'm curious, how do you keep people from changing their password within Google?

Jeff Abernathy
Jeff Abernathy
abernajb@slu.edu
314-977-2019

Web Portal Programmer 
Information Technology Services
Saint Louis University
ITS | Saint Louis University




For your Google Apps domain you can specify that the Google password change should be directed to your own password change site.

Regards,

Brendan Bellina
Mgr, Identity Management
Information Technology Services
University of Southern California
bbellina@usc.edu

On Feb 2, 2012, at 12:18 PM, Jeff Abernathy wrote:

I'm curious, how do you keep people from changing their password within Google?

Jeff Abernathy
Jeff Abernathy
abernajb@slu.edu
314-977-2019

Web Portal Programmer 
Information Technology Services
Saint Louis University
ITS | Saint Louis University




Message from robert.lau@usc.edu

Security focuses on risk – identifying, assessing and managing.

 

What is the risk involved with giving Google the SHA1 hash of your enterprise password?  Lost of the enterprise password.


How can the password be lost, and what is the probability of that happening?

 

1.     User divulges password in response to a phish – very high

2.     Password is captured via keylogger – moderate

3.     Google is compromised – low

 

With #1. When your users receive something like this:

 

From: xxx@yyy.edu

Date: Thu, 02 Feb 2012 19:46:44 +0000

To: "<Undisclosed recipients: ;>"

Subject: Storage Limit Exceeded


Dear members,


You have exceeded the storage limit on your mailbox. You will not be able to send or receive new mail until you upgrade your email quota. Kindly update your account by clicking here, http://kgko.com/formz/use/Web/form1.html


Regards, 

Technical Team.


Some non-trivial percentage of your users will provide either their enterprise or Google password.  Either way, the hackers now have access to your user’s mail (via SSO or gmail.com).  If the hackers only have the Google password, they can still send mail (as your user) to your helpdesk requesting an enterprise password reset.  And what is the probability that second factor information (employee ID, birthdate, etc) are already somewhere in your user’s Google space?  But unless it was a spear phishing attack (which I have seen several times), the hackers just want accounts at high-reputation/high-bandwidth sites to send more spam/phish.

 

With #2. If your user’s device has a keylogger, the hackers have captured your user’s enterprise and Google passwords already, and more.  All password changes are futile.  Game over.

 

With #3. When this happens (the Chinese incident comes to mind), we all have far bigger problems to deal with.


So (IMHO) the technical advantage of separate passwords does not translate into significant real world gains.

 

We enforce a 6-month expiration policy on almost all faculty and staff accounts1.  With two passwords, we would need to send two sets of expiration warnings, and handle all of the “which password are you talking about” calls, and a host of other user experience issues.

 

We are going to use some form of multi-factor authentication on certain services.  Until multi-factor is deployed, as Brendan pointed out earlier today, we can allow people to use a different password for Google if they wish (or are required to).  But they must be made aware of the resulting UX issues.

 

Robert Lau

Director, Information Security

Information Technology Services

University of Southern California

1-213-740-5469

 

1  Student passwords will also expire.  We know our passwords are out there.  $20 for 5 accounts on Chinese web sites.  Or even free - have you searched pastebin for your domain lately?  With expiration, at least the passwords they currently have will be useless in 6 months.

Message from dabantz@alaska.edu





On Thu, 2 Feb 2012, at 14:32 , Robert Lau wrote:

Security focuses on risk – identifying, assessing and managing.
 
What is the risk involved with giving Google the SHA1 hash of your enterprise password?  Lost of the enterprise password.

How can the password be lost, and what is the probability of that happening?
 
1.     User divulges password in response to a phish – very high
2.     Password is captured via keylogger – moderate
3.     Google is compromised – low

4.  The "Google-side" password is stored in users' POP/IMAP client on phone, tablet, netbook,.... and the device is compromised or lost 

5.  If we can give enterprise passwords to one vendor, why not more?  "Wouldn't taking this low risk be easier" than teaching clumsy old apps SAML or other protocols?  So it increases the chances of sending passwords ultimately to lots of places!




David Bantz <db@alaska.edu>   iam.alaska.edu
Chief Information Architect; Manager, Identity & Access Management Services
University of Alaska Office of Information Technology
✉ 103 Butrovich, 910 Yukon Dr, Fairbanks, AK  99775-5320
✆ +1 907 450 8314 (o) +1 907 460 6321 (m)

From my perspective the question is if the practice is allowed by NIST 800-63 level 2 and InCommon Silver. If no then the risk or lack there of does not matter much. If it is then the only decision is if level 2 or Silver are high enough LoA for your use cases. Sent from my iPhone
Message from robert.lau@usc.edu

#4. For people who have not opted into Google and are using central email, their enterprise password is stored on mobile devices right now.  Loss of their device means loss of their enterprise password.  Hence the need for a policy to password protect mobile devices and require the ability to perform a remote wipe.

#5. Security evaluates each vendor independently.  Giving to one does not automatically mean giving to another.  IMAP supports SASL.  Add SAML2 as a SASL mechanism.  Voila!  Now just tell Microsoft and Apple that :)

-robert

From: David Bantz <dabantz@ALASKA.EDU>
Reply-To: Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>
Date: Thu, 02 Feb 2012 15:49:24 -0900
To: <IDM@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [IDM] Google Apps and passwords





On Thu, 2 Feb 2012, at 14:32 , Robert Lau wrote:

Security focuses on risk – identifying, assessing and managing.
 
What is the risk involved with giving Google the SHA1 hash of your enterprise password?  Lost of the enterprise password.

How can the password be lost, and what is the probability of that happening?
 
1.     User divulges password in response to a phish – very high
2.     Password is captured via keylogger – moderate
3.     Google is compromised – low

4.  The "Google-side" password is stored in users' POP/IMAP client on phone, tablet, netbook,.... and the device is compromised or lost 

5.  If we can give enterprise passwords to one vendor, why not more?  "Wouldn't taking this low risk be easier" than teaching clumsy old apps SAML or other protocols?  So it increases the chances of sending passwords ultimately to lots of places!




David Bantz <db@alaska.edu>   iam.alaska.edu
Chief Information Architect; Manager, Identity & Access Management Services
University of Alaska Office of Information Technology
✉ 103 Butrovich, 910 Yukon Dr, Fairbanks, AK  99775-5320
✆ +1 907 450 8314 (o) +1 907 460 6321 (m)



IU also uses a second, vendor-specific password for both our Google and Microsoft hosted mail solutions.  We had many of the same motivators that have been mentioned here, but we also had one that wasn’t.  We have spent a lot of time and effort educating users that they don’t enter their IU passphrase on anything other than an IU system.  Syncing the IU passphrase to student mail (or any cloud service) runs the risk of damaging that user education effort.

 

Jacob

 

Message from robert.lau@usc.edu

We do not have that policy yet but are working toward it.

People read their mail on any device they want.  Many schools that run their own Exchange utilize ActiveSync to remotely wipe only the Exchange-sync'd content from mobile devices.  When a personal device is lost, the owner immediately notifies the school which does a remote wipe, significantly reducing the risk of HIPAA/FERPA/PCI data loss and resulting breach notification, which can be very costly both in dollars and institutional reputation.

I completely agree, the enterprise password should not be used for sensitive systems, that is why we are going to deploy some form of multi-factor/risk-based authentication system for them.

-robert

From: Eric Goodman <ericg@UCSC.EDU>
Reply-To: Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>
Date: Thu, 02 Feb 2012 17:46:52 -0800
To: <IDM@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [IDM] Google Apps and passwords



Message from csr2@st-andrews.ac.uk

On Thu 02 Feb 2012 at 14:21:20 +0000, Mark John Rank wrote: > > So... This thread is very timely for my institution since we are in the > middle of looking at a new email solution... > > To make things easier, I tried to consolidate responses in a simple > spreadsheet. If I have something incorrect or folks don't want it > reported, let me know. I will update as responses come in... > > https://docs.google.com/spreadsheet/ccc?key=0AnyxSQbNqfbvdEh2cFk5QXRDY3d... > > Please advise or scream... A correction/clarification regarding our setup - we also handle the setting of the Google credential locally to ensure that it doesn't match our enterprise credentials. Regards, Chris >
updated... thanks mark ------------------------------------------ Mark Rank - IAM Program Manager University Information Technology Services UW-Milwaukee Email: rankm@uwm.edu Phn: 414-229-3706 ------------------------------------------
Message from benjamin.oshrin@the.oshrinium.net

Have you been asked to provide support for non-web access to other applications? eg: Calendar? (I like this approach in general... it also provides a layer of protection against the switch to the next Cool Email Provider 5 years from now, assuming we're still using email...) -Benn- On 2/2/12 9:45 AM, Mark Valites wrote: > We do both as well, but in a little bit different way from what others have mentioned. > > The majority of users access access the web interface& are authenticated via Web SSO. > > For those that want to use IMAP/POP, we have them configure their clients to point to a local (SSL only) IMAP/POP service. These services serve all campus members - both those on GA& those whose email is provided locally. For the users on GA, it acts as a proxy& authenticates to GA with a separate passwd on their behalf that we've set. The users never know the second passwd exists& should we need to migrate them to/from GA, they don't have to change their IMAP/POP client settings. There were some concerns before deploying it over performance when proxying like this, but it hasn't become an issue to my knowledge. > > -Mark > >
Robert,

This is roughly the exercise Cornell undertook when deploying Google Apps and making the decision to synchronize passwords. It really came down to a risk assessment like this that takes into account the usability factor. If we could have federated all forms of access we would have taken that approach, of course. Thanks for the clear summary. 
--
Andrea Beesing
Assistant Director, Infrastructure
Cornell Information Technologies
110 Maple Ave
Cornell University
(607) 254-7441
amb3@cornell.edu

From: Robert Lau <Robert.Lau@USC.EDU>
Reply-To: Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>
Date: Thu, 2 Feb 2012 15:32:35 -0800
To: <IDM@LISTSERV.EDUCAUSE.EDU>
Subject: [IDM] Google Apps and passwords

Security focuses on risk – identifying, assessing and managing.

 

What is the risk involved with giving Google the SHA1 hash of your enterprise password?  Lost of the enterprise password.


How can the password be lost, and what is the probability of that happening?

 

1.     User divulges password in response to a phish – very high

2.     Password is captured via keylogger – moderate

3.     Google is compromised – low

 

With #1. When your users receive something like this:

 

From: xxx@yyy.edu

Date: Thu, 02 Feb 2012 19:46:44 +0000

To: "<Undisclosed recipients: ;>"

Subject: Storage Limit Exceeded


Dear members,


You have exceeded the storage limit on your mailbox. You will not be able to send or receive new mail until you upgrade your email quota. Kindly update your account by clicking here, http://kgko.com/formz/use/Web/form1.html


Regards, 

Technical Team.


Some non-trivial percentage of your users will provide either their enterprise or Google password.  Either way, the hackers now have access to your user’s mail (via SSO or gmail.com).  If the hackers only have the Google password, they can still send mail (as your user) to your helpdesk requesting an enterprise password reset.  And what is the probability that second factor information (employee ID, birthdate, etc) are already somewhere in your user’s Google space?  But unless it was a spear phishing attack (which I have seen several times), the hackers just want accounts at high-reputation/high-bandwidth sites to send more spam/phish.

 

With #2. If your user’s device has a keylogger, the hackers have captured your user’s enterprise and Google passwords already, and more.  All password changes are futile.  Game over.

 

With #3. When this happens (the Chinese incident comes to mind), we all have far bigger problems to deal with.


So (IMHO) the technical advantage of separate passwords does not translate into significant real world gains.

 

We enforce a 6-month expiration policy on almost all faculty and staff accounts1.  With two passwords, we would need to send two sets of expiration warnings, and handle all of the “which password are you talking about” calls, and a host of other user experience issues.

 

We are going to use some form of multi-factor authentication on certain services.  Until multi-factor is deployed, as Brendan pointed out earlier today, we can allow people to use a different password for Google if they wish (or are required to).  But they must be made aware of the resulting UX issues.

 

Robert Lau

Director, Information Security

Information Technology Services

University of Southern California

1-213-740-5469

 

1  Student passwords will also expire.  We know our passwords are out there.  $20 for 5 accounts on Chinese web sites.  Or even free - have you searched pastebin for your domain lately?  With expiration, at least the passwords they currently have will be useless in 6 months.

We do not support non-web access to the other applications. -Mark On 02/03/2012 08:06 AM, Benn Oshrin wrote: > Have you been asked to provide support for non-web access to other > applications? eg: Calendar? > > (I like this approach in general... it also provides a layer of > protection against the switch to the next Cool Email Provider 5 years > from now, assuming we're still using email...) > > -Benn- > > On 2/2/12 9:45 AM, Mark Valites wrote: >> We do both as well, but in a little bit different way from what others >> have mentioned. >> >> The majority of users access access the web interface& are >> authenticated via Web SSO. >> >> For those that want to use IMAP/POP, we have them configure their >> clients to point to a local (SSL only) IMAP/POP service. These >> services serve all campus members - both those on GA& those whose >> email is provided locally. For the users on GA, it acts as a proxy& >> authenticates to GA with a separate passwd on their behalf that we've >> set. The users never know the second passwd exists& should we need to >> migrate them to/from GA, they don't have to change their IMAP/POP >> client settings. There were some concerns before deploying it over >> performance when proxying like this, but it hasn't become an issue to >> my knowledge. >> >> -Mark >> >>
Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.