User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; ca; rv:220.127.116.11) Gecko/20060830 Firefox/18.104.22.168 (Debian-1.5.dfsg+22.214.171.124-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; ca; rv:126.96.36.199) Gecko/20060830 Firefox/188.8.131.52 (Debian-1.5.dfsg+184.108.40.206-1)
Please remove password obfuscation from signons.txt. It is annoying and useless.
Rationale copied from http://gaim.sourceforge.net/plaintextpasswords.php:
Obscure a password. This means we do something to store the password in some format other than plain text, but we automatically convert it for you. This is security by obscurity, and is a Very Bad Thing™ in that it gives users a false sense of security. A false sense that we (Gaim developers) believe would be worse to have than to let informed users deal with the password issue themselves. Consider that a naive user might think that it is safe to share his or her accounts.xml, because the passwords are "encrypted".
For the base64-decode (when no master password is used), I agree. But we shouldn't make it too easy for spyware to grab the password either.
How about making the master password mandatory ?
Having to type a master password is something I'd find much more impractical than copying passwords (my passwords tend to be 32-byte random alphanumeric and almost never type them manualy) from the GUI tab by hand.
In my system only trusted eyes are able to see my signons.txt, but I understand that you want to support insecure systems with malware too. Can we find a solution that satisfies both situations? Obfuscating only provides a false sense of security and malware can get over that easily. I'm not familiar with master passwords; are these used to encrypt the data? Perhaps you could encourage them (specialy in insecure systems), but still provide a way for expert users not to use them?
Yes, master passwords are used to encrypt stored web site passwords.
It doesn't make sense to me to deliberately make things plaintext, even though obscuring entries technically doesn't provide much security.
But security aside, the reason they're like this is that all the code follows a common path. The entries are encrypted with a key from key3.db, and that key may-or-may-not be protected with a master password. Not encrypting anythin would result in two separate code paths, which would double testing requirements and generally just not make sense.
Agreed. Adding a no-encryption codepath seems like a losing proposition to me.
This has nothing to do with security through obscurity, and everything to do with keeping the codepaths simple.