(→Access Granularity Management)
|Line 66:||Line 66:|
* Ownership model (application can only read values it has created). Here the problem of how to identify applications arises.
* If application wants to access data it has not created, the user is presented with the precise keys the application wants to read and can make an informed decision.
* Possibly rights management for keys is required. (For example, to allow the user to configure that subversion and subclipse both can read/write the SVN password).
Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文
The user shouldn't have to enter his password twice (once for logging in, once for opening the default wallet). The main problem is that the wallet will still have to be password protected, so we need a way to transmit the password to the daemon.
Gnome keyring provide a hack (is it?) for this:
Upon authenticating the user, or logging into the session, the PAM module checks for the GNOME_KEYRING_SOCKET environment variable. If not present it assumes that gnome-keyring-daemon is not running for that session.
Upon authenticating the user, the PAM module tries to unlock the 'login' keyring with the password entered by the user.
|How it works|
We could basically do something quite similar to this for kwallet:
Sascha Peilicke will look into this matters and come up with a plan. This is a core issue so we'll have to discuss it on kcd.
Sascha proposed making kwallet/keyring cross-desktop so the user would need only a single authentication backend running. For this to work we'd either need a single API and multiple implementations or a common backend implementation - probably something for freedesktop.org. Coordinating that would take a hell lot of time so this is more or less a long-term goal. In the process we have to consider binary API compatibility.
It would also be nice to have software not tied to a desktop use this (ie. Firefox).
This relates to Bug bug #105752. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I (Lemma) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session).
General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see.
This is already fixed and will be in 4.1. Benchmarking showed that syncing the wallet on every change (with a very small timer) is feasible.
Currently kwallet uses its own implementations of MD5, SHA-1 and Blowfish to encrypt the wallet. While SHA-1 is probably still safe enough it might not be in the future. Therefore switching to an external library to handle encryption will not only simplify the code but also provide more choices for hashing/encryption algorithms.
This hasn't been talked about yet, but I'd like to additionally store the date of creation and the date of modification for a wallet entry. No API changes are needed for that as all the work could be done by the backend transparently. One thing that would require an API change is commenting on the entries. This could be used to make obscure entries (like the ones by kmail) more transparent to the user.
The interface will have to be reworked. We were talking about:
KWallet provides all or nothing access to the password store. This is a security problem, because it enables application A in principle to access keys of application b.