Starting with Linux can be daunting for longtime Windows or Mac OS X users, and just about everyone who has tried out Linux has had to adjust to the fact that you’re not meant to manage software like you’re used to. This often winds up frustrating users who try to reuse their tried-and-true methods in Linux which often leads to a poor user experience. However, if a new user is willing to learn the basics of how package management works in Linux, they’ll discover the greatest immediate usability improvement that Linux-based operating systems offer compared to their counterparts.

Keep reading for a detailed look at how software management differs on Linux and what users can expect in practical use.

Breaking Expectations

Managing Software on Windows

Windows users are accustomed to downloading a .exe or .msi file from the internet or a CD and running a setup wizard. This results in a new shortcut icon on the desktop and in the start menu, and uninstalling is usually performed either through the control panel or by a start menu entry. As of Windows 8 it seems that the future is moving toward an app store paradigm for managing software, but Windows is likely to retain the current methods for decades to come.

For upgrades, Windows users either rely on the application to automatically check for upgrades or they’ll have to manually check online for upgrades and reinstall that way. System upgrades are done through the Windows Update tool and notoriously frequently require a system restart. The hassle this process poses tends to leave Windows users with a large amount of out-of-date software which may have known security holes.

Managing Software on Mac OS X

Mac OS X users typically either install software from the Mac Store which shows up in the Applications menu or download a .dmg file which typically asks the user to drag and drop a shortcut to the Applications folder. Uninstalling applications is accomplished by dragging the application icon to Trash.

The upgrade situation for Mac OS X users is similar to Windows except that applications installed through the App Store are more readily upgraded automatically. Software installed manually through a .dmg file still needs to either check for updates by itself or be manually checked by the user just like Windows software installed by a .exe or .msi file. System upgrades are, like Windows with Microsoft, issued at the discretion of Apple and are issued separately from other software.

Linux: Enter Package Management

With very little exception, none of these paradigms describe managing software in Linux. Linux employs package managers do manage all software including system software (the Linux kernel, the bootloader, etc), software libraries (required for other software to function), and user applications (such as the VLC media player or the Firefox web browser). These packages are stored in repositories (repos) which are shipped with the distribution you install and can be changed. Package management is often touted by Linux users as one of the best reasons for using the platform if it otherwise suits one’s needs; what we’ll discover is a system that offers the following:

• All software installed with a package manager can be simultaneously upgraded with a single command or button click
• As long as you can trust the distribution’s repositories, all software you install is trustworthy (you can also choose to download the source code with package manager if that’s of interest)
• Installing, upgrading, and uninstalling is all handled through the same interface
• Particularly when using the command-line interfaces, installing software is predictable and can be automated; this makes setting up a fresh Linux install doable with a single script
• The only software upgrades that require a reboot to take advantage of are Linux kernel updates, and if one is using a long term support stable type of distribution these are probably infrequent

At their core, the package managers come in the form of command-line applications accessed from the terminal, and experienced Linux users often gravitate toward accessing them in this manner, but there are also numerous graphical interfaces for these package managers that are more accessible to the average user. For example, Ubuntu features the Ubuntu Software Center (pictured below) which uses the app store paradigm but is really just an interface for accessing packages in Ubuntu’s repositories using the apt package manager. There are lower-level graphical frontends like Synaptic that offer a lot of useful features but are slightly less user friendly than say the Ubuntu Software Center. As is generally the case, Linux never fails to offer vast freedom of choice.

Using Package Managers

I’ll focus on Ubuntu for the following examples due to the distribution’s market share and popularity among new users; the command-line instructions are common to Debian-based (and Ubuntu-based) distributions, and other package managers like yum and pacman function similarly on the command line. Also I’ll generally be foregoing exhaustive details; other easily Googleable guides do a great job of this for covering advanced functionality.

Graphical Package Managers

As noted above, graphical package managers on Linux such as the Ubuntu Software Center are trending toward the app store paradigm. You open up the interface, you are presented with a category list and/or a featured app list, and you may either browse the categories or search for software. For instance, the following Ubuntu Software Center screenshot shows sample search results for “vlc” which is a popular cross-platform video and audio player. This allows for a more familiar and user-friendly experience.

The Ubuntu Software Center, like most of its alternatives, allows the user to browse installed packages and remove items:

Searching is equivalent to searching through the repositories your package manager is configured to use; Ubuntu Software Center for example will use the apt package manager which, as with most things Linux, is also accessible via the command line. If a user chooses to add another repository, software found in this repository will become searchable in the graphical package manager.

The primary difference between using a Linux graphical package manager and, say, the Mac OS X App Store is that because of the all-reaching nature of Linux package managers and repositories, literally all system software is centralized in this graphical interface. That is, not only are user applications available but also core system software and libraries are available: the Linux kernel itself, bootloaders, and software libraries are all available to browse and install in addition to user applications like the VLC media player or the GIMP image editor. Again: in Linux all software is centralized rather than having a gap between system and user software.

Terminal Interface Package Managers

As is often the case with Linux, everything you can do in a graphical interface can be accomplished using command-line tools in the terminal; many experienced users find a high level of comfort and enhanced efficiency when working in the terminal. I’ll try and help illustrate how this can be the case by showing the basic functionality of the apt package manager.

First, one typically updates their package list by syncing with the repositories (other package managers bake this functionality in with other commands):

sudo apt-get update

Notice that a lot of package management actions require root privileges which is why sudo was used here. In the sample output above the lines like saucy-backports/multiverse is an example of an Ubuntu repository. Now let’s look at probably the four most common apt functions:

• Upgrade all installed packages

  sudo apt-get upgrade
  

Notice how both firefox (a web browser, a user application) and grub2 (a bootloader, a core system application) are both handled by the same utility.

• Search for a package (for example, VLC)

  apt-cache search vlc
  

• Install a package (for example, the Chromium web browser)

  sudo apt-get install chromium-browser
  

• Uninstall a package (for example, the Chromium web browser)

  sudo apt-get remove chromium-browser
  

Note here that one can install (or uninstall) many packages at once:

sudo apt-get install libreoffice-writer libreoffice-calc vlc chromium-browser

and so on. Immediately one powerful use is clear: one can write a script to run when they do a fresh install of their OS that installs… everything. It might look like:

1
2
3
4
5
6
7
8
9
10

#!/bin/bash

sudo apt-get update

sudo apt-get install \
libreoffice-writer \
libreoffice-calc \
vlc \
chromium-browser \
firefox

and here the \ was used to split a single command into multiple lines.

The Rare Case: Not Using Package Managers

While it’s uncommon for typical users, there is some software generally not found in a distribution’s repositories due to licensing or other legal issues, the distribution’s principles, or other reasons. On occasion software will be available on the web for download as a .deb file (or for RPM-based distributions a .rpm file) – this is a Debian package just like one would install using the apt package manager. The difference is software installed this way generally won’t be automatically upgraded with the rest of the system’s packages so this is more similar to installing a .exe or .dmg file in Windows or Mac OS X.

Installing software this way is pretty simple: download the .deb file and double click it in the file manager. Ubuntu will install this using the Ubuntu Software Center, and other distributions may come with other graphical alternatives like gdebi. Alternatively, one can use the command line:

sudo dpkg -i /path/to/package.deb

Again, software that is only available this way is rare. The most common case that I can think of is the proprietary Google Chrome browser (note that the open-source Chromium browser is essentially Chrome without certain proprietary Google built-ins, and this is typically found through the package managers of all major distributions). The interesting thing about this case is that when you install Google Chrome’s .deb package it also adds a repository so that upgrading through your package manager also upgrades Chrome, so in this case the only hassle is fetching the .deb package online. Other software may not do that and will need to be handled manually.

Closing Thoughts: A Case Example

As I started on my own Linux journey I quickly found myself frequently switching distributions (or distro-hopping), and early on this was mainly constrained to different Ubuntu flavors (Ubuntu, Xubuntu, Kubuntu, etc) every time a new release occurred on those exciting April and October days. It wasn’t too long until I discovered how easy it was to automate setting everything up cleanly again after another fresh install by writing a single shell script. A snippet of one of the scripts I used for setting up Ubuntu a while ago follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

#!/bin/bash

read -p "Input username: " username

echo "Modifying /tmp to ram disk in fstab"
echo -e "tmpfs\t/tmp\t\ttmpfs\tdefaults,noatime,mode=1777\t0\t0" >> /etc/fstab
echo "Modifying swappiness and vfs_cache_pressure"
echo "vm.swappiness=1" >> /etc/sysctl.conf
echo "vm.vfs_cache_pressure=50" >> /etc/sysctl.conf

echo "Adding ppas..."
echo "Adding apt-fast ppa..."
add-apt-repository -y ppa:apt-fast/stable

apt-get update
apt-get install -y --force-yes apt-fast

echo "Removing some bloat..."
apt-fast remove -y --force-yes --purge \
aisleriot \
brasero* \
deja-dup \
empathy* \
gnome-contacts \
gnome-mahjongg \
gnome-orca \
gnome-sudoku \
gnome-mines \
gwibber* \
landscape-client-ui-install \
onboard \
rhythmbox* \
simple-scan \
thunderbird \
totem* \
ubuntuone* \
unity-lens-gwibber \
unity-lens-music \
unity-lens-photos \
unity-lens-shopping \
unity-lens-video \
unity-scope-gdrive

apt-fast autoremove -y --force-yes --purge

echo "Preparing to install packages..."
apt-fast install -y --force-yes \
djview-plugin \
faience-icon-theme faience-theme \
fail2ban \
filezilla \
frotz \
gimp gimp-data-extras gimp-plugin-registry \
git \
gparted \
grsync \
guake \
htop \
iftop \
indicator-multiload \
iotop \
keepassx \
links2 \
lm-sensors \
nethogs \
numix-gtk-theme \
openssh-client openssh-server openssh-blacklist openssh-blacklist-extra \
p7zip-full p7zip-rar \
pdfshuffler \
pidgin \
powertop \
psensor \
python-bs4 python-html5lib python-lxml python-matplotlib python-mechanize python-numpy python-scipy cython \
r-base r-base-html \
ranger \
screen \
scrot \
sshfs \
synergy \
sysstat \
ubuntu-restricted-extras \
unity-tweak-tool \
vim vim-gtk \
vlc vlc-plugin-pulse

echo "Setting up sshfs..."
modprobe fuse
adduser $username fuse
chown root:fuse /dev/fuse
chmod +x /dev/fuse

echo "Initializing sensors"
sensors-detect

You can see how this script combines modifying certain system configurations, updating software repositories (through what is called a ppa in this case), and removing, upgrading, and installing packages all in the confines of one script. There are plenty of other more user-specific things one can include to set everything back up with a script like this, but the point here is how efficiently we can set up a system exactly how we want it thanks to Linux paradigms like package management and command-line utilities. I would encourage everyone to keep an open mind in this regard and see where their own explorations lead them.

What follows is a discussion on how to use file sync software like Dropbox and encryption software like TrueCrypt to securely and conveniently access an offline password database like those created through KeePassX on every device. The idea is to create a small encrypted file container with TrueCrypt, place the password database inside of it, and sync the file container using Dropbox. Then on any device access the file container in Dropbox, decrypt and mount it with TrueCrypt, and load the password database with KeePassX; this only has to be done once until a device is shut down. The result is a highly secure and convenient way of managing online account credentials.

A thorough look with all the details follows.

I Have a Local Password Database, Now What?

Suppose you followed my advice in the Basic Edition and have created an encrypted KeePassX password database that now contains all the credentials and security questions for your online accounts in one easy-to-use bucket. This is a local solution so the password database resides on your computer, but maybe you have multiple computers and mobile devices. Also, as I mentioned there this does place all your eggs in one basket so to speak so securing that basket is critical. There’s a nice and secure way to fix these problems without resorting to trusting a closed source platform like LastPass to manage both their and your security. I propose using two applications to help accomplish this task: Dropbox and TrueCrypt.

Dropbox

Dropbox is a cloud storage and file sync service. For the uninitiated, you download the client software, create an account, and a special folder called Dropbox will be placed in your computer’s home folder. All files placed in here will be synced and stored online on Dropbox’s servers (Dropbox claims to encrypt the transfers and storage), and any other devices you install Dropbox on will have access to these same files. Dropbox was the first such service to really catch on due to its simplicity, and I believe it’s still the best for a few reasons:

• It’s fully cross-platform (they even support installation on a headless server)
• Its sync times are faster than the other cross-platform alternatives
• It’s a very hands-off solution; all the magic happens without your intervention

That being said some alternatives are Google Drive, Microsoft SkyDrive, and Box. None of these meet all three points I listed above in my experience.

Whatever your choice (I’ll assume Dropbox for the remainder but the procedures are the same), these sorts of services will clearly solve our problem of having a local password database on only one device in the easiest manner possible; just use the service to sync the database and use KeePassX to load it wherever you go. However, since Dropbox requires trusting your data to Dropbox’s servers there is a degree of risk and concern for privacy despite their use of server-side encryption; there have been a few snafus but no reports of data theft. Regardless, it would be ideal not to have to trust your collection of online account credentials to a third party’s security; as we’ve seen before perfect security doesn’t exist, and the more layers we can add without sacrificing much convenience, the better. This leads us to…

TrueCrypt

TrueCrypt is open source cross-platform encryption software that can be used to, among other things, create strongly encrypted file containers. These containers appear as a regular file with size equal to the storage space allocated to the container and, once mounted and decrypted, allow the user to store and access any data inside. In case you’re unfamiliar with the software you may consult the official documentation or my overview of TrueCrypt; while it’s reasonably straightforward there are some considerations such as choosing between standard volumes and hidden volumes that employ plausible deniability methods.

Immediately it’s clear how TrueCrypt can be used to alleviate the problem of placing all of our trust in the hands of Dropbox. Instead of syncing the encrypted password database which, if stolen due to a Dropbox security lapse, might be subject to some vulnerability in KeePassX encryption or a brute force attack if you used a weak password (memorize a strong password instead!), one can sync an encrypted TrueCrypt file container which holds the KeePassX database.

Putting it Together

Now we’ve seen all the pieces of this scheme for conveniently securing your online account credentials without needing to completely trust a single third party: KeePassX, Dropbox, and TrueCrypt (or your preferred equivalents). This is how it all fits together:

Setup

1. Gather all of your online account credentials into an encrypted password database using software like KeePassX, ideally using it to create maximum length random passwords for each account.
2. Create an account for Dropbox or a similar file sync service and install the client software on all of your devices.
3. Create a small encrypted file container with TrueCrypt or equivalent software, place the KeePassX database inside of it, and move the file container to Dropbox to be synced.

Every Day Use

1. Any time a particular device is rebooted, mount the TrueCrypt file container.
2. Open the password database found inside the mounted file container using KeePassX.
3. Any time you need to log into an account, copy and paste the credentials using KeePassX (by default these credentials are cleared from the clipboard after 20 seconds).

By the Numbers

• Number of one-time steps each time a device is rebooted: 2
• Number of passwords to remember: 2
• Effort to take to log into any of your accounts: click (to copy username), paste, click (to copy password), paste

Concluding Remarks

When most people hear words like encryption and security they think of things that get in the way of doing what needs to be done — things that complicate their life. I would simply ask whether the reality laid out in the By the Numbers section above is more or less complicated than memorizing any number of usernames, passwords, and security questions, sometimes being required to change them frequently, and possibly resorting to sharing credentials between accounts.

It’s not often one can enhance both security and convenience at the same time but I suggest this is one of those times.

These days talk of the NSA’s PRISM program and its other surveillance programs tend to be the focus of privacy discussions, but recent gaffes like at yesterday’s Super Bowl XLVIII and more serious incidents such as during the trial of George Zimmerman for Trayvon Martin’s murder show us that the average Joe can cause serious privacy leaks as well.

I give an overview of these events and offer a suggestion on the sort of vigilance you should keep in mind.

Super Bowl XLVIII as a Case Study

During yesterday’s Super Bowl there was an amusing incident in which the stadium’s internal wifi credentials were broadcast on national television; social media pounced on this and spread a snapshot of the monitor displaying the credentials rapidly. This incident serves to illustrate that privacy breaches can happen much closer to home than those focusing on the NSA might be most wary of. Indeed, while companies like Google and Yahoo received 59,000 NSA demands for account contents over the past six months, having everyone in your vicinity being made aware of your wifi SSID and password or more sensitive information is probably a more immediate and tangible concern and much more likely to happen to ordinary, boring (to the NSA) individuals.

The Zimmerman Trial Leaked Personal Information

The media — cameramen in particular — were responsible for the aforementioned Super Bowl wifi incident; they were also responsible for a much more dangerous breach of privacy. During the highly polarizing and controversial trial of George Zimmerman for the murder of Trayvon Martin, CNN broadcasted unredacted footage of Zimmerman’s personal identifiers including his date of birth, address, phone number, and most alarmingly his social security number.

However one felt personally about Zimmerman prior to the outcome of the trial, nobody deserves to have their personal information leaked against their will especially when they’re at the epicenter of such controversy and polarization. All of these personal identifiers are often used to verify one’s identity for healthcare and a variety of other services. One hopes that representatives of the various services Zimmerman used were alerted and were able to catch on to what was likely a deluge of attempts to mine more of his personal information or disrupt his life by engaging in identity theft, but this is very wishful thinking; when attacks like this are successful they are very costly and troublesome to recover from. At the end of the day this was all due to the negligence of one ordinary cameraman.

Again, it wasn’t a nebulous United States government entity but instead a nearby individual who was the biggest cause of concern.

When Will Your Personal Information be at Risk?

To be sure, most of us probably won’t find ourselves in a situation where we need to manage some sort of secret information in an at-all public area, and I’m not going to pretend it’s worthwhile being overly vigilant about those around you beyond reasonable common sense. Instead, given the nature of the incidents I’ve mentioned, I’m going to urge caution with others’ personal information if it could ever come up as part of your job or regular life.

One of the projects I worked on in the past involved thoroughly tagging images with metadata, and in a legacy system there was one entry of distantly personally identifying information temporarily stored in the images to facilitate a process. Had I overlooked this and not purged the metadata afterward it would be possible for several images to be floating around the web tagged with some weak identifiers, but even weak identifiers can be used to discover more confidential information; the age of big data, machine learning, and predictive analytics on the whole prove this beyond a shadow of a doubt.

While I’ve discussed how absolute security is impossible, there’s a difference between building a secured website that may be breached by a concerted and resourceful effort and building a website that advertises potential attack vectors. Several websites are guilty of this and do things like email plaintext passwords or use unnecessarily restrictive password rules; these problems tend to make it much easier for an attacker to compromise user credentials.

For a more detailed look into the problem and ways to begin mitigating it, read on.

Raising Awareness: Plain Text Offenders

I discovered an excellent website the other day called Plain Text Offenders that catalogs websites caught storing passwords in plaintext. Websites like this deserve to be shamed because it’s a potentially serious security issue: look at the recent Yahoo account password breach that caused quite a stir; this attack was at least partially facilitated by username/password credentials collected from other websites that happened to be reused for Yahoo email accounts. Often when username/password combinations are seized from unsecured websites the attackers either reuse them for further attacks as was the case with Yahoo, sell them, or publish them publicly (this is trivially available through a search for ‘pastebin username password combinations’ and is an excerpt of releases from the 2012 Twitter password breach).

A website storing plaintext passwords is also likely to have weak security leading up to access to their database itself so these websites are potentially easy and lucrative targets for attackers. It’s like a bicycle thief: even if they have the means to break through a bike locked with both a U-lock and chain lock, if there’s another bike of similar value with just a rusty old chain lock why bother stealing the first one?

Know Your Hashing

For the following discussion I’m going to assume a basic working knowledge of what a cryptographic hash function is and its basic properties; the uninitiated might want to consult the Simple Wikipedia article; otherwise, I’ll try to give a brief rundown.

A cryptographic hash function is a way of converting some data — for our purposes this data will be a plaintext password — into a fixed-length string called the hash value. For instance, one of the older hash functions (which, for the record, should never be used for passwords) is called MD5, and MD5(“123456”)=e10adc3949ba59abbe56e057f20f883e. A hash function should have these properties:

1. It can be easily computed in less than a second (note: for passwords, faster isn’t better)
2. It is extremely difficult (computationally and ultimately financially expensive) to reverse engineer, or invert, the plaintext password from the hash value
3. It is extremely rare for two distinct inputs to give the same hash value (known as a collision)

When it was made in 1991 MD5 seemed like a fine hash function, but these days it’s very trivial to invert MD5 hashes and there are modern alternatives much more appropriate to current needs.

The Red Flags

Plain Text Offenders performs what I consider to be an important public service by calling out these websites that store passwords in plaintext. With a basic understanding of hashing in hand, let’s look into why this is an issue and also consider some other common practices that may be troublesome and at the very least merit vigilance.

Password Recovery Emails Containing Plaintext Password

This case is the focus of Plain Text Offenders. Some websites allow you to “recover” your password which results in receiving an email containing the plaintext password itself. If you registered with a password of “123456” then you receive that exact string in the email. There are two important issues with this.

First, if a website’s security is compromised then there’s nothing in the way of the attackers immediately commandeering every account. Keep in mind how there is no such thing as perfect security; given enough motivation and effort, any website will be able to be compromised. The likelihood of developers properly securing the website and then leaving passwords stored in plaintext is effectively zero; if you’re able to receive an email like this, be worried and do not share that password with any other accounts — delete the account if possible.

If passwords are even weakly hashed then attackers will have to expend some time and effort to determine the plaintext; if the website administrators happen to be on their toes and the breach is detected then this gives them time to reset passwords and notify their users. If passwords are properly strongly hashed then attackers may not be able to determine the plaintext at all unless they’re very well-funded, and even then it can take a very long time.

Second, email is inherently insecure as it’s an unencrypted form of communication susceptible to man-in-the-middle attacks. This is a less likely avenue of attack since it typically requires some sophistication; the NSA has been impersonating Google servers to do this for example, but “average” attackers are less likely to try.

Password Reset Emails Contain the New Password

Sometimes when you use a website’s password reset functionality this results in receiving an email containing the new password. This doesn’t necessarily mean that the website isn’t hashing this new password as they could have stored the hash value after sending the reset email, but that’s still a real concern.

Beyond this we return to the insecurity of email described in the previous paragraph: the new password can still be intercepted by a determined attacker. Last but not least this leaves a copy of your plaintext password in your email; if you leave your email open and leave the room and a physically-nearby attacker searches your email for “password” then suddenly they have your login credentials.

Registration Limits Password Length and/or Punctuation

It’s the norm for there to be some limits on the length and acceptable characters for a password; this is smart since it would be unwise to allow arbitrarily long form inputs with an uncertain character set that could cause problems with your system. However, the problem comes with overly restrictive limitations. The worst I’ve seen has been forcing passwords to be 6-12 characters and alphanumeric only (no punctuation or spaces). This is a very bad practice.

1. If repeated login attempts aren’t properly limited then a short upper limit makes brute force guessing of a password trivial
2. Restrictive limitations on length and accepted characters means that an attacker has far fewer possibilities to deal with when trying to determine the plaintext; if the website doesn’t use a hashing procedure that defeats brute force attacks then these passwords aren’t secure
3. Restricting punctuation brings into question whether the website is cleansing user input to prevent SQL injection attacks
4. Restrictions like this make one question how the website is storing passwords in the first place; some websites might restrict the length because they’re storing these passwords in plaintext in their database with a fixed-length storage type

While these problems are just speculative, they’re all possible inferences based on these restrictions and a malicious attacker will take this into account. I genuinely put on a wide smile when I encounter a website that allows a 100+ character password using any character on a standard QWERTY keyboard.

Conclusion: Education is Key

I can only imagine that the website administrators just aren’t aware of either the implications of their password storage practices or the ease of implementing a decent hashing algorithm. Plain Text Offenders has a section dedicated to praising former offenders who reformed their ways and secured user passwords. Contacting website administrators when you notice poor practices with a constructively written suggestion is a good way to help.

A recent social engineering attack on PayPal and GoDaddy allowed an attacker to commandeer the victim’s email on GoDaddy and hold his Facebook account hostage in order to facilitate the transfer of the @N Twitter handle (reportedly worth about $50,000 USD) to the attacker. This incident illustrates how organizations fail to train their representatives to resist old and simple social engineering techniques. More broadly I use this as a case study with which to demonstrate how no matter what, we can never have absolute security when it comes to safeguarding our online presence; between social engineering attacks and zero-day exploits we can always expect there to be a weak link in a long chain of security.

Read on for full details.

A Social Engineering Case Study

There’s been a lot of buzz surrounding Naoki Hiroshima’s harrowing ordeal in which an attacker used social engineering techniques to commandeer Mr. Hiroshima’s GoDaddy email account; the goal of this attack was to obtain his @N Twitter account, a coveted single-letter Twitter handle allegedly worth no less than $50,000 USD. Once the attacker obtained the upper hand by seizing Mr. Hiroshima’s Facebook account and succeeded in having him hand over the Twitter account, he explained his methods.

Posing as a PayPal employee, the attacker had called PayPal and obtained the last four digits of Mr. Hiroshima’s credit card. With this in hand he was able to call GoDaddy and feign having lost the card he used to purchase a domain name; using these last four digits he was allowed to guess the first two until he got it right and finally reset the account’s security. That was all it took to get to the Facebook account which was enough encouragement for Mr. Hiroshima to hand over the Twitter account.

There are some other technical particulars involved but the point here is the way social engineering techniques can, without much trouble, bypass both traditional and advanced account security measures.

Old Tricks

Social engineering attacks aren’t remotely new. I’m not familiar with the earliest history, but to further the point take this wonderfully cheesy scene from the 1995 film Hackers in which Jonny Lee Miller’s character coaxes a security guard into providing information about a modem’s hardware which helps him break into their systems. In any event, this is not a new idea and there are numerous examples to be studied but, as the recent events involving Mr. Hiroshima illustrate, not necessarily learned from. Consider some other not-exactly-groundbreaking security mishaps:

• Apple’s Flashback Trojan incident caused by an unpatched Java version; Apple took three months since the exploit was originally published and fixed to release the patch to end-users
• Snapchat had 4.6 million user name and phone number combinations published owing to, fundamentally, a lack of rate limiting and bot abuse prevention in their API but also by failure to respond to an exploit disclosure by white hat security researchers
• Several D-Link routers were found to have a backdoor in their firmware that would allow an attacker to alter the device’s settings thereby allowing several attacks

The Problem of Trust

The examples of breaches I’ve outlined so far boil down to needing to place at least part of your security in the hands of a third party. It’s effectively impossible to eliminate the need to trust third parties while using any sort of online technology. In 1984 Ken Thompson described a theoretical hack based on a compromised compiler that would result in a nearly undetectable backdoor that couldn’t be avoided without unplugging your hardware and putting on a tin foil hat. Regarding more tangible events, among the recent NSA spying revelations was an allegation that the security company RSA may have created a backdoor for the NSA in one of their encryption algorithms; the details are fairly technical and mathematical but essentially a random number generator can be constructed in a poor way so as to make the numbers predictable — this would disrupt the strength of the encryption.

Whether due to negligence in the case of PayPal, GoDaddy, Apple, Snapchat, and probably D-Link or due to malicious intent in the case of the Ken Thompson hack or (allegedly) the RSA collusion, trusting a third party can be a necessary weak link in one’s personal security. Ultimately this boils down to relying on humans who, like all of us, are liable to make mistakes or be influenced into making unethical decisions. This will never change, and this will always be an attack vector for security breaches.

Forget Trust: Zero-Day Exploits

The impossibility of absolute security isn’t just down to negligence and manipulation; there’s a simple universal fact of software engineering: we can never expect any software to be completely secure and unexploitable. Ever. There’s an unending struggle between white hat and black hat hackers; white hats continuously try to penetrate their own systems so as to fix security holes while black hats attempts to beat them so they can profit or otherwise benefit from it. Sometimes the black hats get there first, and that’s what constitutes a zero-day attack: one that hadn’t been discovered previously and is actively being exploited.

In 2008 a security flaw in Microsoft Internet Explorer was discovered that would result in victims losing control of their computers and passwords; this was said to affect all versions of the browser dating back to 2001. A 2012 study by Symantec researchers suggested that black hat hackers have an average of ten months before details of an exploit are made public.

There are entire black markets devoted to selling exploits and more recently efforts by companies like Google, Microsoft, and Facebook to offer competitive bounties to white hat security researchers for finding and reporting exploits. The risk of this sort of attack can never be eliminated, and preventative measures focus on a combination of investment in security research by the software developers and by prompt updates by end-users; neither is a trivial expectation by any stretch.

Conclusion: Abandon all Hope?

No, not quite. While it’s important to be aware of this unfortunate truth, it shouldn’t stop an individual from doing the best they reasonably can to secure themselves. This can involve improving the security of your online accounts and keeping your systems up to date. Dialing your security down to 0 just because you can never ramp it up to 100 isn’t wise — Sony learned that the hard way. Beyond this we can try to find reasonably easy ways to safeguard our personal data; I hope to cover some notable methods in the coming days.

There are some particular perceptions among many non-Linux users that in order to use Linux one must be

• Willing to resort to the command line to accomplish mundane tasks
• A computer science major
• Able to find and rely on others to use their own system

While I disagree with these views on the whole, I think there is a degree of merit provided one applies a more level-headed tone to the rhetoric; instead of discussing that I’d like to consider why these perceptions exist. I propose that a major cause is the vast fragmentation of the Linux platform.

While Linux fragmentation offers truly — without exaggeration — unparalleled freedom of choice when it comes to customizing one’s computing interface and workflow, this can make offering help to any individual through their particular GUI very cumbersome. Consequently, the terminal becomes the common denominator since there are only a few common Linux filesystem layouts in use by the various distributions and the GNU Core Utilities can be assumed to be installed on any Linux system. This makes offering terminal commands the most direct approach for most people offering assistance to others, and this helps bolster the aforementioned perceptions: if everyone is receiving help through terminal commands, surely this is the only way to fix these problems.

The best we can do is accept that some people will feel this way and attempt to educate them on the benefits of computing diversity and choice; whether this is important to them or not is their choice, and perhaps they’ll come around to appreciating this diversity.

Keep reading for a more thorough analysis.

A Particular Case

Today I was reading a question about permissions from a new Linux user having troubles with reading some files on external storage drives. What really caught my eye about this wasn’t the subject of the question itself but rather a comment in the first reply:

have not tried the command line method from >terminal. Don’t understand the structure.

I’d suggest learning the rudiments of using the command line. Most folks here that can help you out will need you to enter commands from said command line.

This is a very common phenomenon: a new or otherwise terminal-illiterate Linux user runs into a problem and asks around for help, and often this help comes in the form of commands to enter in the terminal to help diagnose the problem. This in turn leads to negative attitudes toward Linux even from people merely observing this sort of thing:

• You can’t use Linux without using the terminal
• Linux is only for computer science majors
• Nobody could use Linux on their own

There’s a degree of truth to each of these points provided you add some reasonable and level-headed qualifiers. I propose that Linux fragmentation is one of the leading reasons that users asking for help receive it via terminal input.

An Open Platform

Let’s think about the two major computing ecosystems in play for end users: desktop and mobile.

Mobile: iOS Compared to Android/Linux

Disclaimer: I’ve used both Android devices (in the Nexus family) and an iPhone 4S; I happily prefer Android

iOS is of course a very locked-down and closed platform — no sane person would argue this point. You get your One Interface and you had better like it; the ability to customize it is minimal and the options in general are very limited. The OS, which most users are generally on the latest version of, resides on one of just a few hardware variants. This makes it very straightforward to troubleshoot any problems — which, in principle, should be few and far between since the software is tailored for about as many hardware variants as you have fingers — since you can always direct them to a predictable menu or whatever is needed.

Compare this to Android where there is a much broader representation of OS versions in use and for each version it might be on any number of hardware variants even per device model; the Samsung Galaxy S III shipped with different chips in the Korean version and the US version. Finally, you have different manufacturer skins (HTC Sense, Samsung TouchWiz, etc) that have wildly distinct interfaces, and on top of that you could have carrier-specific bloatware that may need to be taken into consideration as well. This results in a massive range of distinct ways to go about addressing an individual’s problem; even if you’re trying to help someone with the “same exact” device as you, carrier bloatware alone could render one individual unqualified to offer assistance. Finding a common denominator to start at when giving assistance becomes a daunting task indeed.

Here are some reference stats and figures about the distribution ofAndroid and iOS versions. It must be said that Google has been improving the situation recently and we can expect it to improve more going forward, but based on recent data we have:

iOS

• 78% iOS 7
• 18% iOS 6
• 04% Earlier

Android

• 01.4% 4.4 KitKat
• 59.1% 4.1.x-4.3 Jelly Bean
• 16.9% 4.0.3-4.0.4 Ice Cream Sandwich
• 00.1% 3.2 Honeycomb
• 21.2% 2.3.3-2.3.7 Gingerbread
• 01.3% 2.2 Froyo

Additionally, TheVerge has put together superb interactive figures illustrating Android fragmentation in terms of model, OS version, and screen size, and I invite you to have a look at them if for no other reason than to see best-in-class examples of how to meaningfully illustrate data. In any event, the differences are clear.

Desktop: Mac OS X Compared to Desktop Linux

Here when I refer to the “desktop” I include laptops. I’m going to ignore Windows for the purpose of this comparison as I feel it has additional variables not relevant to this topic, such as being the top target for malware, that must be weighed for a fair comparison.

Mac OS X, like its mobile cousin iOS, is a tightly closed OS that runs on a very limited range of hardware — you might need both toes and fingers to count the variants this time though! The same points apply: there are few customization options and excepting those who enter the realm of Homebrew or MacPorts and take things very far, you can easily predict the interface and system of someone you’re trying to help.

Finally we arrive at Linux, the most diverse computing platform in existence. Consider the prominent factors that vary from system to system:

• Hardware: Every desktop PC hardware combination is liable to have Linux installed on it
• Distribution: Do yourself a favor and look at the GNU/Linux Distribution Timeline: diversity incarnate. Every line that terminates on the right edge should be an active and supported distribution. Whether the distribution is based on Red Hat, Debian, Ubuntu, Arch, Gentoo, etc, the layout of system files, software versions, and maintainer patches will vary
  • Desktop environment: Each distribution is liable to have any of a number of desktop environments installed; GNOME, KDE, Unity, and Openbox are among the more popular, but rest assured there are plenty of alternatives
  • Version: Most distributions are liable to support many versions of the OS at a time; Ubuntu for instance is currently set to support three Long Term Support releases and up to three in-between point releases that are released every 6 months and supported for 9
• User Software: Users are liable to install any number of fundamental software (file managers, web browsers, package manager frontends etc) beyond the defaults; the variety here is again far greater than any other OS

Alright… I think you’re starting to get the picture.

Too Much Choice?

The clear benefit of this choice is that if someone is willing to search around the variety of Linux installs they’re very likely to find a setup that feels optimal for their uses. It’s like Goldilocks: Windows or Mac OS X is likely to be “too hot” or “too cold” in some respects (even if the user isn’t aware of it due to never having experienced an alternative), but with enough experimentation Linux can offer that wonderful “just right” setup.

This freedom of choice comes at a clear cost: if you try to help someone in need of assistance and you try to help them in terms of their particular system’s GUI, you’re likely to spend more time figuring out the particulars of their setup than you are actually solving the problem.

The Great Unifier: The Almighty Terminal

So it comes down to this: what’s the easiest way to help someone with a problem? Their GUI is subject to so many degrees of variability, but at the end of the day they’re running a Linux-based OS with only a few major variants of the file system’s setup to deal with, and they’ll always have GNU Core Utilities. This means you can, without much guessing, give the user commands that they can copy and paste into a terminal to extract relevant diagnostic information or to outright solve the problem if you’re given just the distribution and version.

Combine this observation with the unavoidable fact that a lot of advanced Linux users find themselves drawn to work in software engineering or system administration, where there is a substantial amount of work liable to be done optimally or necessarily via the command line, and you have a community of very knowledgeable individuals who have several strong reasons to offer help using the command line if there isn’t a clear and unambiguous GUI solution available.

Conclusion: A Perception We Must Endure

It’s my belief that most technically-inclined users who experiment with Linux and stick with it for any meaningful period of time will gradually be drawn to doing more work in the terminal; one of the critical factors in this is typically finding readily-available help in the form of terminal commands. I think I’m not alone in remembering my early days of copying chmod commands into the terminal, utterly bewildered by those mysterious numbers or letters.

I don’t think that this will ever change so long as the Linux ecosystem maintains or increases its current level of diversity. Therefore, I arrive at the conclusion that we’ll need to simply accept the fact that some people will look down on the platform because so many new users are offered help that isn’t strictly GUI-based; we can try to educate them on the causes of this and offer our opinions on the benefits of diversity — perhaps one day these individuals will have some interest in experimentation and will come to appreciate computing variety for themselves.

Sharing credentials (username and passwords) between the numerous online accounts we have is a difficult dangerous habit to break. I propose the following steps as a manageable way to fix the problem:

• Select password database software like KeePassX or LastPass and if necessary complementary mobile apps
• Track down all of the online accounts you’re aware of and scour your email account(s) for accounts you’ve forgotten; for each account:
  • If you no longer care about the account, delete with prejudice (pkill -9 $account) if possible
  • If two-factor authentication is available, set it up
  • Remove any non-critical personal information, especially from legacy accounts
  • Generate a unique random username (if you can change it) and password (with maximum length and largest dictionary) and store it in the password database
  • If a security question is required, create an entry in the password database for a random answer and make note of the site and question in the database entry
• Lock down the security of your password database; use a unique, memorable, and strong password and see the Advanced Edition (coming soon) for more details
• Enjoy the ability click a few buttons to log into your accounts!

Read on for full details.

Motivation and Recent Password Leaks

Passwords for most people are just an annoyance. A common scenario is that an individual has:

• up to just a few basic easy-to-remember short passwords they use as much possible
• a simple way of modifying a password only when a site forces them to do so by its unique requirements
• the same security questions/answers used as often as possible, sometimes unknowingly with publicly-identifiable or otherwise easy-to-find information

From an information security perspective this is disastrous although you can hardly blame these individuals on the state of things; passwords are antiquated and increasingly ineffective given the number of accounts most people have lying around. Indeed, Google is among those trying to replace password-based security with a Universal 2nd Factor, or U2F physical key among other approaches.

That is all for the future though; what we have is a potentially dangerous situation where any single site’s security being compromised could lead to several other of a user’s accounts also being compromised due to credential reuse. We live in this unfortunate reality where corporations and other entities have suboptimal or outright poor security practices that allow data breaches to lead to actual username/password combinations and personal information in the hands of criminals.

LinkedIn was one such corporation with poor security practices that resulted in no less than 3.5 million plaintext passwords being dumped publicly, and the original attackers would have both email and password combinations. Ok, so you’re a tech geek and you caught wind of this story and changed your LinkedIn password? Well, that’s a start, but if you have any accounts also using that password then they’re at risk as well; Facebook, being aware of this, responded to the recent Adobe security breach by warning its users and prompting security questions and a new password.

For those interested in a more comprehensive list of recent password breaches I advise consulting my long list of password breaches.

A Light at the End of the Tunnel

Even if your password security situation isn’t the worst case described above I invite you to ask how close your situation is to the current optimal:

• Every single account has a unique random username (where possible) and password with as large a dictionary as possible
• Every security question has a randomly generated answer
• All credentials are as long as an individual website will allow
• When possible, use two-factor authentication
• A minimum of personal information is stored with each account

Sounds… feasible, right? Ok maybe it sounds absurd and unreasonable, but these days it’s completely possible to accomplish this in a highly secure manner that is also easy to use (at least easier than remembering which of the twenty variants of a weak password goes with which site).

Password Management Software

The biggest piece of the puzzle is the software that manages passwords for you. I’m going to highlight two popular solutions, one of which is online-only and closed source and the other offline-only and open source:

• KeePassX (cross-platform)
  • KeePassDroid (Android)
  • MiniKeePass (iOS)
• LastPass (cross-platform)

Note that whatever your choice is, use a strong password to access the database! This is going to be one of the last passwords you ever need to memorize and will also be one of the larger security bottlenecks in this scheme, so make it count.

KeePassX

I’ve written a KeePassX tutorial if you’re not familiar with this sort of software — it’s fairly straightforward but there are some details to get the most out of its security offerings.

Mobile

To access your password database on your mobile device you’ll need an appropriate app; for Android I prefer KeePassDroid and for iOS the highest-rated app I’m aware of is MiniKeePass, though I can’t vouch for it.

LastPass

LastPass is a web-based analog to KeePassX; it follows the same concept except the encrypted password database is stored on their servers. In my opinion this is a good reason to go with a locally-stored solution like KeePassX over LastPass; while KeePassX is open source (meaning you have the ability to audit the source code yourself) and local (meaning your security is still entirely in your hands), LastPass requires you to trust the security of LastPass’ closed-source implementation which also requires securing a web app against the entire black hat population. Remember that part of the motivation for randomizing our login credentials like this boils down to being unable to trust online services to use the best (or even better-than-awful) security practices. That being said there have been no attacks against LastPass to date that have verifiably leaked any customer information, and as their user base would presumably diminish severely if such a breach occurred they have a strong financial interest to keep their security optimal.

At the time of writing I haven’t used LastPass myself, but it is well-reputed and follows the same principles as KeePassX so it serves the purposes of this guide. I’ll leave the documentation in the hands of their website; note that it seems that their mobile app requires purchase.

Two-Factor Authentication

This is a method of bolstering the security of password-based authentication; services like battle.net, Google, GitHub, Twitter, Facebook, etc all offer it in some form. The idea is you’ll either receive a specific physical device, install a mobile app, or receive an SMS message to provide the “second factor” of authentication: usually a constantly regenerating single-use code. In other words, not only do you have to know the password but you also have to be in possession of a physical device in order to log into an account. This isn’t completely failsafe, and targeted malware can still do things like perform man-in-the-middle attacks to steal user credentials. Still, it’s going to prevent the shared-credential vulnerability.

Almost every two-factor authentication system I’ve encountered is compatible with Google Authenticator (Android and iOS), and setting it up can usually be done just by scanning a QR code with your phone. Once set up you’ll just pull up the app when logging in and after providing your username and password you’ll also provide the single-use code you receive.

Securing Your Online Presence

We’re almost there! Let’s recap our goals:

• Every single account has a unique random username (where possible) and password with as large a dictionary as possible
• Every security question has a randomly generated answer
• All credentials are as long as an individual website will allow
• When possible, use two-factor authentication
• A minimum of personal information is stored with each account

Finding the Accounts

Once you’ve acquainted yourself with your choice of password management software, the path to accomplishing the above goals is visible. Unfortunately now comes the most tedious part; depending on how much of an online footprint you’ve accumulated this could take the better part of a day. You need to track down as many accounts as possible; this might go back well over a decade. Think about it: the weak link could be a random forum from your youth that had no sense of security and is still up and running, and if you shared those credentials with other sites then the potential problem is clear.

You can remember most of the recent websites you’ve dealt with but your strongest resource for tracking down any accounts you’ve forgotten about will be your email account(s). Try searching your email for terms like “username,” “verify,” “verification,” “noreply,” “account,” “welcome,” and so on. If you had older email accounts from years ago try to track those down too and do the same for them. At the time of writing I have records for well over 150 accounts.

Securing Credentials

As you find these accounts:

1. Figure out how to log in to them; use password recovery options if needed
2. If you no longer care about them and are able, delete them
3. Generate optimal passwords and store them in your database
4. Clear out any unnecessary personal information, particularly from unused sites
5. If a security question is required, create an entry in your password database with a random answer; make a note there of the site and security question
6. If the site offers two-factor authentication, set it up

Conclusion

This is basically everything that needs to be done. At the end you’ll have an encrypted database that contains records for your entire online presence. While this means there’s a single point of failure, it’s far easier to lock that down (especially if you chose a local password database like KeePassX) rather than potentially hundreds of points of failure.

For those interested in learning how to both lock down this password database and securely sync it between all of your devices using easy to use software, see the advanced edition.

There’ve been several controversies in recent memory that have sparked in me a desire to discuss or to use as motivation to discuss important related topics. Consider:

• In Feb. 2012 emails were leaked for several in Bashar al-Assad’s office; they were secured with the strengthy password “1234” – lovely. More recently SplashData published its most recent annual list of the most common passwords found on the internet for 2013, and “123456” is at the top – really lovely.
• Toward the end of Dec. 2013 the story that Ubuntu stores wifi passwords in plain text by default made its rounds. There are things I agree with and disagree with regarding Ubuntu and Canonical, but it seems to be a rule of thumb that all controversies involving Ubuntu are exaggerated and laced with FUD whatever their actual merit, and I believe this is no exception — notably, it isn’t even Ubuntu-specific despite seemingly every story labeling it as such.

Additionally, I’ve recently fielded some Linux questions about the basics and other practicalities on Twitter @IsaacVelando. These items will probably be the basis for the first several topics I’ll write about about when I get around to it, and perhaps you can take this as a sign of what to expect from this site in the future. I intend to write many articles not too much unlike a research paper in that claims will be sourced from reputable third parties, and while I consider it my mission to avoid falsehoods at all cost, if an honest mistake is made I’ll fix it swiftly. For all posts after this I’ll be welcoming your input and discussion. Until then.