blob: bec552cdd8075c43ae2bc3db6cd4514db5cc2cb5 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
Soledad Server
==============
A U1DB server that stores data using CouchDB as its persistence layer.
.. contents::
:local:
General information
-------------------
This is written as a Twisted application and intended to be run using the
twistd command. To start the soledad server, run:
.. code-block:: bash
twistd -n web \
--class=leap.soledad.server.entrypoint.SoledadEntrypoint \
--port=X
An systemd script is included and will be installed system wide to make it
feasible to start and stop the Soledad server service using a standard
interface.
Server database organization
----------------------------
Soledad Server works with one database per user and one shared database in
which user's encrypted secrets might be stored.
User database
~~~~~~~~~~~~~
Users' databases in the server are named 'user-<uuid>' and Soledad Client
may perform synchronization between its local replicas and the user's
database in the server. Authorization for creating, updating, deleting and
retrieving information about the user database as well as performing
synchronization is handled by the `leap.soledad.server.auth` module.
Shared database
~~~~~~~~~~~~~~~
Each user may store password-encrypted recovery data in the shared database.
Recovery documents are stored in the database without any information that
may identify the user. In order to achieve this, the doc_id of recovery
documents are obtained as a hash of the user's uid and the user's password.
User's must have a valid token to interact with recovery documents, but the
server does not perform further authentication because it has no way to know
which recovery document belongs to each user.
This has some implications:
* The security of the recovery document doc_id, and thus of access to the
recovery document (encrypted) content, as well as tampering with the
stored data, all rely on the difficulty of obtaining the user's password
(supposing the user's uid is somewhat public) and the security of the hash
function used to calculate the doc_id.
* The security of the content of a recovery document relies on the
difficulty of obtaining the user's password.
* If the user looses his/her password, he/she will not be able to obtain the
recovery document.
* Because of the above, it is recommended that recovery documents expire
(not implemented yet) to prevent excess storage.
The authorization for creating, updating, deleting and retrieving recovery
documents on the shared database is handled by `leap.soledad.server.auth`
module.
|
