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

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