README: added the Security section
This commit is contained in:
parent
e29ea6288a
commit
23d09f0c5d
30
README
30
README
|
@ -123,6 +123,36 @@ great for saving power.
|
|||
inconsistent data.
|
||||
|
||||
|
||||
Security
|
||||
--------
|
||||
At the moment only one widget type (Gmail) requires auth. information
|
||||
in order to get to the data. In the future there could be more, and
|
||||
you should give some thought to the issue of protecting your data. The
|
||||
Gmail widget type by default stores login information in the module it
|
||||
self, and you are advised to make sure that file is only readable by
|
||||
the owner. Other than that we can not force all users to conform to
|
||||
one standard, one way of keeping it secure, like in some keyring.
|
||||
|
||||
First let's clear why we simply don't encrypt the login information
|
||||
and store it in ciphertext. Answer is simple, that is no more secure
|
||||
than having it stored in plaintext. By exposing the algorithm anyone
|
||||
can reverse the encryption steps. Some claim even that's better than
|
||||
plaintext but it's just security trough obscurity.
|
||||
|
||||
Here are some ideas actually worth your time. Users that have KDE (or
|
||||
parts of it) installed could store their login information into the
|
||||
Kwallet service and request it via DBus from the widget type. It can
|
||||
be done with tools like "dbus-send" and "qdbus". The Gnome keyring
|
||||
should support the same, so those with parts of Gnome installed could
|
||||
use that keyring.
|
||||
|
||||
Some users move their login into an external file and read it from
|
||||
there. Not much different than keeping it in the module, but what if
|
||||
you encrypt the file with your GPG key? Users of the GPG Passphrase
|
||||
Agent could decrypt the file transparently while their session is
|
||||
active.
|
||||
|
||||
|
||||
Widget types
|
||||
------------
|
||||
Widget types consist of worker functions that take the "format"
|
||||
|
|
Loading…
Reference in New Issue