OneLogin suffers breach–customer data said to be exposed, decrypted | Hacker News Reader

OneLogin suffers breach–customer data said to be exposed, decrypted

arstechnica.com

125 pointsmercutio252 comments

On a tangent, has anyone tried using Vault as a personal keyring, rather than using a cloud based password manager? In particular, how much would I need to trust each device that runs a Vault instance, if I was concerned mainly about malware running alongside it?

Right now, I have everything in Keepass, and no good way to synchronize that between devices. Merging key repos is a royal pain, but mainly, I don't like the idea of trusting everything to an organization that I can't hold accountable. Running my own service on a generic tiny EC2 cluster feels like an improvement, although I would still worry a little about the virtual neighbors.

Please, someone build an open source solution similar to Lastpass backed by a Vault instance with browser plugins and a web front end to allow for key management. That would be amazing.

Lastpass is almost necessary for me to keep all my passwords moderately secure and still usable. But I really do not love trusting all of my info to a 3rd party.

> But I really do not love trusting all of my info to a 3rd party.

You don't need to. You need to trust Lastpass's design.

A Lastpass database is an AES-256 encrypted blob, encrypted using a "slow" hash of your master password (PBKDF2, rounds are configurable). Lastpass don't know your password. When they authenticate you they test to see if your database is decryptable with the password you entered (after it is hashed). If you set 2F then they won't even allow attempts until 2F is satisfied (Google Authenticator is free).

Lastpass's biggest weakness is also applicable to this theoretical OpenSource alternative: Javascript. Javascript is delivered from Lastpass (for the browser extension) and after you decrypt your password database, that JS has full access to it. If a "bad guy" is able to inject evil JS between you and them, then they could trivially steal already decrypted passwords.

As I said, this weakness has nothing to do with Lastpass, it would equally apply to all password managers which integrate into the browser with an extension. In effect you've exchanged convenience for security. And you can already read the Lastpass browser extension's source code, being more open source doesn't make you immune from this issue.

So you can choose to trust Lastpass, or not, but the design is sound. Slapping the words "open source" onto something won't mitigate any of LastPass's inherent design issues, and you'd still want to follow a similar design since it is a good compromise between security and convenience. Coming up with a superior design that doesn't sacrifice convenience would be awesome, but it is a hard problem...

Sure, it can happen to open source; all engineering rules still apply. The attractive part to me would be that there are more eyes on the code.

I would host my own in a google app engine or heroku and avoid a 3rd party who is more attractive to hackers due to the number of accounts they host and potential gain to criminals.

Thats not how many (most?) breaches occur. The situation you would run into (and worry about) is that an exploit is found in the software and then it is mechanized so that things like google app engine and heroku are scanned and user run versions exploited in mass. Open source does not prevent that, only diligent operations do. So by self hosting your are making the bet that you are doing that singularly more competently than the hosted version.

No, open source does not prevent anything. There is just more transparency.

Any self hosting would need to be fully connected with automated update notifications from the "crowd" of contributors and reviewers.

I guess, it becomes a managed service at that point (since as you point out it should have reliable and secure production characteristics which does require a high level of competency). I am imagining a cloud of one for my passwords (a stateless, secure container, with disabled user access to the OS and which connects to an encrypted simple file store to keep my small sized but precious passwords).

Just to be clear: I have nothing against Open Source at all. Open Source is great.

I was just pointing out that Open Source in and of itself isn't a security protection. If you follow the same design you'll have the same design weaknesses, Open Source or closed. The "more eyes" thing, may be true, but I'd argue popularity is more important than license in determining the number of "eyes."

I'd also caution you in assuming an exploit would be against the server side. The server holds a bunch of really hard to decrypt blobs. The client is the real crown jewel. The client browser has all of the usernames/passwords decrypted, so if you were either able to deliver an "evil" extension update, or find an exploit in the existing extension, you could extricate those credentials.

That's the real rub: You turn off extension updates and you're more secure against "evil" extension updates; but you're now more vulnerable to situations where a bug is discovered in the legitimate extension and the organisation pushes a real update to patch that. Auto-updaters in particular are both a huge benefit and a huge security hole.

Thanks for this detailed description!

Is there a way to close the entry point for evil JS? For example, can you tell the extension to stop touching the DOM and injecting any code. That way the username/password can be only interacted with via the browser's chrome button?

No practical one. The extension needs full access to the data in order to push it into a page's forms or to update them via the admin UI ("Lastpass Vault").

I believe the Chrome Web Store does check an extension's signing certificate before updates are published, so security wise that's a good thing, but realistically it remains the weakest part of Lastpass's overall design.

You're right but I would like to point out that a few things actually aren't encrypted in your vault, in particular the URL field of the form. I don't really know if they mine that for info but in theory, they could. And obviously anybody having access to your encrypted blob on your filesystem can do the same.

Also, the extension queries the server to know the number of rounds to use while deriving the master key from the password before it'll deliver the encrypted blob to the client, so in theory if they really wanted to break your password they could tell the extension that it's encrypted with a single round of the hash function (IIRC the minimum is actually two) which would make bruteforcing a whole lot easier, although still very much non-trivial.

> it'll deliver the encrypted blob to the client, so in theory if they really wanted to break your password they could tell the extension that it's encrypted with a single round of the hash function

That's incorrect. When you change the round count your master password is re-computed, and database is re-encrypted with the new hash. The server needs to return the round count so the client can generate the correct master password hash, if you ignore that and simply calculate it for e.g. 2 rounds, the master password hash won't match and therefore the AES-256 database won't decrypt.

The way Lastpass works is straightforward... PBKDF2(password, rounds) -> AES256(hash, blob). If the rounds change then the resulting hash changes and therefore the database won't decrypt. Your second paragraph is quite confusing, in that I cannot make heads or tails of why you think you can use 2 rounds when e.g. 10,000 are specified previously. A correct round count is just as vital as a correct password in generating the correct hash.

I'm talking about the authentication to the lastpass server, not the decryption itself.

Lastpass won't serve you the encrypted blob if you don't authenticate with their servers. To do this it computes a different key (using a different derivation function, but using the same "master" password as the encryption key) that it uses to log into the lastpass server.

This key cannot be used to decrypt the blob because of the different derivation function, but the client asks the server how many rounds of the kdf to use for a given user by posting its email to https://lastpass.com/iterations.php . As you can see it defaults to 5000, but the client will gladly accept any value.

Therefore the server can tell the client to send a key derived from only one iteration, it which case this code is run: https://github.com/lastpass/lastpass-cli/blob/623b344e898958...

In other words if an hostile party gets access to the lastpass server they can instruct your client to send your master password protected by two rounds of sha256. If you have a strong password (as you should) it's not an issue, but clearly you can't count on thousands of rounds of the KDF as you might think.

> they test to see if your database is decryptable with the password you entered (after it is hashed).

At which point they have full access to your database, don't they?

> And you can already read the Lastpass browser extension's source code

Of course, it's a bit more difficult, I'm betting it's minified.

High profile open source encourages people to read the source code, if nothing else. It's possible someone would've noticed that nasty cross-domain autofill bug from a while back (https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...). It's also possible that the community would hold the codebase to a higher quality standard, and a lot of issues would go away (only a rumor, but I've heard that parts of the LastPass codebase are a mess).

Yeah, implementing a Vault client in the browser is just asking for trouble. Currently, I am copy-pasting into the browser, which has two obvious vulnerabilities: the clipboard, which is accessible to everything, and the login page, which could be running an XSS exploit.

Perhaps we could eliminate both problems, by handling authentication outside of the browser, and then injecting an auth cookie into a new browser tab?

  1. `curl site.com/login` to get the login form as HTML
  2. Extract the form submission URL and the name of the user/pass fields
  3. Pipe a key from Vault, to a URL encoded HTTPS POST request (curl again)
  4. Receive the resulting session cookie and the login-success URL from the login response
  5. Insert or replace this cookie into Firefox's jar
  6. Open a new browser tab to the login-success URL

This way, the browser never sees the password, and the clipboard never holds it. The session cookie is still just as vulnerable as ever, but is of a lower value, assuming that it alone does not grant the ability to change the user's password or PW recovery email address. The entire sequence could be scripted into an `authenticate my-user@site.com` command, which would depend on a connected Vault client (or some other backend scheme). I have no idea if this would work on mobile operating systems, it might not be possible to write to the FF cookie jar from another app.

I don't know what options are still available, but the "3rd party" thing is why I ended up paying $100 or something to purchase 1Password back when it was still only available as a one-time-purchased standalone app.

Even if it's open source, I'm in no position to effectively evaluate their crypto/etc. But I can do some basic reasoning about the possible attack surfaces.

With 1Password I hold all my data, and the software that I use to view it runs completely independently of anything else. Besides a takeover of my local machine or breaking the encryption, nobody gets my data.

With something like LastPass, they hold all my data. The software that I use to view it runs in my browser. The software handling all my passwords is running in the same program that I use to execute untrusted code from the internet thousands of times a day. This has bitten them in the ass a few times.

I'd love an open source password manager solution given the turn 1Password has taken towards being a "cloud service", but for the love of god can it please be useful without tying it to my web browser.

The standard advice here is to throw your KeePass vault onto Dropbox/Google Drive/OneDrive, but I agree, keeping everything sync'd is a PITA. It's a problem that needs solving, but KeePass itself is probably not keen on solving it.

Keepass2 actually has reasonably good built-in merging. There are also sync plugins which could help with the cloud provider's own collision copy issues

I've been sort of sketching out a system for this in my spare time.

Something like a portable container that you can host anywhere and keeps syncing easy. What kinds of other features would you want?

I use KeePass2Android and merging works very well with it. It just automatically reads from my Dropbox file and merges any changes.

This is probably not a good solution for the vast majority of people but it works well for me: I use pass[0] but I host my ~/.password-store on a sshfs on a server I own. Wherever I need to access my passwords I just mount the sshfs and then can proceed as normal.

Since pass supports versioning the passwords with git it would also be possible to use that, just push/pull the repository to keep it in sync. It would also give you access to the password even while offline, but I actually prefer the added security of not copying the passwords over, even encrypted.

Obviously if you want to access your passwords from, say, a Windows machine or a smartphone it won't quite do the trick.

[0]https://www.passwordstore.org/

Similar to "pass" is "hunter2" ( https://chiselapp.com/user/rkeene/repository/hunter2/ ) which uses a hardware security module such as a smartcard to decrypt the password and allows sharing between users in a file that can be managed by a version control system (such as Fossil or Git).

Hunter2 sounds like a reference to this: http://bash.org/?244321 Amusing if true, both dealing with passwords so it's likely.

It is. There are several references to that on the page and in the source.

I actually already do that with pass and a GnuPG smartcard since pass uses gpg to handle the encryption.

You can also provide several PGP encryption keys if you want to share your passwords across several people. I believe pass lets you specify the keys on a per-directory basis, although I never actually tried to do that myself.

hunter2 makes multiple users a first class principle. Anyone that has access to decrypt a password can add other users to that password, in the future if that password is updated all users that have access retain the new password

I understand the problem you're having with keepass. My solution for it was to store the kdbx in cloud storage then access it with a nice service called https://app.keeweb.info/. This means remembering two passwords, one for your cloud storage, and one for your kdbx file. Keeweb is open source and can be used without an internet connection if you would like to use it as your primary keepass client https://github.com/keeweb/keeweb

One thing I have always wondered: how do companies like this actually detect such a breach in the first place? HTTP and SSH log files?

Also, how do they ensure that their systems are no longer compromised?

Of the 6-7 breaches I've heard the details of, they were detected because either:

- an engineer stumbled upon clear evidence of a rootkit, like a leftover dotfile or shell history entries

- the exfiltrated data got used and someone noticed

(Different story for active intrusions, where the intruder is detected when they first breach a system. At least anecdotally, the passive after-the-fact detection above seems more common, though.)

Thanks for your reply.

I assume many startups use AWS or GCE (with auto scaling) and thus don't necessarily setup/SSH into each and every machine/VM. Wouldn't this make rootkit detection more difficult?

edit: how would an active intrusion detection take place?

You don't have to ssh in to a system in order to detect a rootkit or intrusion. You could run a rootkit detection app like rkhunter[1] or chrootkit[2] (though I don't know how good these programs are at doing what they claim to do) or run a filesystem integrity monitoring app or HIDS[3] like Samhain[4]. You might also pick up intrusions via a network intrusion detection system like Snort[5].

[1] - https://en.wikipedia.org/wiki/Rkhunter

[2] - https://en.wikipedia.org/wiki/Chkrootkit

[3] - https://en.wikipedia.org/wiki/Host-based_intrusion_detection...

[4] - https://en.wikipedia.org/wiki/Samhain_(software)

[5] - https://en.wikipedia.org/wiki/Snort_(software)

> don't know how good these programs are at doing what they claim to do

They're good for checking old backups to see if you were hacked in the 90s, not so useful for today.

The first two, sure. Snort, at least, remains under active maintenance, and while I'm not in network security myself any more, those I know who still are have had good things to say about it.

So what would you use today?

I don't think there is any useful software intended for the same purpose as those two. You'll need something like Samhain to spot the breach when it happens.

It will definitely require some configuration, but AIDE is an awesome tool. You take hashes of files when they are in a known good state (and are not supposed to change) and then monitor them for changes.

http://aide.sourceforge.net/

It takes a good amount of setup because there are a lot of files that routinely change that you will want to ignore.

For a really great book about an Active Intrusion this is a classic. https://www.amazon.com/Cuckoos-Egg-Tracking-Computer-Espiona...

Is this the one that started to realise what was happening due to unpaid time on a machine amounting to 25c or similar?

That's the one. I remember reading it in 1991 or 1992, and just having my mind blinded by the whole story.

Yup. Cliff Stoll. His first book is a great read. The second as well, but he caught a lot of flack for his 'Luddite' views. Personally, and with the aid of hindsight, I think he just undershot on his predictions.

I think so. It's also the one in which the protagonist stalled the attacker by means of a keyring, which is not so much a thing you can do any more.

I re-read Cuckoo's Egg recently, and it was still a riveting read! Especially when considering that it all happened over telnet.

LastPass issued a security warning in June 2015 that was originally triggered by their having detected network activity from an unknown source. For what it's worth, their handling of this event was the reason I adopted LastPass.

https://blog.lastpass.com/2015/06/lastpass-security-notice.h...

I don't trust putting all my passwords into the hands of another system for this reason.

The threat model these defend against best is using a single login and password across a host of secure and unsecured systems out of convenience.

Some pass managers are better than others and on balance are better than the solutions non-technical (and many technical) would otherwise use. This is highly dependent on your threat model, degree of technical skill, actual data risk, and behavior.

They aren't a password manager, but a SSO provider. The downside is also the upside. If a credential is leaked, having a single provider makes it easy to revoke access to all systems.

Another tangent: I see OneLogin, on their main site, lists the customers using their solution. I know this is a very common practice, but can anyone explain any (not short-sightedly financial) benefit possible for a company allowing this disclosure?

Sure! I can offer one reason that isn't purely "because we got a discount".

Imagine that you're a company not necessarily known for security prowess. Now imagine that you want to be able to demonstrate to users / customers / investors that you take security seriously and work with reputable vendors. You could list off the vendors you use, but then they're just taking your word for it. Wouldn't it be better if the vendor listed you?

Alternately, perhaps there are common investors or board members exerting influence.

Pricing. Sometimes you can get better contract terms by allowing them to cite you as a customer. Usually pricing, but there are other terms you may negotiate as well.

As a side note... I imagine well probably see some of those customers coming down soon.

In addition to to what the others have said l, sometimes the other business is willing to be a reference because they're happy with the product and want you to succeed. After all, they're using your product, its in their best interest that you succeed.

Discounts, etc.

But usually these lists of "customers" is just someone trawling the user database for @foocorp.com and anyone signed up from there makes the company a "customer".

There are reasonable answers in this subthread but don't discount the simplest one, which is that they asked and nobody at the client thought about it for more than 15 seconds.

Or the even simpler answer, which is that they didn't ask.

We put logo privileges in our standard contract just to see what would happen, and we got it a bunch.

This is why I won't use mint.com for anything but my credit cards.

Reply on news.ycombinator.com