Comments (18)
From @VoR0220 on July 1, 2015 0:58
how far do our authentication efforts have to go? I assume this is trying to prevent an Eclipse attack...but what should the user have to give up in order to (attempt to) ensure that they aren't a bot in the network? Perhaps hard coding in witnesses/delegates/workers IP address would help prevent an Eclipse attack from taking over the entire routing table of a user?
from bitshares-core.
From @nathanhourt on July 1, 2015 14:20
This isn't about eclipse attacks, it's just about preventing an unauthorized party from seeing or modifying sensitive node state.
from bitshares-core.
From @jcalfee on July 1, 2015 15:48
For a hosted wallet, the public API is probably best as a whitelist file where each call is added on case-by-case basis and reviewed for its potential to return too much data, run slow, etc... Even though a call may be safe it is not added to the whitelist until it is looked at and needed. This limits exposure to unknown bugs.
from bitshares-core.
From @theoreticalbts on July 1, 2015 16:15
@jcalfee -- This is the purpose of having multiple API's in the RPC infrastructure. Functions are whitelisted for public use by registering the API's containing those functions to anonymous connections.
The problem is that the way functions are currently categorized into API's has some API's with a mix of public methods (safe for public access and needed by hosted wallet) and private methods (unsafe for public access).
from bitshares-core.
From @VoR0220 on July 1, 2015 21:42
@theoreticalbts @nathanhourt Could you elaborate on the problem that could happen if a node gathers another node's peer list and makes a request for a connection endpoint?
from bitshares-core.
From @nathanhourt on July 2, 2015 16:18
@VoR0220 An eclipse attack is a reasonable exploit of the vulnerability, but it's a more general issue. I might not want third parties knowing how my network is organized. I certainly don't want third parties controlling which nodes I am connected to.
from bitshares-core.
From @VoR0220 on July 2, 2015 18:36
Might one way to solve this be to set it up so that a request only gives you a quarter of the nodes in the list and from there get a quarter from all the other nodes in the list?
from bitshares-core.
From @nathanhourt on July 2, 2015 19:3
The solution is simply to reject access to the network API until the client authenticates.
from bitshares-core.
From @VoR0220 on July 3, 2015 18:8
@nathanhourt I've been trying to find ways to authenticate in a p2p network....any ideas so far about how we go about authenticating the client?
from bitshares-core.
From @theoreticalbts on July 6, 2015 2:26
@nathanhourt The problem is that public [1] access for broadcasting tx's is desirable (maybe with some rate limiting), but access to add_node
should definitely be restricted to node admins.
@VoR0220 Authenticating in a p2p network is a hard problem, which likely ultimately requires some form of p2p PKI (public key infrastructure), i.e. some shared global database mapping entities to pubkeys. Which is a major purpose of the account systems in BitShares 0.x or Graphene. You can also view tx signatures (in any cryptocurrency) as a form of p2p authentication -- itself a kind of PKI. (E.g. in Bitcoin, the script attached to a balance maps an entity -- the owner of that specific balance -- to a pubkey.)
[1] Either truly public anonymous access, or access by ordinary user account (i.e. the account you get if you sign up with a hosted wallet provider as a member of the general public).
from bitshares-core.
From @nathanhourt on July 6, 2015 13:57
Then split the network API into separate APIs -- one for public access and one for administrative access.
from bitshares-core.
From @VoR0220 on July 6, 2015 16:27
@theoreticalbts when you say node admins, are you referring to an authority type? Or might you be referring to a witness? Just looking for elaboration.
from bitshares-core.
From @theoreticalbts on July 6, 2015 17:6
@VoR0220 By "node admin," I was referring to the system administrator of the machine where the node is running.
from bitshares-core.
From @theoreticalbts on July 6, 2015 17:52
I'm going to take over this ticket. It is clear that we need to simply split the network API into two different API's.
from bitshares-core.
From @VoR0220 on July 6, 2015 17:54
damn...I kind of wanted to try my hand at this....
from bitshares-core.
From @theoreticalbts on July 8, 2015 18:4
We still need to audit all calls and review, for each call, why public access is safe.
from bitshares-core.
This TODO
also needs to be addressed: https://github.com/cryptonomex/graphene/blob/a751d90e000903821ad8a096079d0bdb19f4f948/libraries/app/application.cpp#L231-L240
from bitshares-core.
This has been done.
from bitshares-core.
Related Issues (20)
- Update pre-built binaries with the latest security updates from time to time
- Phase out Ubuntu 18.04 LTS (Bionic Beaver) HOT 1
- Draft Release Notes: BitShares Mekong 6.1.0 HOT 1
- ES `mapper_parsing_exception` error with `testnet-6.1.0` HOT 1
- ES `413 Request too large` error with `testnet-6.1.0` HOT 1
- Buyback orders that fail to place should not show in account history
- `operation_history_object::virtual_op` numbering may be discontinuous (possibly with holes)
- Missing account history data in ElasticSearch if node is restarted while syncing
- Support ElasticSearch version 8 HOT 1
- ElasticSearch plugins: HTTPS support
- Witness_node crashes on exit
- About Docker sunsetting Free Team organizations HOT 8
- Credit deal auto-renewal feature
- "sonar.cfamily.cache.enabled" and "sonar.cfamily.cache.path" properties are deprecated HOT 1
- Docker image issues
- Draft Release Notes: BitShares Core 7.0.0 "Suez" HOT 1
- `gethelp` command in CLI wallet built with Ubuntu 20 lacks docs for command parameters HOT 1
- Develop the functionality to create a list of accounts eligible to claim assets HOT 1
- Update get_ticker API to include liquidity pools
- Witness_node randomly stops syncing HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bitshares-core.