On a related note... I just checked; Modest and all of the RTComm accounts (except Skype) still store all the passwords in plain text in GConf. It is trivial for any app to obtain these passwords at the moment.

Should I file bug(s) about this?

Basically, no. It is architectural design, and the proposed solution is snake oil.

Plain text storage of password works as intended because somehow these passwords are stored and encrypted without user interaction because the user chose to save the password. What Skype does is obfuscate the password.

What should happen is this:
Barrier -> Authentication attempt (using input data; e.g. fysical key, smartcard, password, fingerprint, etc)-> Encrypt authentication -> Compare with saved key -> If match, authentication succeeded.

Then stop. However what happens is that after the above the input data is stored. If you provide one this input data they have access. Its like giving away your password.

Now, Skype obfuscates, because it is not known in which format Skype saves it. But if Skype can somehow decrypt the data without input data then so can someone else; they just need to figure out what.

Without obfuscation saving your password is akin to putting your house key before your door and then assume nobody will use it, or whine when someone does use it.

With obfuscation its akin to hiding your key in one of your plants in the front garden which supposedly nobody knows except a determined attacker can easily figure out about this.

This provides a false sense of security; snake oil.

Early UNIX versions did the very same thing, and together with lack of shadow file this made password cracking easy because /etc/passwd was readable by everyone.

If your application can read your program's configuration file and abuses this (arguably misplaced) trust you have worse problems. However, non-hostile applications do not do this.

If people dislike this they should use some form of authentication or a keyring like GNOME Keyring or KeePassX. This is pretty neat however a hostile application can ofcourse work around this.

IOW if this is an issue your solution should be dealing with core issue; hence, a rather architectural change. For example, applications isolated from each other. Then you get to levels such as privilege separation, VMs, ACLs, or microkernel + capability-based security. We do know Nokia is working on a framework to provide some of these mentioned features, but they won't be for Fremantle. Hence 'fixed in Harmattan' or WONTFIX seems rather a likely outcome.

That's not quite true; the data in unix passwd file is not the input data, nor is it equivalent to a stored plain-text password. Getting a password from a passwd file entry required reversing a one way hash function - not impossible using a password guessing app, but it's a long way from 'giving away your password'.

If apps on the N900 are storing passwords or password equivalent tokens unencrypted in predictable locations, then that is a bug, and should be filed as one.

You didn't understand what I wrote. Authentication with PAM or equivalent requires some kind of input data. If you _save_ your password then you simply _lost_ your chance to allow yourself to require input data.

There are 2 major differences with /etc/shadow:

1) /etc/shadow is only readably by root whereas any user application can read any one other user application's config files. Changing this requires serious work on the architecture of the OS.

2) the input data is encrypted and compared with the entry on /etc/shadow. If they match, the user is authenticated. Nothing is decrypted, ever. It'd make password cracking much easier. As I wrote, there is no input data if the passwords are stored, and if the passwords are not stored there is no issue.

The right way to solve the issue without too much changes (although still requires substantial work) is by using a keyring. In fact, many applications could make use of this. But the support for this has to be added in the applications, and you might as well wait a year for Harmattan which has DRM/ACL/capabilities support in the core OS.

PS: And like I wrote, if you have a hostile application which reads your passwords and abuses that then you have other worries. A hostile application could also log your keys, or be a worm. Really, the issue is much, much more different and complicated then. And this is exactly why capability-based security and signed binaries such as in Symbian is a Good Thing because it gives responsibility to those where it matters. The developer is known, their do's and dont's are known, when such isn't known they're denied.

This is true, however, you seemed (and indeed, seem) to be giving the impression that traditional unix passwd files saved passwords, and that this only changed with the move to shadow passwords. That is not the case.

You said that a major difference with shadow passwords is that:In fact, that's exactly how traditional unix passwords work too, the _only_ difference with shadow passwords is that the hashes are not stored in a world readable file.

Point #1 is about privilege separation.

Point #2 is related to what you assert. Because there is no input data there is nothing to be encrypted and compared with /etc/shadow.

The alternative to this is right there in existence and simple as kissing: do not save your password(s).

Again, I am not saying this doesn't warrant a bug report, but I am saying the problem is pretty much system-wide and architectural design instead of a problem easy to pinpoint in applications. The proposed solution, and very description of problem, do not solve the issue. They are snake oil pur sang.

A "good thing" from the perspective of those who use them against you, because any such security scheme where authorization requires a 3rd party is implicitly holding you in the same level of contempt as any author of malicious software, and using your own property to enforce it.

It could be a good thing at best if such binary signing capabilities were made available to the user, with the ability for them to grant the highest levels of access should they desire (which, under Symbian, you definitely were not.)

The reasons this is in my opinion quite a bad thing for the open source/free sofware community are

1) people are forced to do choose between being free to do what they want with their device and being able to enjoy media, possibly some applications etc. In the worst possible case this means no proprietary apps or any movies, music etc. for you at all if you want an open system. In the best possible case this means you just won't be able to use some media that uses this but there will still be alternatives (albeit maybe more cumbersome to get on the device)

2) Even if things will be as described in the best possible case described in point 1 at first, if such a thing is accepted and becomes universal (that is MS finally gets around implementing a similar thing as they have been trying to etc.) there eventually will not be any or very little non-protected music, movies etc. that can be used on a device not using this "protection". This would mean becoming free would also prevent you from getting any entertainment that also wasn't a part of free culture.

Yes, the analog hole would still persist while we don't have DRMed eyes & ears but the quality degradation would be pretty severe... I'll say I will have a hard time justifying the purchase of a supposedly FLOSS-friendly device that also supports this divide.

epage's posts moved to http://talk.maemo.org/showthread.php?t=43627 , which is the current thread for the Security Framework discussion.

Everybody interested in this discussion please continue there since the scope is much wider than Windows Playready DRM.