
OneLogin: Breach Exposed Ability to Decrypt Data - johannsg
https://krebsonsecurity.com/2017/06/onelogin-breach-exposed-ability-to-decrypt-data/
======
graystevens
The recent update from Krebs gives some interesting details into how the
attack took place, something we don't get to hear very often:

 _“Our review has shown that a threat actor obtained access to a set of AWS
keys and used them to access the AWS API from an intermediate host with
another, smaller service provider in the US. Evidence shows the attack started
on May 31, 2017 around 2 am PST. Through the AWS API, the actor created
several instances in our infrastructure to do reconnaissance. OneLogin staff
was alerted of unusual database activity around 9 am PST and within minutes
shut down the affected instance as well as the AWS keys that were used to
create it.”_

Credit where credit is due, that's a pretty quick response time for data
breaches, which are normally quoted as being discovered in an average of 30 or
so days.

However the fact people's information can be decrypted from this breach is
awful. Sounds a lot like the private key to decrypt this information was
stored alongside the data in the database... whoops! That's like storing the
clear text password. Let's hope the decrypted information contains strongly
hashed passwords, but I'm not holding my breath.

~~~
yzmtf2008
Think about a single-sign-on service: by definition, the service would have
the ability to generate/access tokens that would grant a user access to other
applications. Therefore, a breach in any kind of SSO service would result in
granting access to people's information -- no decryption needed!

~~~
vidarh
That's true, but the SSO service itself can run on the users computer, so
there is no need for the service to be able to decrypt the users data, only
for it to be able to persist encrypted data.

------
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...](https://support.onelogin.com/hc/en-
us/articles/201175264-Password-Management)

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

~~~
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.

------
willow9886
This is my primary concern with SaaS identity providers--yes, they are easy to
setup and administrate, but they are huge honey pots.

In addition, customers are unable to do any forensic analysis to determine how
their data was affected.

> OneLogin’s blog post includes no other details, aside from a reference to
> the company’s compliance page.

The only option is to hope they provide customers with relevant information in
a "timely manner", but that could be months for an organization with thousands
of customers.

------
mnm1
'Gartner Inc. financial fraud analyst Avivah Litan said she has long
discouraged companies from using cloud-based single sign-on services, arguing
that they are the digital equivalent to an organization putting all of its
eggs in one basket.'

So it's better if that single point of failure the company puts all its eggs
into is a hacked piece of shit by an engineer who couldn't build a secure
login system if his life depended on it? This is a serious question and one
that I've been struggling with at my current work and at every other job I've
had in this industry without exaggeration. Plaintext passwords, passwords
encrypted with an easily obtainable key, insecure hashes, no salts, etc. These
things are the norm in DIY login schemes. This is what the quoted financial
fraud analyst thinks is better and Krebs thinks is worth repeating? This
should be the main point of discussion here, yet it's brushed off by the
advice of a financial fraud analyst? Oh, our industry is fucked and I just
lost a ton of respect for Krebs' reporting.

~~~
autotune
There are services companies can use as well that offer on-prem, integrated
login solutions, not just DIY.

------
mirimir
> After OneLogin customers sign into their account, the service takes care of
> remembering and supplying the customer’s usernames and passwords for all of
> their other applications.

Isn't that at least somewhat analogous to using the same username and password
on every site?

~~~
subway
Kinda-sorta, in the same way a password manager is. It allows one strong
password/2fa vs many likely weaker passwords.

In reality OneLogin is typically using a federated login protocol like SAML or
OIDC to grant access to third-party services. This means it can also be used
to immediately revoke access, without having to reach out to and reconfigure
various services.

~~~
cube00
For SAML at least if the identity provider is compromised, meaning I can now
issue tokens using it's certificate, each service will need to be provided
with a new certificate. That requires 'reach out' to each service,

~~~
shimms
Yup - we had to reconfigure each service that uses SAML today.

Also don't forget having to audit each service's API keys/tokens/local users
etc to make sure someone hasn't gotten access via a compromised certificate
and then created a sneaky API key for them to use in the future.

Basically we had to assume every app had been compromised and rotate every
internal key/certificate the was in each one, as well as reconfigure them with
a new SAML certificate.

------
jupp0r
I'm not a user of OneLogin, but if they store encrypted passwords _and_
encryption keys, their security model is fundamentally broken imho and I'd
never give them my passwords.

Better services (1password for example) are specifically designed to never
know your master password/key to avoid this very situation.

~~~
izacus
Does any of those better designed services support Linux?

~~~
ascorbic
All of them.

~~~
shimms
Except 1Password - unless you want to use it through the browser only which is
no where near as convenient.

------
brazzledazzle
These SSO providers like OneLogin and Okta are incredibly high value targets.
State-level targets. I predict that SSO providers and security tools (whether
on-prem or SaaS) will be targeted and breached more and more often. The SSO
providers are the middle men for accessing everything so they literally have
the keys to the kingdom. Security tools are given incredible amounts of access
and permissions without question.

As a result of trying to be more secure a big enterprise has gone from maybe a
couple single points of compromise to several. It's not as easy to do script
kiddie-level attacks but the tradeoff is that a very smart and/or well funded
attacker now has some very, very powerful targets.

------
stcredzero
There seems to be a great need for an Open Source password vault
codebase/library that:

    
    
        Runs securely cross-platform, including tablets & smartphones
        Can present a great looking UI across all platforms
        Has no licensing issues in proprietary walled gardens
        Can securely support plugins to integrate with webapps
    

This would enable startups in the personal security space to be able to serve
user's needs for tracking their credentials without creating a high value
centralized store of sensitive information.

------
yolo66
How did this happen ? We see big companies getting hacked all the time, how do
we protect our products ? I'm an engineer, and have no clue about how I could
protect myself against such attacks.

------
rbranson
One thing to remember in all of this is that services like OneLogin are likely
a huge upgrade in security for their customers. They lower the barriers for
moving away from things like shared passwords and poorly functioning in-house
SSO setups.

It's easy for a Gartner analyst to sit behind a desk and pontificate about the
ultimate-most-secure single-sign-on, but resource constraints are a thing.
SaaS SSO is a very reasonable compromise for those who don't have the time,
money, or talent to invest in on-premise infrastructure.

------
dukedougal
How was a central password store ever a good idea?

~~~
jeffnolan
It's not a password store, SSO services like OneLogin are federated services
that authenticate users with encrypted tokens. In a SAML transaction, or with
OAuth, a username/password combination is never exchanged. How is this better,
aside from user experience? For starters, the ability to disrupt access
benefits from a single point rather than having to change passwords in every
app. It also benefits from relying on a credential from a directory service
that can then be used to provision access within the target application, which
means you can have more granular role-based or dynamic access based on
metadata like time of day or geolocation.

------
perseusprime11
I use onelogin. Should I change my password?

------
qrbLPHiKpiux
Come down to this: your most sensitive data is in danger of one misplaced
character or one wrong click.

------
EternalData
I'm thinking of splitting my logins into a set of essential information in a
paper journal -- while keeping some transactional passwords on 1password.
1password was one of those times where I decided to trade off convenience for
absolute security -- which I'm realizing is a mistake.

