The recent update from Krebs gives some interesting details into how the attack took place, something we don't get to hear very often:<p><i>“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.”</i><p>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.<p>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.
Lots of confusion in all the posts about OneLogin - they are <i>not</i> 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.<p>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.
This is my primary concern with SaaS identity providers--yes, they are easy to setup and administrate, but they are huge honey pots.<p>In addition, customers are unable to do any forensic analysis to determine how their data was affected.<p>> OneLogin’s blog post includes no other details, aside from a reference to the company’s compliance page.<p>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.
'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.'<p>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.
> 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.<p>Isn't that at least somewhat analogous to using the same username and password on every site?
I'm not a user of OneLogin, but if they store encrypted passwords <i>and</i> encryption keys, their security model is fundamentally broken imho and I'd never give them my passwords.<p>Better services (1password for example) are specifically designed to never know your master password/key to avoid this very situation.
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.<p>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.
There seems to be a great need for an Open Source password vault codebase/library that:<p><pre><code> 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
</code></pre>
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.
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.
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.<p>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.
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.