All SIP accounts + IM accounts passwords are not protected.

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).

I prefer the second option to change it into password being shown as plain
text.

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 :)

(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.

(In reply to comment #5)

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

Yup :) thanks for correcting!

*** This bug has been confirmed by popular vote. ***

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 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.

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....

How about using a salted md5 hash like stuff in passwd uses? Or any other
salted mechanism?

(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 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.

(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.

(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 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 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 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. ;-)

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?

(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).

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”

(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 :(

(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.

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.

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.

(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 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ä 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ä 2010-01-19 09:34:28 UTC

Reopening.

Comment 30 Lassi Syrjälä 2010-01-19 09:35:17 UTC

Should be FIXED (with caveats)

Comment 31 Lassi Syrjälä 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ä 2010-01-25 21:55:20 UTC

Ping? Does comment #28 help?

(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

Couldn't reproduce in PR1.1.1

Closing bug.