[manigandham]

Lots of confusion in all the posts about OneLogin - they are not a password manager like lastpass, they are a Single Sign-On (SSO) and Identity Provider, meaning they integrate with other services, maintain a master directory of all users, and provide a single login UI for all connected apps.

Companies use OneLogin so employees have 1 service to enter their credentials and can then use federated access to apps like Google, Office 365, Salesforce, etc without signing in again, most often connected via SAML which uses public/private keys. The identity provider can also be external, so for example users can sign-in via the OneLogin UI but the username/password are actually authenticated against Office 365 Active Directory instead.

[sbarre]

From reading many articles, it seems that OneLogin does have a service called "Password Cache", which sounds to me like a cache for passwords, perhaps for storing credentials to sites that do not have SSO..

See here: https://support.onelogin.com/hc/en-us/articles/201175264-Pas...

If they are storing the password and pushing it to the connected service on the user's behalf, then they have to be able to decrypt it somehow, and if the bad actor was able to intercept and decrypt data within the platform, then that may have included passwords stored using this mechanism perhaps

[stcredzero]

If they are storing the password and pushing it to the connected service on the user's behalf, then they have to be able to decrypt it somehow

By storing so many passwords in one system, they made that system a high value target, all while not having the security chops they thought they had.

Password vaults should be distributed. This prevents the conglomeration of password secrets that creates a high value target. They would've been wise to have a series of password vault apps that are integrated with their system. They could have done this by leveraging Password Safe.

[jacquesm]

This is by far the best argument for decentralization of almost anything that is not meant to be public. You probably will lose some of it but at least you won't lose all of it.

[danbruc]

If they are storing the password and pushing it to the connected service on the user's behalf, then they have to be able to decrypt it somehow [...]

But not necessarily all of them all the time. The decryption key could be derived from the master password of each user and only kept around while the user is logged in.

[brazzledazzle]

That wouldn't work, at least for a lot of customers, because they authenticate a user based on a chain of trust back to the customer's on-prem Active Directory instance. An agent running on the customer's infrastructure leverages Kerberos/NTLM to authenticate the user then passes a token back to the identity provider. As a result there are authentication flows where the provider never sees the password.

Many providers do have an agent that runs on the AD servers that MitM captures the passwords when the user rotates them but that's a lot more involved to get setup. They could either force use of that AD agent or remove the functionality entirely and force users to manage a password with the service but it would either make on-boarding slow/impossible or really reduce the convenience factor for users. It's something every identity provider would need to do (or be forced to do) because the ones that didn't would steal away all of their customers.

[sbarre]

That depends on how the service works I suppose. Does a user have to enter a master password when they log into OneLogin, or does an SSO service authenticate them to OneLogin, which then logs them into Twitter/Facebook/etc?

If the latter, then OneLogin has to possess the ability to decrypt the passwords without user input (edit: although I suppose the SSO token coming from the client could be the key? I don't know if that's possible or how that would work - the key would still need to be cached for some period of time post-auth either way I would think)..

[idunno246]

The other big thing is lots of saas companies don't implement multiple users per company initially, so you end up with a google doc with all the shared passwords of things like analytics/ads providers. This way you get a unique login, acls, etc by hiding the shared password inside onelogin

I've used these, but refused to put more important things like aws in there.

[jeffnolan]

it's a semantic argument. You are not storing passwords in an SSO service, but it is passing tokens to authenticate access based on the asserting/relying relationship between IdP and app. The reason I say it is semantic is that while you are not storing passwords, you are sitting on a trove of access credentials. What is different about an SSO app that is of huge value is that cutting off access is not a function of changing passwords at the app level.

I think we agree on all the major points here, but I would not diminish the significance based on the fact that OneLogin is not a password vault.

[EduardoBautista]

OneLogin also stores passwords like 1Password. I used to work there.

[manigandham]

It's a purely informational comment about what the service is, not about the significance of the security breach.

Any identity related service, especially one that also includes password manager and desktop login functionality along with secure notes, etc. being involved in something like this is a major issue. We were looking at using them but have decided to stick with Google instead.