-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom active permission #86
Changes from 9 commits
15fbf7f
7a13f4d
aed7556
e928c44
e8fabfd
5ebcbb6
a825307
239b7a2
28f96ba
10fa5ad
815a50c
8591695
824549e
71e57c5
54d0ee6
1083311
189ceec
cb79a4f
e6cc5f1
75faa36
5b5e550
7ae9f94
55aa5b0
ef397f0
bcfa32f
5da66a4
6c64b50
8207e24
e2d9022
fccca20
2bcc40a
4349e8d
2051ff3
6df4a38
ba625b1
1d4aa42
523ed86
07b6fa0
ab5500d
0e8e9ad
e145ede
d5e6f75
15a0514
d77a526
6c7a90a
41a2403
cf72eaa
f0d16bb
63f6ddc
b7282a5
9b07069
12355d6
2222cea
b1864f8
03f24f0
8dce372
34d0086
651e00c
8893727
5d92967
b8f2691
871b93d
d036c8c
ecf22d4
7d1468e
d9466f2
5ddc6cd
40b7ae4
552b5c4
6a00164
5dcf316
3ac2159
f1f9755
0919eae
78100ed
a1ce8ab
e9c8e9b
f9c2df5
bd2af37
0c43bfd
0f2a433
982348c
64338a4
02bb9e5
1d0a341
e749319
51d46da
b560291
b0dfaa5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,87 @@ | ||
BSIP: 0040 | ||
Title: Custom active permissions | ||
Authors: | ||
Alex Megalokonomos <https://github.com/clockworkgr> | ||
Fabian Schuh <https://github.com/xeroc> | ||
Stefan Schießl <https://github.com/sschiessl-bcp> | ||
Status: Draft | ||
Type: Protocol | ||
Created: 2018-07-25 | ||
Discussion: https://github.com/bitshares/bitshares-core/issues/1061 | ||
Worker: <Id of worker proposal> | ||
|
||
# Abstract | ||
|
||
Strengthening user security is one of the main factors to elevate BitShares. Inlight of recent | ||
hacking and phishing attempts this becomes even more important. The need for a more sophisticated | ||
account security preceeded the idea for a finer-grained control of account permissions. | ||
We propose to add an additional authority to the account, called Custom Active (Permission). The | ||
permission contains a list of operationid-to-authority mappings that each grant access to the respective | ||
operation as if it were the active permission of the account. Additionally, the arguments of said operation | ||
can be restricted. | ||
|
||
# Motivation | ||
|
||
Any successfull hacking or phishing attempt on any of the web wallets that are powered by the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Typo: successful There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. done |
||
BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP | ||
aims to ensure all technical possibilities are met while being flexible to allow many use-cases. | ||
|
||
Examples: | ||
- Witness Key: Only allows update signing key and publish price feed | ||
- Trading Key: Only allows limit orders (arguments restricted to desired markets), update margin position and transfers (arguments restricted to certain accounts) | ||
- Proposal Update Key: Approve proposals (2FA comes to mind) | ||
- Faucet Key: Allow only to create accounts | ||
The above list of named keys is nothing that is known to the backend as the backend should have an abstract implementation. | ||
The UI should provide a button "Create Trading Key" that properly configures the respective custom active permission entry. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. UI changes are out of scope for a BSIP. Remove this line, or replace "should" with "could" to make it clear that this is not part of the specification. |
||
|
||
# Rational | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Rationale |
||
|
||
The description here is more on a superficial level and no recommendation how it can best be implemented. | ||
Custom active permission is a list of custom active authorities. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `assert`s than can be used to restricted arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. It also checks if the arguments are in the allowed range. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. restrict |
||
|
||
A Custom Active Permission looks like follows (in JSON for clarification, backend serializes and stores in a different way): | ||
``` | ||
custom_active_permission = list of custom_active_authority items | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just a note: the list here means There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I tried to make that clearer in Rational and Outline of handling incoming transactions |
||
custom_active_authority = { | ||
operationid, | ||
auhtority, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typo |
||
assert | ||
} | ||
``` | ||
|
||
Example: | ||
Assume account A and B and some unrelated key K. Furthermore A has a custom active authority in the following way: | ||
``` | ||
custom active authority = { | ||
operationid: 0 (transfer), | ||
authority: { | ||
threshold: 1 | ||
key_auth: [K, 1] | ||
account_auth: [] | ||
}, | ||
assert: { | ||
to: B | ||
} | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note: this is just an illustration of a possible serialization, not a specification of the serialized format. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added as well |
||
``` | ||
That has the consquence now that a a transfer transaction sending funds away from A can be signed with key K as long as the receiver is B. | ||
|
||
# Specifications | ||
Requirements to modify the backend includes | ||
* Extend the account object to store custom active permission | ||
* Extend `account_update` or create a new operation to allow changing the custom active permission | ||
* Operation-specific authorities (if present) must be evaluated in incoming transactions | ||
* Additional committee parameters may be needed to limit the extend of usage of this feature | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please elaborate:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have included a more detailed description, please see here https://github.com/sschiessl-bcp/bsips/blob/patch-1/bsip-0040.md |
||
# Discussion | ||
|
||
To be found in the [issue](https://github.com/bitshares/bitshares-core/issues/1061). | ||
|
||
# Summary for Shareholders | ||
|
||
Bad publicity in terms of security can have very negative effect on the BTS value. This BSIP allows that traders can e.g. use a trading key, witnesses can use their witness key and a faucet can use a faucet key. If then for some reason the key or witness/faucet server becomes compromised, such a key can do little harm to the account holders, minimizing the risk. | ||
|
||
# Copyright | ||
|
||
This document is placed in the public domain. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"In light" - two words