Sorry, but this sets off my bullshit detector. If someone compromises your server he also has access to the routines decrypting the ssh keys. How do you encrypt them?

Hi - It's not enough to compromise the Bastio servers. Some of the data facets needed to successfully decrypt the SSH keys are stored securely in the browser. This is why we can't deploy OS users or keys if a Bastio user is not logged in and active.

That is better but not good enough. If your servers were compromised, that attacker could add JS code to your page that quietly farms that facets that are securly stored in the browser, when the user logs in.

Makes it harder against a targeted attack, but does nothing for the average user.

You can mitigate the problem by having a really good intrusion detection system, but not eliminate it.

It's harder than it sounds, as we use HttpOnly cookies and, much more importantly, have little to no XSS attack surface.

As far as injecting JS after server compromise: At that point, an equal concern is really attacker access to application memory, as we protect against the (admittedly edge) case where the attacker replaces the served Javascript but doesn't have access to memory. We've taken steps to reduce the opportunity for memory compromise.

Also, we are actually working on a reaction-oriented intrusion detection system that will take appropriate actions when invariants are tripped. But more importantly, we're moving to the daemon model, where customers have much more control over the security of their systems at the network level.

Many service providers, including DNS and hosting providers, use web-based control panels and must properly secure their systems. It's not a requirement that's unique to us. If you offer SaaS, you have to lock it down.

Of course the requirement exists for all SaaS providers. But while a break in on Evernote reveals my notes (which would be bad, but not lethal), a break in at bastio might compromise the servers where I host my SaaS products, triggering a very nasty chain reaction.

So while the risk you face may be the same, the damage that can be done is vastly greater. But I'm sure you're aware of that.

Assuming someone gains root level access to one of the boxes bastio is hosted on, then he could

1a. block all outgoing traffic from the server except for the service (to avoid alarms getting through) or 1b. replay the heartbeat sent by the server 2. retrieve the database 3. Sniff on all incoming traffic for the HttpOnly Cookies

The worst thing is you might not even know which customers' keys are compromised.

I'm sure you are thoughtful about security, but of course you are a great target because of the valuable loot (root access lot's of other servers)

A lot of your concerns are considerations for me too as I am thinking of launching a distributed SaaS. Just take it as input to your threat analysis :)

Yeah, definitely, it's all an input to the threat analysis. Thanks for the great discussion. It's interesting stuff and fun+important to just think through.

Yes, you're right that someone could intercept the HttpOnly cookies, but as you said, only if they were able to compromise the server, since we use SSL and won't have any XSS surface.

Also agree that alarm or heartbeat-based IDS stuff won't cut it here. We're working on an (agent-based, with signed code deployments) IDS (https://sentryhq.com/) that sits on the server and makes decisions to take certain actions not just when an attack matches some probably-out-of-date rule, but when some ever-growing list of invariants change. It's kind of like what banks use, except it responds automatically.

We will eventually be able to overcome all of these concerns (in the daemon-based model, wherein we don't store server keys) by validating OS user key distribution commands with secure emails to the people who requested them + nonces for confirmation. At that point, if we can enforce best practices amongst our customers, we can probably reduce the security problem to the trust problem, which is as solid as can be expected.

Actually, what do you think about such an IDS? Usually the tactic is "let my admins respond," but you are quite correct that that isn't sufficient, as your IDS may pick up the attack but the response may never come. We are thinking that the response isn't usually fast enough either.