August 2016 Incident | Hacker News Reader

August 2016 Incident

onelogin.com

36 pointsmarcins19 comments

So.. they send data to their servers unencrypted? That's a serious design flaw right there. That they do any encryption (besides HTTPS) server side should be a red flag for any secrets store.

Seems more likely that they use HTTPS and this is "just" an issue with cleartext logging (i.e. some server component logs unencrypted data after TLS termination).

I think OP is referring to client side encryption instead of encrypting it on the server for storage.

You're right, that makes more sense

Agreed 100%. With something like LastPass, they never actually have your enencrypted data at any point. So a logging bug (probably somebody logging the payload, etc. accidentally) wouldn't matter.

This is really concerning for a company that offers IAM as a service. IMO this is straight up incompetence.

LassPass doesn't have your data as long as you trust their javascript. That's not really very comforting IMO.

Every commercial password manager is a security risk. Each company's product uses official applications (whether on desktop, mobile, or browser) provided by them. The applications are in theory coded to keep cleartext credentials sandboxed and unavailable to the company. That simple fact is a) not a guarantee - applications are binary installs so you have no idea what the application is really doing; and b) even the most secure application is a single accidental or intentional software update away from leaking/stealing the entire unencrypted contents.

I don't know if LastPass is the same, but 1Password has a browser "application" (regular old web page hosted on their servers) that keeps your credentials in the browser's local storage. While they technically don't store your credentials on their servers, that web app is a ticking time bomb for a cross-origin attack, someone managing to slip in one line of javascript in a commit, or any of your browser extensions/addons being compromised.

If you're reading this and are a software developer, think back to all the horrid code and glaring security holes you've seen at most companies you've worked for. Then consider that the type of developers and managers who are rushing deadlines at these password manager companies are no different. These products are not being designed or developed by top security professionals, but rather by everyday developers - most of whom likely know very little about encryption and security outside of what their language of choice's libraries make easy to use. Even if a password manager were to be written exclusively by the single best security professional on the planet and audited by the next top 100, again there is no guarantee for there to never be an accidental or intentional update or hack.

Consider what you are storing in a password manager. Full access to banking, including your life savings? Logins to your government's sites with sensitive data? For most of us, having a single moderately or critical account hacked would cause havoc. Imagine what happens if someone ever gets ahold of the entire contents of your password manager. It's identity theft taken to the maximum possible extreme. Two-step authentication (a la Google Authenticator) is an additional layer for many accounts, unless of course you're using something like a combination of LastPass's password manager and their separate 2-step auth app, in which case that one company exposes you to a single point of total security failure.

The idea of a commercial password manager being run by an everyday software development shop scares the crap out of me. I won't touch them with a 10-foot pole.

This!

If I could upvote it more than once, I would do it in a heartbeat!

Here are recent LastPass vulnerabilities: http://www.theregister.co.uk/2016/07/27/zero_day_hole_can_pw... https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...

Yeah, they have to because of how they work. As much as possible they do via SAML, and for that no plaintext is needed. But a lot of their customers want to log in to sites that don't support SAML (it's hard). For those they do form stuffing - naturally that requires plaintext.

Source: worked in the industry at a more security-focused company, had to explain to sales/support a few times why they can support a site but we can't.

Pet peeve of the day.

Tried to right click on the header logo so I can check out their main site in a new tab.

Instead I'm blocked and get prompted to download their brand assets...

Please don't mess with established interactions.

Very interesting. Do they really think that people use right click on the logo to get their logo?

Also, I use Cmd + Click more than right click -> open in new tab.

> multiple levels of AES-256 encryption.

crypto cringe - this instills just as much confidence as saying "WE USE MILITARY GRADE ENCRYPTION PROTOCOLS"

IRONIC NEWS FLASH OF THE DAY: OneLogin employees to store their credentials in LastPass to prevent any further compromising of passwords...

This is why one should always, always use client-side encryption. Want to encrypt to the server? Sure, fine, there are good reasons for that interaction to be encrypted. But there are good reasons for one's data to be secured from the server as well.

Any protocol in which a malicious server can do more than deny service is broken.

I'd love to know which logging server they had exposed to the internet. Putting all infrastructure on a private network is security 101.

That is my question too - how was an internal logging server not set for restricted login only from the internal subnet?

Also - they mentioned the perp got in via a compromised employee login. No clarification if it was a former disgruntled employee, or that a current employee had a weak password, or was social engineered into divulging it.

In any case, it points to bad internal policies and procedures around isolating servers and employee password management.

Especially ironic since they do "Identity Management as a Service": https://www.onelogin.com/why-onelogin/strengthen-security

If it was a compromised employee login it could have been an indirect path to the log server. E.g. ssh or "Go to My PC" to employee workstation, or log in to company VPN, from there to internal hosts.

Not that employee workstations should have access to production machines ideally, but it is commonplace at small companies (and big ones too).

Reply on news.ycombinator.com