Ask / Submit
44

Credential storage security issues

asked 2014-01-17 13:35:58 +0200

benthor gravatar image

updated 2014-01-20 13:12:34 +0200

lk gravatar image

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), this is a big concern.

I'd like to get a discussion going about how to approach this problem. Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According to people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

edit retag flag offensive close delete

Comments

agreed... it is never a good thing to store passwords in plain text... particularly if those files are not adequately protected from different user space applications. This got an up-vote from me.

roboro ( 2014-01-17 14:02:27 +0200 )edit

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. [...] The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

And we go back to Aegis.

javispedro ( 2014-01-24 20:20:51 +0200 )edit

2 Answers

Sort by » oldest newest most voted
6

answered 2014-01-17 14:03:04 +0200

lbt gravatar image

Firstly, thanks for asking about this and let me address a couple of points before there's any confusion.

The nature of these kinds of passwords means they need to be stored and sent in the clear over encrypted (ssl) channels. See https://developer.pidgin.im/wiki/PlainTextPasswords about why encrypting them isn't too sensible.

The accounts and credentials frameworks come from Nemomobile and are due to be updated; contributions there are welcome.

edit flag offensive delete publish link more
8

answered 2014-01-17 14:01:32 +0200

rainisto gravatar image

updated 2014-01-17 14:04:20 +0200

Thanks for the feedback and feature suggestions. We are working ways to improve the security (first small steps like protecting it under privileged group etc).

But there is also possibility to co-creation, if people in Mer and Nemo can come up with better working solution for example in some Nemomobile git project, then I don't see any obstacles to integrate that into device at some point.

edit flag offensive delete publish link more

Comments

In this case I suppose just making it group readable only by the accounts/signon processes would work... After all, in N9 world it was supposed to work this way.

javispedro ( 2014-01-24 20:22:53 +0200 )edit
Login/Signup to Answer

Question tools

Follow
8 followers

Stats

Asked: 2014-01-17 13:35:58 +0200

Seen: 467 times

Last updated: Jan 17 '14