Mixing
How do universities and schools securely sync passwords between multiple services?
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?
passwords single-sign-on
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
|
show 1 more comment
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?
passwords single-sign-on
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
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 at 15:28
4
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 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 at 23:28
1
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 at 16:02
@BenVoigt Sure, to a point. The distinguishing factor being that if I tell you I have an account calledbobwhose password hashes toABC123, it's stored in your own system.
– Blrfl
Jan 21 at 23:27
|
show 1 more comment
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?
passwords single-sign-on
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
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?
passwords single-sign-on
passwords single-sign-on
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
edited Jan 20 at 15:27
schroeder♦
77.1k30171206
77.1k30171206
asked Jan 20 at 15:19
darknissdarkniss
30125
asked Jan 20 at 15:19
darknissdarkniss
30125
asked Jan 20 at 15:19
darknissdarkniss
30125
30125
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 at 15:28
4
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 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 at 23:28
1
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 at 16:02
@BenVoigt Sure, to a point. The distinguishing factor being that if I tell you I have an account calledbobwhose password hashes toABC123, it's stored in your own system.
– Blrfl
Jan 21 at 23:27
|
show 1 more comment
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 at 15:28
4
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 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 at 23:28
1
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 at 16:02
@BenVoigt Sure, to a point. The distinguishing factor being that if I tell you I have an account calledbobwhose password hashes toABC123, it's stored in your own system.
– Blrfl
Jan 21 at 23:27
17
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 at 15:28
I added the Single-sign-on tag because that's actually what you are talking about (and it's the answer).
– schroeder♦
Jan 20 at 15:28
4
4
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 at 19:58
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 at 19:58
2
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 at 23:28
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 at 23:28
1
1
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 at 16:02
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 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 at 23:27
@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 at 23:27
|
show 1 more comment
2 Answers
2
active
oldest
votes
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.
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
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
Jan 20 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 at 9: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 at 18:24
add a comment |
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.
answered Jan 22 at 8:06
SingletonSingleton
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 at 8: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 at 8: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 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 at 10:43
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201836%2fhow-do-universities-and-schools-securely-sync-passwords-between-multiple-service%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
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
Jan 20 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 at 9: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 at 18:24
add a comment |
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.
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
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
Jan 20 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 at 9: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 at 18:24
add a comment |
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.
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
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.
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
answered Jan 20 at 15:46
multithr3at3dmultithr3at3d
4,68511427
4,68511427
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
Jan 20 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 at 9: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 at 18:24
add a comment |
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
Jan 20 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 at 9: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 at 18:24
20
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
Jan 20 at 20:01
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
Jan 20 at 20:01
7
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 at 9:53
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 at 9: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 at 18:24
@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 at 18:24
add a comment |
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.
answered Jan 22 at 8:06
SingletonSingleton
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 at 8: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 at 8: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 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 at 10:43
add a comment |
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.
answered Jan 22 at 8:06
SingletonSingleton
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 at 8: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 at 8: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 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 at 10:43
add a comment |
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.
answered Jan 22 at 8:06
SingletonSingleton
1
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.
answered Jan 22 at 8:06
SingletonSingleton
1
answered Jan 22 at 8:06
SingletonSingleton
1
answered Jan 22 at 8:06
SingletonSingleton
1
answered Jan 22 at 8:06
SingletonSingleton
1
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 at 8: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 at 8: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 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 at 10:43
add a comment |
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 at 8: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 at 8: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 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 at 10:43
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 at 8:24
Really, encrypted passwords, with AES, not hashed with $somethingappropriate? Are you sure "all cases you've seen" are not zero?
– Tobi Nary
Jan 22 at 8:24
1
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 at 8:31
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 at 8: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 at 10:17
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 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 at 10:43
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 at 10:43
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201836%2fhow-do-universities-and-schools-securely-sync-passwords-between-multiple-service%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 at 15:28
4
For educational institutions in the US, Internet2 drives a lot of identity management work. Shibboleth is common in Universities to provide the actual sign-in APIs, and InCommon allows federation (i.e. cross-university authentication for features like eduroam).
– user71659
Jan 20 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 at 23:28
1
@Blrfl: That sounds indistinguishable from single sign-on with replication to local mirrors.
– Ben Voigt
Jan 21 at 16:02
@BenVoigt Sure, to a point. The distinguishing factor being that if I tell you I have an account called
bobwhose password hashes toABC123, it's stored in your own system.– Blrfl
Jan 21 at 23:27