maemo.org Bugzilla – Full Text Bug Listing
|.rtcom-accounts/accounts.cfg storing SIP & IM passwords as plain text
|[Maemo Official Applications] Settings and Maintenance
|andrew, andre_klapper, corsac, emanuele.cassioli, j.s.sebastian, jarmo.lahtiranta, jorgen.scheibengruber, klarsen, lassi.syrjala, maemo, maemo, ruskie+bugs, scifi1947
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
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
> 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
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?
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).
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 ;-)
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
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.
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.
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?
Should be FIXED (with caveats)
Bugzilla wasn't sending out messages this morning so I guess everyone missed comment #28. Does that solve the problem?
(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.