On my last post about Tumbleweed installs, I noted two serious problems:
- installs using the live media do not work correctly;
- a weak password encryption method is used.
I have since done some more installs. And, happily, both problems seem to have been resolved.
I did a new install with Tumbleweed live KDE around 10 days ago. And the install went well. On first boot, the installed system booted without any problems.
After that live install, I checked “/etc/shadow”. There was still a problem there. The encrypted password for the newly defined user was using the weak DES encryption. As before, the root password did use the more secure sha256 hashing method.
In my recent review of “chromium”, I mentioned that it offers to save passwords, and stores them in kwallet. This suggests that they should be stored in encrypted form, due to the way that kwallet works.
Unfortunately, things may be worse. I recently tested out “chromium” while logged into Gnome. And when I visited a site where chromium had a saved password, it filled in the password field. But I was never prompted for the key to unlock kwallet.
It now looks as if “chromium” is saving the passwords in kwallet, where they are encrypted. But it is apparently also saving them in an unencrypted (but obscured) file in the user chromium profile directory.
This is not good.
I’ll be commenting on those answers to special questions that some banks use.
Yesterday, I logged into my bank site to check the balance. The first page I saw told me how they were going to protect my security. Then I was asked for information. The first item was a phone number. Okay thus far, though I’m pretty sure that they already know that.
The next information was three questions to which I should supply answers. I had some choice in the questions.
[Update: it appears that the ecryptfs kernel module may need to be loaded before you can setup a private directory. See the comments below, particularly my reply with time stamp of “2012/09/10 at 22:16”.]
It has been a while since I first posted on ecryptfs, and there have been some changes (improvements) with opensuse 12.2. My earlier post was about my experimenting. Some time in the near future, I will do a more complete post about ecryptfs. For now, this will be specific to using it with opensuse 12.2, and about what has changed since that earlier post.
What has mainly changed, is that opensuse support for ecryptfs has improved. It still does not quite work “out of the box,” but it is closer. Read More…
I plan a post on installing linux. This is a preliminary posts on the user accounts that I setup as part of the installation.
I use three accounts. The login names for those three accounts are:
The intended use of the first of these, is for system administration tasks. The second of those is my primary account, where I get most of my work done. The third of those is for testing purposes. On my current linux systems, the three accounts have uid (numerical userid) of 1000, 1001, 1002 respectively. Read More…
Some internet sites have ordinary security. They require an account and password for access, but they don’t go to special lengths. And then there are those who use a security expert (or a security BOFH). I’ll call those the “super-security” sites.
When I visit an ordinary internet site, I take reasonable care to use a good password. In fact, I generate that password with a random password generator to be sure that it isn’t easily guessed. I store a copy of that password in an encrypted file. But, mainly, I allow the firefox password manager to handle it. I did configure firefox to encrypt its password database, so that I have to unlock that once per firefox session. But then, logging into the site is rather simple, with firefox filling in the required information. Read More…