39

I'm a student and it seems every school or university I have been to has one password that you set for your user account for logging in to university services, which is also then synced to external services the university use such as blackboard, fronter, dropbox, Office 365 e-mail, etc.

Lesson 1 of cybersecurity is not to store passwords in plain text or to encrypt them. But instead to use some sort of hashing algorithm. If this is true how can a university's IT service automatically sync password for all the relevant accounts? I can understand how this can be done by using APIs each time to update all the services when a password change has been requested, but it would then make it impossible to adopt a new service without the user re-entering their password.

How is it done? or are they just holding passwords in plain text?

schroeder
  • 123,438
  • 55
  • 284
  • 319
darkniss
  • 501
  • 4
  • 6
  • 17
    I added the Single-sign-on tag because that's actually what you are talking about (and it's the answer). – schroeder Jan 20 '19 at 15:28
  • 4
    For educational institutions in the US, [Internet2](https://www.internet2.edu/products-services/trust-identity/) drives a lot of identity management work. [Shibboleth](https://www.shibboleth.net/) is common in Universities to provide the actual sign-in APIs, and [InCommon](https://www.incommon.org/index.html) allows federation (i.e. cross-university authentication for features like eduroam). – user71659 Jan 20 '19 at 19:58
  • 2
    The accepted answer is the right one, but also consider that a hash could be passed to other services and used as long as the other services know how it was created. – Blrfl Jan 20 '19 at 23:28
  • 1
    @Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors. – Ben Voigt Jan 21 '19 at 16:02
  • @BenVoigt Sure, to a point. The distinguishing factor being that if I tell you I have an account called `bob` whose password hashes to `ABC123`, it's stored in your own system. – Blrfl Jan 21 '19 at 23:27
  • You can find an explanation on how it's done in Switzerland there: https://www.switch.ch/aai/about/ It's probably similar in other European countries, since there is a bit of intra-country business. – Nico Jan 22 '19 at 13:11

2 Answers2

71

It's usually not that passwords are "synced" between services, but rather a centralized authentication service is used. In many cases, this is going to be a Microsoft Windows domain controller running an Active Directory server (others exist e.g. FreeIPA), which other services can talk to using LDAP and Kerberos.

The typical setup has all user accounts added to the directory server (which is usually replicated across multiple servers transparently for redundancy and reliability purposes). Locally hosted applications (e.g. Blackboard) will have the directory server's LDAP information entered into the server settings as an authentication provider. When a client enters their credentials on the web interface, the application may check the credentials against a local database as well as LDAP services that have been configured. If the LDAP server confirms a successful authentication, information about the user (contact info, group membership, etc.) can be retrieved to populate parts of the application. When user information is updated somewhere, the data on the directory server is changed so that the change will be visible everywhere else. This applies to changing the password.

Not all applications will use LDAP directly; external services such as Office 365 or Google Apps suite and others may instead use single sign-on (SSO), where you authenticate through your organization's login page and these external services are able to effectively reuse this authentication (e.g. through SAML).

On the directory server, passwords are stored as hashes within each user object. The hashes are protected further using LDAP access controls (so any LDAP client can't just pull hashes) and are encrypted with a key from the registry (in the case of Windows Active directory).

In short, this is just scratching the surface. There are a number of ways to set up a network and services to use centralized authentication. But almost every organization uses some type of this system; like you said, it would be very difficult and insecure to do manually in most cases.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • 20
    A useful comparison may be online services, such as Google's myriad sites & tools (e.g., Youtube, Google+, Google Drive, Gmail, etc.) all sharing the same login information, by passing your authentication attempts on to a single backend service. Or for external services, Stack Exchange allowing users to log in by authenticating through Facebook or Google. – Justin Time - Reinstate Monica Jan 20 '19 at 20:01
  • 7
    Kerberos and CAS are also heavily used in Academic organizations. In additions to that RADIUS is pretty much omnipresent for WLAN access points (including EDURoam) – eckes Jan 21 '19 at 09:53
  • @JustinTime In fact, after I left university, they moved their email to Google - I haven't been back but chances are they moved a lot of their authentication to that google account. – corsiKa Jan 22 '19 at 18:24
0

When logging in to external services, if you are redirected by your browser to your organization for entering the password then federation is used, i.e. the password is not synced to the external service.

This is usually the case, and the standard used is usually SAML2.

But there are organizations that actually sync your password to different services, in my experience it's usually between internal services that don't support LDAP authentication but I have seen it done for external services as well such as Office 365 and Google.

This is done by a identity management system (there are plenty of those out there, "IDM") which has connectors that keep identity information in sync between a central repository and all connected systems.

In that case the password is stored encrypted, in all cases I've seen with AES256 in that central repository. Of course the administrator of the IDM system can read those passwords since they control the key if there are no audit controls in place.

Singleton
  • 1
  • 1
    Really, **encrypted** passwords, with AES, not **hashed** with $somethingappropriate? Are you sure "all cases you've seen" are not zero? – Tobi Nary Jan 22 '19 at 08:24
  • 1
    To be more precise, **if** an IDM **encrypts** the passwords and doesn't hash them, it's not a good IDM, regardless of the algorithm used to encrypt the data. – Tobi Nary Jan 22 '19 at 08:31
  • I've seen plenty implementations, i.e. more than zero when utilizing password synchronization. That's the nature of password sync since each system you are syncing to has its own hash method so you need the clear text password to be able to sync it. That's the reality of "enterprise" software. – Singleton Jan 22 '19 at 10:17
  • I'm not sure that you can equate IdM with "password syncing" services. Those are different services. Yes, password syncing services would encrypt your password, but I'm not sure that the implication can be that IdM encrypts passwords and sends them on. I think you need to rephrase that part of your answer. – schroeder Jan 22 '19 at 10:43