ubuntu-phone team mailing list archive

[Daniel Clem <clem11388@xxxxxxxxx>]

I made a reply to the "Why no Browser in the core apps” thread  about using the same filetype as KeepassX, but didn't see Keepass mentioned here so I thought it might be un related to the browser discussion.

The .kdb file type is encrypted and requires a master password to open. But is very secure and runs on all 3 desktop types and on Android. Perhaps its not integrated into gnome-keyring or kwallet, but I always hated how they both would always pop up asking for a unlocking password for simple messaging tasks. Maybe it was just me, but always seemed cumbersome and confusing.

This feature should have the highest security possible, be safe from outside eyes such as "big brother”, but be completely out of the way so that its only noticed when adding a new entry.

Also, just thought of something important that I use all the time in Keepass. These entries, Facebook for instance, should not be only used by one single app. Why have 5 entries for the same Facebook account just because you have 5 different apps. That also means you have to enter the info 5 times. Where with Keepass I simply lookup Facebook, copy and paste. And my passwords are also usually at least more than 50 random characters that I could never remember. And I have hundreds of separate entries like this. So requiring the user to enter passwords manually each time for different apps would be more cumbersome than either Kwallet or Gnome-keyring.

Sorry for being so long, I maybe very biased, but I feel the benefits to implementing a Keepass like way of doing things would benefit more than just myself.

      God Bless,
         Clem

Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx> wrote:

>Hi all!
>  I'd like to discuss about our plans for a password/secret storage
>service which could be used by applications to store and retrieve
>secret
>data.
>
>On the desktop, we are currently using the GNOME keyring, which we
>cannot use as-is on UbuntuTouch given its dependency on Gtk+. The GNOME
>keyring itself implements part of the "Secret Service" freedesktop.org
>API [0], which AFAIK is also implemented by KDE's KWallet.
>
>Whatever solution we choose, I'd recommend to expose an API compatible
>with the freedesktop.org's one; it might not be exactly what we need,
>but on the other hand I don't see a strong reason to do things
>differently.
>
>That said, the next question is what we want to use; given that the
>"Secrets Service" API is not terribly complicated, and that the GNOME
>keyring is tied to Gtk+, I don't think that the effort of extracting
>and
>reusing the non-Gtk+ parts of the GNOME keyring is worth it.
>
>Someone suggested that we could implement the freedesktop API inside
>the
>signond daemon, which is at the core of Online Accounts; given that the
>daemon is easily extensible (it already provides an extension API for
>plugins), it might not be a bad idea, considering also that signond
>will
>be one of the main users of this API (it needs it to store account
>passwords and authentication tokens).
>However, while not being against the idea, I'd like to give it some
>more
>though before pushing it forward.
>
>Another question is how the secrets DB should be stored. In MeeGo we
>were using the SIM "Run GSM algorithm" [1] to obtain a byte array which
>would be unique to the user's SIM, and use that as a LUKS key to
>decrypt
>the secrets storage which was mounted in its own loop partition.
>So the plan was to disable the password storage when the SIM was
>removed
>or deactivated.
>At the end we had to disable this feature because of problems with the
>SIM service (which from time to time reported that the SIM was being
>removed while in fact it was still there), but the infrastructure was
>all in place -- and as far as Online Accounts is concerned this is
>still
>usable, since we took off from the MeeGo code. Only the SIM interface
>needs to be re-written for oFono (provided that it can offer the same
>functionality).
>
>Anyway, regardless of what the access key is (whether it's the SIM or
>anything else, like a lock code or screen gesture), it might be a good
>idea to consider the possibility of having the secrets storage being
>made unavailable when some conditions are not met.
>
>
>So, those above are a few aspects to consider. There are many ways to
>implement the secrets DB, and if you think you have more ideas, you are
>very welcome to list them here.
>I'm bringing up this discussion because this service is essential for
>Online Accounts (right now on UbuntuTouch our password database is not
>encrypted), and if there's something I can do to get this done,
>including writing code, I'd be happy to help.
>Consider this e-mail as me volunteering for this task -- but first we
>need to decide how to do it. :-)
>
>Ciao,
>  Alberto
>
>[0]: http://standards.freedesktop.org/secret-service/
>[1]:
>http://en.wikipedia.org/wiki/Subscriber_identity_module#Authentication_key_.28Ki.29
>
>-- 
>Mailing list: https://launchpad.net/~ubuntu-phone
>Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~ubuntu-phone
>More help   : https://help.launchpad.net/ListHelp