Exactly. I keep hearing the argument "if the user knows the passwords are being stored as plaintext they'll be more careful with the file" but I had no idea they were being stored as plaintext until this thread appeared.

Although, it sounds like the issue may have been resolved in this update?

I dunno, but, damn, whoever wrote that FAQ needs a strong lesson in proper pronoun usage.

I was on more about the attitude of security via strong passphrases and of course the attitude that seems to be pushed out via the Pidgin FAQ of understanding >>>>> then weak security measures.... I do wonder what the Firefox dev who wrote the saved passwords module thinks about their weak security model?

In terms of the N900, I think what needs to be done now is some way of sanitising the file that stored the passwords from pre PR1.1 days!

Why do you falsely claim that Firefox uses a weak security model for saved passwords?

I'm not, I'm trying to be sarcastic

I'm just taking what is said by some posters on the thread (and from the Pidgin FAQ) and applying it to the fact that Firefox does save passwords locally. With Firefox it actually does save the passwords locally and encrypts them and it recommends the user to use a master password to ensure at least the passwords are not easily grabbed between sessions.

Without using the Master Password, Firefox, prior to 3.5, stores the passwords as securely as Pidgin as all you need is a proper base64 decoder (Firefox itself will suffice, javascript:atob("<base64 encoded username/pass here>") ) - the passwords are just a tad bit harder to get. Since the 3.5 version (on which microB is based as well) the things are more complicated as you need to read the signons.sqlite file (although the important data will be visible in a text editor) and then requires an extra step as it obviously encrypts the data (hence the key3.db even if no Master Password is used) with some for me unknown string, but if looked hard enough, it can be found as it's accessible to the browser without user input.

When using the Master Password, and one that can be considered a quality password at that (i.e. 12+ characters of mixed case, numbers and puncuation with no dictionary words or dates), it's one of the safest ways to store (unfortunately not to use, as it can be sniffed during the entry phase) passwords. And I'm all for it, somebody should file an enhacement request.

What I am against is calling the current system insecure just because it stores the passwords in plain text, and recommending base64/ROT13/whatever to make it more secure. It wouldn't, just like no other app that don't use keychain/master password/other means of proper encryption (with some added inconvinience to the end user) is not storing the passwords securely. This thread itself proves why a plain text storage is more secure - if it was obfuscated, many people would falsely think that their passwords are safe (just like they think for the microB passwords, even tho they are just as accessible).

I agree with everything you said apart from this last line. How does it prove it is more secure? Most people don't even know that their passwords are being stored in plain txt. If the app warns of how the password is stored when the user tries to store it then what you said would be true!

The thing is that rarely any app out there, which stores passwords locally, warns you on how your passwords are insecure. How is it any different than some other (Trillian, Miranda, even Digsby when `Auto Login` used...) IM? They all store locally passwords either plain text, or at best base64/ROT13 encoded.

If ~/.rtcom-accounts/accounts.cfg stored the passwords using base64/ROT13/something similar this thread wouldn't even exist in the first place, and users would falsely think that their passwords are safe, where in fact they are not. They are not safe in the microB browser as well, but are just fairly harder to retrieve. If somebody has a physical access to your device, you are not any safer with non-encrypted (with user/3rd party input) passwords as you are with plain text stored passwords.

I agree that some warning would be useful (education wise), but generally we need to educate people that nothing is secure if it's stored locally, and does not require further input and/or additional non-local based keys. Nothing! What use is to do that for the mail/telepathy/microB, when a user can install some third party software (for example FB widget, don't know how it stores the passwords tho) that will do just the same thing.

In the current situation, the easiest solution would be if the devs allowed to create an account without entering the password in the first place, and for careful users to enter their password each time they login to some service. Either that, or some sort of Master Password / keyring partition. Both should be filled as a feature request, I'd gladly vote for them.

Just because the norm is to encourage, or have some insecure method of storing passphrases doesn't mean it should be taken as the best method of doing something. The idea that storing passphrases locally is bad, and therefore no security is better then some, _without_ educating the user is flawed imho.

If we look beyond the single application, to the user environment, we already have tried and tested methods such as the gnome keyring (etc) which provide a certain level of protection between sessions. Sure a trojan (or admin) can grabbed those passwords during the session, but does that mean they shouldn't use it?

If we take the above reasoning to the extreme then unless some token system is used, we really should enter the passphrase in _each time_ it is used. Because if an application requires access to the passphrase during the session, it doesn't matter if it is stored locally or in memory, it can be compromised. That would mean each time you access a https connection you would need to type in a passphrase, each time your wifi needs to establish you would need to type in a passphrase and so on.

Of course the above example is being silly, but the point I am trying to make is there needs to be a balance between security and usability (for the average user).

Also I firmly believe that a secure system is a combination of little measures that are transparent to the user combined with user education. When a decent server admin hardens a box, they don't just do one thing, but lots of little things which on their own don't seem much, but all together makes the box a lot harder to compromise and makes the target less tasty for the would be attacker.

A FAQ posted on a site somewhere just sounds like a prepared excuse to laugh at people who have been compromised because they just didn't know better.

@mahousaru

Again, we have people that understand security trying to explain it to people that don't understand it, and probably don't really care to. What people do care about is feeling secure. These are two different things, and I responded to the latter. And so did you.

stskeeps already alluded to the only known solution to having a secure device that you can loan to someone. At a minimum, it would need a boot-up password and a special chip, the reason why is left to the reader that actually gives a sh*t.