Bug 8146

Summary: .rtcom-accounts/accounts.cfg storing SIP & IM passwords as plain text
Product: [Maemo Official Applications] Settings and Maintenance Reporter: Venomrush <tri>
Component: Backup/RestoreAssignee: unassigned <nobody>
Status: CLOSED FIXED QA Contact: backup-restore-bugs
Severity: enhancement    
Priority: Unspecified CC: andrew, andre_klapper, corsac, emanuele.cassioli, j.s.sebastian, jarmo.lahtiranta, jorgen.scheibengruber, klarsen, lassi.syrjala, maemo, maemo, ruskie+bugs, scifi1947
Version: 5.0/(2.2009.51-1)   
Target Milestone: 5.0/(3.2010.02-8)   
Hardware: N900   
OS: Maemo   

Description Venomrush (reporter) 2010-01-17 12:02:39 UTC
SOFTWARE VERSION:
PR1.1

EXACT STEPS LEADING TO PROBLEM: 
1. Create a full backup 
2. Open comm_and_cal\Root\tmp\.rtcom-accounts\accounts.cfg

EXPECTED OUTCOME:
param-password encrypted

ACTUAL OUTCOME:
param-password not encrypted, full password shown as plain text

REPRODUCIBILITY:
Always
Comment 1 Venomrush (reporter) 2010-01-17 12:04:06 UTC
All SIP accounts + IM accounts passwords are not protected.
Comment 2 Lucas Maneos 2010-01-17 15:37:48 UTC
As currently stated this is INVALID - osso-backup simply archives a copy of
/home/user/.rtcom-accounts/accounts.cfg, but does give you the option of
encrypting the entire backup.

We can either close this or change it into a bug about the passwords being
stored in plaintext (which will probably be FIXED in Harmattan).
Comment 3 Venomrush (reporter) 2010-01-18 08:23:59 UTC
I prefer the second option to change it into password being shown as plain
text.
Comment 4 Venomrush (reporter) 2010-01-18 13:24:03 UTC
Ok after some digging around trying to exploit the fact passwords aren't
encrypted. 

I can now say that I can walk up to anyone who has N900 and open Web and browse
to:

file:///home/user/.rt-accounts/accounts.cfg

and be able to view any SIP and/or IM accounts they got on their device :)
Comment 5 EC 2010-01-18 13:39:53 UTC
(In reply to comment #4)
> Ok after some digging around trying to exploit the fact passwords aren't
> encrypted. 
> I can now say that I can walk up to anyone who has N900 and open Web and browse
> to:
> file:///home/user/.rt-accounts/accounts.cfg
> and be able to view any SIP and/or IM accounts they got on their device :)

You mean file:///home/user/.rtcom-accounts/accounts.cfg, right?
Nice catch Venomrush, I think this is a valid bug, it shouldn't be so simple
finding anyone's password.
Comment 6 Venomrush (reporter) 2010-01-18 13:43:51 UTC
(In reply to comment #5)

> You mean file:///home/user/.rtcom-accounts/accounts.cfg, right?

Yup :) thanks for correcting!
Comment 7 Nuno Mgaz 2010-01-18 13:44:06 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 NvyUs 2010-01-18 13:53:18 UTC
this needs to be fixed fast a simple browse throufg files using web browser
exposes everything.
just release a patch waiting over a months for PR1.2 is not fast enough when
security is in question
Comment 9 Andre Klapper maemo.org 2010-01-18 14:07:10 UTC
> param-password encrypted

Encrypted as what, and how?

I fail to see the bug here actually. Maemo5 does not have anything like
gnome-keyring or kwallet etc in place.

Plus using base64 encoding takes simply one command more to decrypt the
information.

As with every computer: Don't let people you don't trust use it.
Comment 10 klarsen 2010-01-18 14:49:12 UTC
Might not be a bug but a serious issue. Not many platforms exposes users
passwords in plain-text on the "drive". Since the platform is quite open -
anyone with basic skills can write a "nice to have app" that reports SIP
passwords home to base.. Hurray....
Comment 11 Andraž 'ruskie' Levstik 2010-01-18 14:51:49 UTC
How about using a salted md5 hash like stuff in passwd uses? Or any other
salted mechanism?
Comment 12 feydrutha 2010-01-18 14:59:41 UTC
(In reply to comment #11)
> How about using a salted md5 hash like stuff in passwd uses? Or any other
> salted mechanism?

That cannot work for passwords to remote systems. To log in to your IM or SIP
account, you need to send the password, not an md5 of the password. The point
of the salted hash is that the password cannot be recovered from it (short of
brute-force). How would the IM client log in, if it only has a hash of the
password?
Comment 13 Andre Klapper maemo.org 2010-01-18 15:06:47 UTC
I tend to close this as invalid if I don't see an actual proposal that makes
sense here soon.
Also, the forum exists for a good reason at
http://talk.maemo.org/showthread.php?t=41164 while Bugzilla is not a forum.

Also see bug 6030.
Comment 14 Yves-Alexis 2010-01-18 15:15:29 UTC
(In reply to comment #9)
> > param-password encrypted
> 
> Encrypted as what, and how?
> 
> I fail to see the bug here actually. Maemo5 does not have anything like
> gnome-keyring or kwallet etc in place.
> 
The real problem lies here, imho. I think the problem exists since first maemo
versions (not sure if we can dig a bug that old, but someone might be able to
confirm this looking at a n770). 

I guess a keyring daemon might not be possible until Harmattan (which is
supposed to have a security architecture, meaning this kind of issues might be
adressed), but some encryption using the lock password or the SIM PIN code
would be nice.

Though that means the user has to type it every time she needs a password, and
that means:

* IM;
* mail;
* wireless passwords;
* and so on.

Another solution could be to store the password in an encrypted files, decrypt
them at boot time using PIN code, then only store it in memory in a not too
obvious way.
Comment 15 Yves-Alexis 2010-01-18 15:20:57 UTC
(In reply to comment #13)
> Also see bug 6030.

I'm not sure encrypted storage would really help us there. I mean, encrypted
*data* storage would really be nice to have (I hope to be able to play with
cryptsetup and stuff like that) but in that case it wouldn't help that much if
there's only one large crypto-container used for everything, because it would
always need to be mounted decrypted.

What would be needed (and yes, that looks like a keyring manager) is multiple
encrypted files/passwords/area/..., and something to ask for a password each
time an access is needed (and maybe a global decrypted state with stuff present
only in ram, but as always it's a tradeoff).
Comment 16 Andrew Flegg maemo.org 2010-01-18 15:23:14 UTC
Proposal to "fix" this bug, within the steps to reproduce laid out by
Venomrush:

    Browser cannot open any file:///home/user/.* URLs.

Then, when there's a bug raised that "I can just go up to any N900 user's
device, open X Terminal and cat .rtcom-accounts/accounts.cfg" that can be dealt
with separately ;-)
Comment 17 Jörgen Scheibengruber nokia 2010-01-18 15:24:21 UTC
Andre, this is not my domain, but I agree with invalid:

Rationale is here and I don't see why from our POV the situation would be
different: http://developer.pidgin.im/wiki/PlainTextPasswords
Comment 18 Andre Klapper maemo.org 2010-01-18 15:33:23 UTC
So I will close this either as "INVALID for Maemo5", or as "FIXED in
Harmattan".
Pick your poison, I chose INVALID. ;-)
Comment 19 Jarmo Lahtiranta 2010-01-18 15:33:51 UTC
How about using file permissions as a first level of defence. Give only some
special user access to the file and run the IM programs with that user. That
way the normal user doesn't see the passwords using a browser, but you don't
need to encrypt them either.

It's not a perfect solution in any way, but might be enough for now?
Comment 20 Yves-Alexis 2010-01-18 15:43:20 UTC
(In reply to comment #17)
> Andre, this is not my domain, but I agree with invalid:
> 
> Rationale is here and I don't see why from our POV the situation would be
> different: http://developer.pidgin.im/wiki/PlainTextPasswords
> 
Not sure the situation is exactly the same. First, I don't think you can use
GPG or other end-to-end encryption in Maemo. Nor in modest, nor in
conversations (wether IM or SMS). So no workaround.

Then, an n900 (or, for that matter, all the NIT and all the phones anyway) are
portable devices, which can be easily lost (or stolen). Meaning gaining access
to the files is not really hard, and especially easier than in a
desktop/laptop, and you don't (at the moment) have the workarounds existing in
those environments.

Another problem is the “rogue apps”, which can easily mess with that, but
there's not much people can do about that (well, except only running signed
applications, which kind-of suck in an open platform. Hopefully, people running
only maemo extras won't have that kind of problem if peer review is done well
in extras-devel and extras-testing. As always, the problem is the trust the
user has in the platform and the apps wrt. its passwords and keys.

In the end, I don't see the bug as “Invalid” (the point is valid, the
passwords *are* indeed available as plaintext) but rather the fix is not that
easy and existing solutions are not simple to implement.

But imho it *is* a concern, and it'd be nice if something was done to address
the issue, because improving the plateform security is always a good idea
(wether for business, government or individual users).
Comment 21 Yves-Alexis 2010-01-18 15:45:51 UTC
Oh and sorry for flooding the bug report, but I forgot to add that any level of
added security is nice to have. Think “defense in depth”
Comment 22 Venomrush (reporter) 2010-01-18 15:49:28 UTC
(In reply to comment #9)

> As with every computer: Don't let people you don't trust use it. 
> 

Then we might as well get rid of the *** asterisks in password entry fields
since we're the only one using it.

> I fail to see the bug here actually.
> 

Compare to other 'computers', you would require some sort of 3rd party software
to get the passwords. There are some 'efforts' required.

This on the other hand, no additional software required, no effort.

We could argue all we want but at the end of the day it's a major FAIL for the
N900 :(
Comment 23 Venomrush (reporter) 2010-01-18 15:53:23 UTC
(In reply to comment #2)

> We can either close this or change it into a bug about the passwords being
> stored in plaintext (which will probably be FIXED in Harmattan).
> 

Please mark Target Milestone as Fixed in Harmattan so at least we have a
reference/record later on.
Comment 24 Ndi 2010-01-18 17:34:33 UTC
Can't we get it to encrypt in any way? Even ROT13 would be nice since it's not
human readable, it still requires the file to be sent over and decoded or an
app or somesuch.

First thing that will happen once this is out is next person that grabs my
phone is going to show me this exact "trick" and in consequence learn my
passwords.

There's one thing to keep an eye on a person handling the phone to see what is
being sent and quite another to be able to plain-see the password and remember
it - that's actually a lost password.

It can't be too hard to ROT13 the password (only) or repeating bit shift or
anything that makes it not humanly readable and not decryptable with on-hand
tools. There's one thing to remember "ThisIsMyPassword" and quite another to
remember "Xyf50Pgze".

I vote for quite implementation of ROT or SHL.
Comment 25 sarah.newman 2010-01-18 18:25:13 UTC
As a temporary workaround, I suggest enabling autolock and also explicitly
"securing" your device from the power-button menu when you're not using it. 
Enabling autolock causes your PIN to be required during system boot.
Comment 26 hqh 2010-01-18 20:32:27 UTC
(In reply to comment #24)
> There's one thing to remember "ThisIsMyPassword" and quite another to
> remember "Xyf50Pgze".

Obviously, by choosing good passwords like "Xyf50Pgze" in the first place you
can make them a lot harder for anyone to remember.
Comment 27 Ryan Abel maemo.org 2010-01-19 05:54:14 UTC
Re-RESOLVING.

Venomrush, it's considered quite rude to REOPEN bug reports after they've been
RESOLVED without either additional evidence or consensus from the developer.
Please leave it RESOLVED until such time as one of the above criteria is met.

Thanks.
Comment 28 Lassi Syrjälä nokia 2010-01-19 09:33:28 UTC
Actually, there *is* a slightly more secure storage for the passwords but PR1.0
kept them as plain text, too, just in case... PR1.1 should address this for
newly-created accounts, but I suppose we do not touch the existing ones.

If you created your accounts on PR1.0, try re-creating them from the UI.

(Alternatively, set presence to offline, remove all lines starting with
"param-password=", and "killall mission-control". At your own risk, backup
recommended, but remember to delete it if signing in still succeeds)

WORKSFORME or FIXED?
Comment 29 Lassi Syrjälä nokia 2010-01-19 09:34:28 UTC
Reopening.
Comment 30 Lassi Syrjälä nokia 2010-01-19 09:35:17 UTC
Should be FIXED (with caveats)
Comment 31 Lassi Syrjälä nokia 2010-01-19 18:29:12 UTC
Bugzilla wasn't sending out messages this morning so I guess everyone missed
comment #28. Does that solve the problem?
Comment 32 Lassi Syrjälä nokia 2010-01-25 21:55:20 UTC
Ping? Does comment #28 help?
Comment 33 Scifi 2010-02-21 19:05:50 UTC
(In reply to comment #32)
> Ping? Does comment #28 help?
> 

I recreated the IM accounts from UI after upgrading to PR1.1. I can confirm
that the IM Passwords are NOT displayed in this file.

file:///home/user/.rtcom-accounts/accounts.cfg
Comment 34 Venomrush (reporter) 2010-04-13 02:23:52 UTC
Couldn't reproduce in PR1.1.1

Closing bug.