Cooking with Linux: Forgotten Security
Where is that wine order from Henri's Fine Wines, François? We seem to be getting low on a couple of my favorites. Henri is usually right on top of these things. Did he not give you an order to approve? Ah, excellent. Then you have the order? No? What do you mean, it is somewhere safe? You either have it or you don't? I see. You thought it was important, so you encrypted the order and threw away the original message. Let me guess, mon ami, you do not remember the password you used to encrypt the message. That's what I thought. All right, show me what program you used.
Steganography, François? You used a picture of yourself and embedded the wine order inside it—I'm impressed! We will deal with this problem a little later, François. There isn't much time, and our guests will be here any moment. Ah, but they are already here.
Welcome, mes amis to Chez Marcel, the world's finest Linux French restaurant and the home the greatest wine cellar in the world. Of course, at this moment, it might be only the second best in the world. It seems my faithful waiter misplaced an order and didn't want to tell me. Yes, François, I know you know where it is. Just go down to the cellar and bring back the 2000 Douro from Portugal. This is a great red, mes amis, a rich and powerful wine with wonderful, dark fruit flavors and just a hint of mystery. Vite, François!
While François brings back the wine, let me tell you how he managed not to misplace the wine order. He used a program called Steghide, created by Stefan Hetzl, to encode and encrypt the list inside an image, an image of himself as it turns out (Figure 1).
This process is called steganography. Using this process, you can take any message and encode it inside another message (or in this case, a graphic image). In fact, you could create a whole Web site, full of images with secret messages in all of them, and no one would be the wiser. You can get a copy of Steghide at the Steghide home page (see the on-line Resources). Contributed binaries are easy to find. To build from source, Steghide requires the libmhash, libjpeg, zlib and libmcrypt development libraries; other than that, it's an easy build that you'll recognize as an extract and build five-step:
tar -xzvf steghide-0.5.1.tar.gz cd steghide-0.5.1 ./configure make su -c "make install"
In order to hide the wine replacement order, François used the following command to encode the document into his picture:
steghide embed -cf francois.jpg -ef wine_order.txt
Speaking of wine, François has returned. If you would be so kind, mon ami, and pour for our guests. Anyhow, immediately upon running the command, you are asked for a passphrase:
Enter passphrase: Re-Enter passphrase: embedding "wine_order.txt" in "francois.jpg"... done
The result is an image that still looks as it did before you hid your secret message inside, but its size will have changed. To recover the data from the image, you or the person to whom you sent the image can use the extract argument with the command:
steghide extract -sf francois.jpg Enter passphrase:
If you successfully entered the right information, the hidden file is saved to disk. This is precisely where things start to go wrong. After forgetting the passphrase, there is no way to retrieve the information. In real life, some of us have, on occasion, lost our keys. Some people chronically lose their keys, and that's why an enterprising inventor came up with the idea of putting a beeper on a keychain. Assuming you don't lose the locator unit, you can push a button and your keys emit a high-pitched signal telling you which cushion they've slipped behind.
With passwords, there's a similar idea. The simplest of these is to write passwords down or keep them in a text file. That's not a particularly secure method. However, the idea of keeping a list of passwords or passphrases makes more and more sense as we are asked to remember dozens, sometimes hundreds of passwords. It might be a lot easier if all we had to remember was one password, and that's where password managers come into play.
The first one I ran across was Dennis Pries' Password Management System or PMS. I like this one because it can run in a text-only terminal window, which means you can access it through a shell login from wherever you might be. You can pick the program up from SourceForge (see Resources), where source and a Debian package are available.
To build PMS, you have to do a kind of double extract and build five-step. First, extract the tarred and gzipped bundle (tar -xzvf pms-0.94.tar.gz). Now, look inside that source directory and you'll find a contrib directory from which you can build cdk using the extract and build five-step on that source archive. Once cdk is installed, go back to the PMS source directory, then build and install that.
The command to use this password manager is pms. When you run it for the first time, it asks you for a master password. This is the only password or passphrase you need to remember from here, but make sure you do. Forget the master key and you won't be able to get at all those other passwords. Then, PMS provides you with a simple menu from which you can add, delete or rename a host. These would be the hosts that you need to log in to. Start by adding a host (for example, www.somewhere.dom) and then a comment (for example, main production system). You'll find yourself back at the main menu. From there, choose User Functions. That's the menu that lets you add or delete user names associated with whatever hostnames you added in the previous step. You also can show a user to display the password you thought was lost forever.
Before I move on, I should point out that the hostname and user name could be anything. For hostname, I could enter “school locker”, for user name “combination” and for password, the combination itself. Although it is intended for recording login information, it works very well for other things (Figure 2).
Another thing we tend to forget all the time are the various passwords we enter for the countless Web sites we visit. From on-line banking to newspapers that require you to have a free account to read the articles, the number of accounts we build up over time is staggering. Then, there are the passwords associated with our instant messaging accounts, e-mail accounts, FTP sites and more. If there were some way to maintain and store all this information transparently while we worked, it could simplify things. Is there such a thing that integrates into the desktop?
The answer is yes. With the release of KDE 3.2 and now 3.3, users of the desktop find that they have a password manager built in. It's George Staikos' KDE Wallet Manager, and the program that runs it is kwalletmanager. When you first start the program, no wallets are created. You will, however, see a small wallet icon appear in your system tray. If the wallet manager window is not already open, click on the icon, and a blank box, looking a great deal like an empty directory folder, appears. Click Settings on the menu bar and select Configure Wallet.
A new dialog box appears with most items grayed out. Click the check box that says Enable the KDE Wallet Subsystem. Several other options now are available to you (Figure 3).
Look at the middle section, labeled Automatic Wallet Selection. You're asked to select the wallet to use as the default. Right below that, you have the option of selecting another wallet for local passwords (more on that in a moment). If this is the first time you run the KDE Wallet, it's unlikely at this point that you have an existing wallet; click New and enter a name for this wallet when prompted to do so. You simply might choose to use your name as I did. Once you enter the name and click OK, the KDE Wallet Manager Wizard appears offering you the basic or advanced setup, with basic being the recommended choice. In the advanced setup, there are a few more information screens and you can choose at that time to create a separate wallet for local passwords. I chose basic and went for the single wallet.
Whichever you choose, at some point the wizard asks you for a master password to open the wallet. This is the super-password, the one you don't want to forget—the one that opens the door to all the others. Choose carefully, and make sure the check box labeled “Yes, I wish to use the KDE wallet to store my personal information” is checked on.
When you've finished the wizard you almost are done. A new dialog box pops up telling you that an application (the wizard) has asked to create a new wallet. You now must confirm this request with the password for that wallet. Take note of this dialog. You'll see something similar to it once per KDE session whenever an application wants to open the wallet to check a password. Until you log out, the wallet now stays open. In fact, visit a Web site where you are asked for a user name and password (such as your bank page). After you have entered the information and clicked Submit or Enter (depending on the form), a new dialog appears from the KDE Wallet Manager telling you that an application (in this case, Konqueror) has requested to open the default wallet (which you just created). Have a look at Figure 4 to see what I mean.
Enter your master password and click to continue. You'll get one final warning telling you that this encrypted information is about to be saved and asking for your confirmation. Click Yes. Now, look down in your system tray, and you'll see that the icon shows a slightly open wallet where before it was closed.
The beauty of this particular system is that all the information is entered magically for you next time you visit a site. This is true of any KDE application that asks you for a password, such as your instant messenger.
There is one catch, however, and it is a big one. As I mentioned, you'll need to enter your master password only once per KDE session, and that makes things easy. But beware: now that you've got your system automatically filling in passwords for you, securing your desktop becomes important. Make sure you lock your desktop before you walk away. Another way to do this is to go back into the KDE Wallet configuration dialog and look at some of the Close Wallet options. You can set it to close automatically after a defined period of time, like when the screensaver starts (when you normally would be away) or when the last application using it is closed. Doing it that way, you have one less thing to remember.
Judging by the clock on the wall, mes amis, it appears that closing time is once again upon us. As you can see, there are a number of alternatives for storing password information so that you do not have to remember dozens or hundreds of cryptic letter and number combinations. Perhaps if we can convince François to use a tool like this in the future, there won't be any more lost orders. In the meantime, I'm sure we can convince him to refill our guests' glasses one more time. And don't worry about the wine supply. I personally will make sure the wine cellar is fully stocked when we next meet. Until next time, mes amis, let us all drink to one another's health. A votre santé Bon appétit!
Resources for this article: /article/7860.
Marcel Gagné (firstname.lastname@example.org) lives in Mississauga, Ontario. He is the author of Moving to the Linux Business Desktop (ISBN 0-131-42192-1), his third book from Addison-Wesley. In real life, he is president of Salmar Consulting, Inc., a systems integration and network consulting firm. He is also a pilot, writes science fiction and fantasy and folds a mean origami T-Rex.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
47 min 41 sec ago
4 hours 23 min ago
- Reply to comment | Linux Journal
4 hours 55 min ago
- All the articles you talked
7 hours 19 min ago
- All the articles you talked
7 hours 22 min ago
- All the articles you talked
7 hours 23 min ago
11 hours 48 min ago
- Keeping track of IP address
13 hours 39 min ago
- Roll your own dynamic dns
18 hours 53 min ago
- Please correct the URL for Salt Stack's web site
22 hours 4 min ago