{"action":"opened","issue":{"url":"https://api.github.com/repos/steemit/steem/issues/2504","repository_url":"https://api.github.com/repos/steemit/steem","labels_url":"https://api.github.com/repos/steemit/steem/issues/2504/labels{/name}","comments_url":"https://api.github.com/repos/steemit/steem/issues/2504/comments","events_url":"https://api.github.com/repos/steemit/steem/issues/2504/events","html_url":"https://github.com/steemit/steem/issues/2504","id":327128592,"number":2504,"title":"Privileged API implementation strategy","user":{"login":"theoreticalbts","id":10215982,"avatar_url":"https://avatars3.githubusercontent.com/u/10215982?v=4","gravatar_id":"","url":"https://api.github.com/users/theoreticalbts","html_url":"https://github.com/theoreticalbts","followers_url":"https://api.github.com/users/theoreticalbts/followers","following_url":"https://api.github.com/users/theoreticalbts/following{/other_user}","gists_url":"https://api.github.com/users/theoreticalbts/gists{/gist_id}","starred_url":"https://api.github.com/users/theoreticalbts/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/theoreticalbts/subscriptions","organizations_url":"https://api.github.com/users/theoreticalbts/orgs","repos_url":"https://api.github.com/users/theoreticalbts/repos","events_url":"https://api.github.com/users/theoreticalbts/events{/privacy}","received_events_url":"https://api.github.com/users/theoreticalbts/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-05-28T22:46:17Z","updated_at":"2018-05-28T22:46:17Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"\r\nCurrently, most/all of the implemented API's are fairly harmless if publicly exposed.  At some point in the future, we might want to create API's that control node behavior, such as real-time alteration of:\r\n\r\n- Various aspects of the p2p networking\r\n- Pausing/unpausing block production\r\n- Changing logging behavior\r\n- Enabling/disabling other API's\r\n\r\nObviously, the general public shouldn't be allowed access to API's that do this kind of stuff [1].  The question is, how does an administrator sending a request to such an API authenticate themselves to `steemd`?\r\n\r\nHere are the options as I see them:\r\n\r\n- No authentication.  To keep the general public out, nodes that enable dangerous API's must bind RPC's to `localhost` or operate on a trusted non-public network.  If you can make the TCP connection, you're assumed to be authorized to make the API call.\r\n- Multiple TCP sockets.  Implement configuration to allow different (sets of) API's to be bound to different hosts/sockets.  This is like \"No authentication,\" but it allows network-level protection to be applied to a subset of API's, instead of being all-public or all-private.\r\n- HTTP Basic authentication.  HTTP has a standard for this.  It's not that great, the credentials aren't encrypted.  Requires maintaining a username/password database of who's allowed to access what.\r\n- HTTP-header-based shared secret authentication.  Basically store the value of `H(body+api_token)` in header.  Secure, requires a token database of which tokens exist and what they're allowed to access.\r\n- Signed requests.  Require public key signature to accompany requests, deny the request if not signed by a trusted key.  Requires a database of trusted signers.  (We can leverage the blockchain and have trusted signers be blockchain accounts.)  Requires clients to have private keys and be able to sign with them.  `jussi` / `condenser` may have some implementation work already on a system like this, maybe if `steemd` grows a native system the two systems should try to be compatible with each other?\r\n- Stateful login.  BitShares implemented an HTTP Basic-like system based on stateful Websocket requests.  Essentially when a WS connection is established to a node, you can access some API's right away.  For other API's, you need to first log in with a username and password.  Then you would be granted access to any other API's your user is configured to be able to access.  This system was never used to its potential in BitShares, and people mostly seemed to find it a hard-to-understand quirk that needed to be worked around, not a useful feature.  It goes against Steem's REST-ful model where API's are all stateless, all the time.  I don't think we should implement any kind of stateful login in `steemd`, but I include the idea here for completeness.\r\n\r\n[1] A node operator who left these functions open to the public would be subject to all kinds of attacks, mostly involving either giving the node operator or other users an incorrect view of the blockchain state by manipulating the p2p network, or various flavors of denial-of-service.\r\n\r\nExposing these functions to the general public wouldn't harm the blockchain itself, it would just cause confusion/inconvenience to the misconfigured node and its users.\r\n"}}
{"actor":{"display_login":"theoreticalbts"}}