password-auth the web interface

[pfrazee]

Phoenix uses an HMAC to authenticate (https://github.com/ssbc/phoenix/blob/master/domain-auth.js#L11-L21). The server for /access.json denies requests from remotes, but that doesn't stop webpages. We can deny requests with a Host header, but I'm fairly certain sites can find ways around that.

I'd feel safer putting a password on the web interface, and using cookies to maintain a session.

EDIT: correction, it's the Origin header I'm thinking of

[dominictarr]

security needs to be done a bit more clearly than "feel safe". can you spell out the problem here in more detail? do you mean browsers open in your local browser can open /access.json?

[pfrazee]

first I have to correct my original post-- I had forgotten how tight the browser is about single-origin policy. in the current phoenix/sbot, it's not possible to fetch /access.json cross-domain from a webpage

---

ok, the three things I'm concerned about

1. webpages making cross-domain requests. this is supposed to be prevented by single-origin policy, but I wonder about flash, java, silverlight, etc
2. browser plugins and apps getting access, since they dont have SOP to deal with
3. tunneling

after digging a bit, I found 1 (SOP breaks) to be pretty hard to do; circumventing SOP is considered a security exploit so browser-vendors are watching for it. still, vulnerabilities do happen, and it would be better if a exploit had to steal cookies, not just break SOP. (maybe we could even find a way not to use cookies?)

2 still concerns me; our base authentication model is, "if you can read the keyfile, you can get master access," which means

• a program needs filesystem read-access to authenticate as master, and
• usergroup file-perms can be used for protection.

but with /access.json, the authentication model is "if you can create an HTTP request with the right Origin header, you can get master access" which is much looser. I was able to get /access.json with the Postman chrome app without any perms prompt, which isn't great. Filesystem access is much more controlled in chrome apps (https://developer.chrome.com/apps/fileSystem)

I witnessed 3 happen the other day, when a friend installed a traffic tunnel on his laptop so he could run the pub from home. turns out, the requests coming through the tunnel looked like they came from localhost, so i was able to read /access.json using the tunnel. (I told him to shut it down.)

[dominictarr]

Aha, okay this is much better!

So, I have been developing my security thinking recently - of course, it's important to get security right before hand, since you don't tend to get notified about errors as they happen.

look at my approach for the secure channel: https://github.com/ssbc/scuttlebot/wiki/secure-private-channels:-the-good,-the-bad,-and-the-ugly

summarize the various approaches that can be used, including step by step description of the process, and what security properties are ensured on not, and at what time. I found creating an overview like this gave me a very good idea about what properties where possible. I then summarized those here: https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel

Then, I when I designed a solution, I was able to meet nearly all the security properties desired: https://github.com/ssbc/scuttlebot/wiki/a-secure-secure-channel-(WIP) (I've actually got a better design that I think does everything now, but it's currently in my notebook)

This way, you make clear claims about what security properties you are going for, and what weaknesses you are exposing / data you are leaking.

Also, are there other systems that do something comparable? like oauth?

[pfrazee]

I think that's a good idea, clear documenting is good for outsiders evaluating and for implementers thinking through the problem

We could broaden this issue's scope to "authentication," which really needs a good treatment

Do you have the bandwidth to take this on? I've got a list of tasks I want to nail in the nearterm (1/2 months) and this is on it but more near the bottom

[dominictarr]

yeah. right now I'm working on the secure-channel, but i'll tackle this next.

[dominictarr]

no longer relavant since we now have an electron app