||[Sep. 27th, 2004|03:32 am]
I had occasion this morning to manually edit my ~/.logjam/conf.xml preference file. I'm not especially happy about having had to edit it manually, but that was the only way I could get LogJam 4.4.0 to save my default font size for the editor window. I kept setting it to FreeSans 11, and it kept setting itself back to FreeSans 10.|
While doing so, I browsed the various other conf.xml files I found, and found something really, really disturbing. I was not expecting to find that my journal's password was saved to clear text. I was even more so not expecting to find the permissions on that file, and every other file inside the .logjam folder, defaulted to 666. The directory itself and all the subdirectories were correctly set to 700, but any user on the same machine who knew my LJ name and who used LogJam themselves could deduce the directory path and open, view, and edit every file in there. I consider that a pretty big bug.
Hmm. Yes, I too am kind of surprised to find it saved in plaintext. It's 644 on my system, though, and the containing directories are appropriately 700.
Note that users should need execute permissions on the directory to open files in it.
Jut out of curiosity, how would you like them to handle it? Since they need the plaintext passphrase when they log into LJ, they can't really encrypt it with a one-way algorithm (unless they had you enter some other sort of authentication tokens when you started logjam, or something like that). They can obscure it, of course, but it would be done with a known algorithm and would, by necessity, have to be reversible.
Personally, I guess I would prefer to see the default permissions on the file be user-only, and to have the password obscured (just to inconvenience the lazy). Just don't kid yourself that obscuring the password is protecting it in any meaningful way. I'd suggest, instead, that you don't let it store your passphrase.
Well, yes, actually, you have guessed my preferences. Every file in the ~/.logjam folder should default to 600 for safety's sake, and the password field should be obscured, preferably including having the field name itself obscured so that it isn't obvious to any random 3rd grader how to break into other people's LiveJournals.
I'm not laboring under the misconception that these two changes will make it impossible to crack. But we put locks on doors, even knowing that you can buy semi-automated lock picking tools from several gun and knife catalogs. Making it more difficult to enter something without permission dramatically lowers the number of people who'll do so.
I think you're correct that the password should probably be obscured. It won't stop someone who's determined to break in, but it will deter the random person who stumbles over the file out of curiosity and decides to try out the password 'just to see if it works'.
2004-09-27 05:49 pm (UTC)
Not to be picky, but if the directory is 700, then only you can List, Read, and Write files in that directory and any directory under it. In order to read a file/directory in another one, a user must have execute permision on the parent directory. Read permission is used to get a list of files in a directory and write is used to create files.
Also, what is your umask set to? For security it ought to be at least 022, and I usually set mine to 027 or 077 depending.
2004-10-08 02:06 pm (UTC)
Apparently you never bothered to check your umask. Add the following line to your '.bash_profile' or whatever shell startup script you use:- EOF -
umask 022 - means all new files are created world and group readable, but not writable
umask 077 - means all new files are neither group nor world readable (700, 600, etc..)
Then chmod the .logjam/ dir to 700 and the files and internal directories to 600 and 700, respectively. Next time you have a problem with file permissions please check yourself first as opposed to accusing the developers of foul play. And about the plaintext password, unless you want to type the password in every time anyway (even if you save it), it has to be saved in plaintext.