That is of course based on the idea that you will never be able to access that lock code which, by being 5 numerical chars, is very easy to recover...
(see this thread/post)

if you're gonna go through the trouble of getting through the phone lock code, it'll be hundred times easier to break through shitty security that's there as an illusion of safety.

Venomrush i realise you are bringing something you feel strongly about to the forum however this is no different to all IM accounts on PCs.
Would you mind altering your first post to prevent confusion for other users and add a link this Pidgin link that clearly explains the reasons for being in clear text.

http://developer.pidgin.im/wiki/PlainTextPasswords

I understand the arguments both camps are making, but surely some security is better than no security? The more complex a system is to crack (and even base64 encoding is more complex than plaintext), the smaller the pool is of people able to do it.

Take WEP for example. Someone with aircrack and a wifi card can steal a WEP key, but because it's more technically difficult to do that to simply connect to an unsecured access point, less people can do it, therefore it happens less frequently. Wireless access points with no key will be compromised far more often than those with even WEP.

I don't believe that all-or-nothing is the correct approach, it's akin to saying "why lock your front door when a determined thief could break a window to get in?". I know that for my house to be truely secure it would have to be a bunker with a reinforced door, but I'm definitely glad the front door locks, and wouldn't live here if it didn't!

Does this mean the browser also stores usernames/passwords in plaintext? If not, what security technique does it use?

Yes, but within an SQLite datbase ( ~/.mozilla/microb/signons.sqlite ) which is only slightly harder to read. It still is plain-text (well, base64, but it's as good as plain text)...

People that understand security are trying to explain things to people that don't understand security, and it doesn't seem to be helping.

So let's get to the real problem: If you're worried about someone seeing and remembering your passwords in plain text, your passwords probably suck.

One simple solution: Choose passwords that use abbreviations for meaningful personal phrases

The quick brown fox jumps over the lazy dog ->

tqbfjotld

Sure looks like some sort of a hash to me. Why don't you ask your mom.

Stop choosing passwords that suck.

It isn't a bad idea at all and I have not noticed anybody argue that it is. Apparently that kind of an enhancement request would either be better received or is already filed.

It seems to be WONTFIX for Fremantle, though.

The Base64 encoding (yes, obfuscation) that others have suggested may at the very least protect from an attacker that only has the time or inclination for an accidental or not screen glancing and who wouldn't go further if he encountered a garbled looking string.

Now whether this is a valid or simply common enough attack vector to bother with could be something to debate.

As a sidenote, re-adding in PR1.1 accounts (skype, msn, gtalk) that I had added beforehand hid their passwords from that file.

Actually it seems to me that you are making one of the biggest mistakes of security and focusing on a single element.

Of course decent password/phrases are very important, but the actual system that the password is being used is very important too. Identifying _all_ the areas where there is a vulnerability and the level of risk it exposes VS the difficulty of securing can become very difficult. Especially when u factor in the human element. What use is a long passphrase if the device you are using doesn't have a decent method of entering it. Lucky for us the N900 does have a nice KB!

Lets focus on the idea of a strong passphrase.... That is as strong as the mechanism used for authentication. For example GMail via a https interface can be considered pretty safe, (as long as the client hasn't been compromised). But if the user decides to use Pidgin the level of security provided by that strong passphrase drops to the level of what Pidgin provides. Basically storing that passphrase in a known location and the way it handles the auth process.

Of course the easiest solution would be to have 2 accounts, a secure one for emailing via more secure methods and one for IM, but this takes understanding by the user.

Now the Pidgin FAQ goes on about the most secure method is to not store the password, which is set by default. If the user decides to save the password does it warn them that it will be stored in a plain text file? I've dropped Pidgin in favor of Empathy, so I don't know if it does prompt the user or not, or does it rely on the user being telepathic....

Personally I believe that developers (and sys admins) should build systems secure from initial design and make their systems as transparent to the users as possible. Too many times security is added as an after thought, or so complex and cumbersome that the users bypass it.