Things That Matter Most

Things That Matter Most

Configuring Yubikeys, GPG, and Keybase

by Leave a Comment

Rather than use GPG and SSH keys housed on individual machines, I embed my GPG private keys on Yubikeys by default. This allows me to keep my keys somewhat portable (i.e. I can use them on multiple devices) while preventing my keys from leaking if anyone accesses my machine without my permission.

This is the same workflow I use with my team to enforce various cryptographic controls with our projects. A specific encryption key manages email encryption and access to git-crypt-protected credentials. A signing key manages email and Git commit signing. A separate authentication key manages SSH access.

It’s a strong way to protect our identities within the various tools we use, and one I recommend for just about any development team. To that end, a version of this article appeared in the March 2018 issue of php[architect], and I have an even longer version I distribute in person to developers.

Setting up your Yubikey

The goal of this walkthrough is to help you configure your GPG identity and port your keys to a secure hardware token – I recommend a Yubkey 4 (as it supports 4096-bit RSA keys). You can also use a Yubikey Neo, but this will only work with 2048-bit keys.

The basics we’re going to set up:

  • A 4096-bit master key that will be kept offline
  • A revocation certificate that will also be kept offline
  • 4096-bit sub-keys for encryption, signing, and authentication
  • Publication of keys to Keybase and other directories
  • Automatic signing of Git commits with the GPG key
  • Configuring gpg-agent to act as ssh-agent for remote access

I’d love to recommend everyone use the newer elliptic curves available in GPG as they’re powered by Libsodium and rapidly becoming a new industry standard. Unfortunately, the Yubikey hardware doesn’t yet support this family of cryptography, so we’ve got to stick with battle-tested RSA for now. Using a 4096-bit key size with RSA gives us equivalent protection to a 256-bit elliptic curve key, so it’s “good enough” for the moment.

Installing GPG

The following instructions require some format of GnuPG installed locally to behave. On Mac, this is as simple as running:



$ brew install gnupg2

On Windows, this requires installing GPG4Win.

If you’re running things on Windows, I’d highly recommend you reference Scott Hanselman’s amazing walkthrough as well. The instructions that follow are more targeted towards *NIX environments, but Scott’s article deals with some of the various edge cases that might pop up during Windows use.

Once installed, you can use either gpg2 or gpg from the command line to interact with the system (I’ll use gpg2 below as it refers explicitly to the version of GPG we just installed).

Creating the Keys

Master Key

To begin generating keys, start with:



$ gpg2 --full-generate-key

On the menus that follow:

  • Select (4) RSA (sign only)
  • Set keysize to 4096 bits
  • I typically set expiration to infinity (0) – use a reasonable value for your use case
  • Set your real name
  • Use your email address
  • Leave the comment blank
  • Use a strong passphrase – but make sure it’s easy enough to remember/type (you’ll need it later)

Make a note of the generated key fingerprint and key ID. The key ID will be used in subsequent steps.

Sub-keys

Start adding sub-keys by editing the key we just created. Make sure to substitute your real key ID when you see KEYID in the steps that follow:



$ gpg2 --expert --edit-key KEYID



$ addkey

On the menus that follow:

  • Select 4 – RSA (sign only)
  • Set keysize to 4096 bits
  • I typically set expiration to infinity (0) – use a reasonable value for your use case

Make a note of the generated fingerprint and key ID.



$ addkey

On the menus that follow:

  • Select 6 – RSA (encrypt only)
  • Set keysize to 4096 bits
  • I typically set expiration to infinity (0) – use a reasonable value for your use case

Make a note of the generated fingerprint and key ID.



$ addkey

On the menus that follow:

  • Select 8 – RSA (own capabilities)
  • Press s to toggle signing
  • Press e to toggle encryption
  • Press a to toggle authentication
  • Press q to save settings and create an auth-only key
  • Set keysize to 4096 bits
  • I typically set expiration to infinity (0) – use a reasonable value for your use case

Make a note of the generated fingerprint and key ID.



$ save

Publishing the Keys

If no one has your public key, they can’t verify your identity. Upload your public key to a keyserver with:



$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --send-key KEYID

If you’re using Keybase, you can also add your key quickly with:



$ keybase pgp select --multi

Then select the appropriate key.

Add Additional Identities

It’s often more trouble than you care to deal with to manage multiple identities and keys. Instead, it’s easier to add secondary identities to the key we created above (i.e. your personal and professional email addresses). For example, my keys are bound to all of my online identities to make it easier for people to find me.

If you need to use GPG keys for personal emails/identities as well, you can add them with the following steps:



$ gpg2 --expert --edit-key KEYID



$ adduid

On the menus that follow, provide your real name, your email address, and an optional comment. You can add as many secondary IDs as you need. Once you’re done, commit the changes with:



$ save

Generate a Revocation Certificate for the Master Key

If your keys are ever compromised, you will need to revoke them with the public keyserver. Remember, if you lose your private key there is no way to revoke a key from the server so keeping a revocation certificate is a necessary step to proactively protect your security.

Generate the key easily with:



$ gpg2 --output KEYID.asc --gen-revoke KEYID

Specify the revocation reason that “key has been compromised” and store the generated certificate in a safe, secure, and preferably offline location. You might not ever need this certificate, but if you do having it in a trustworthy place is critical.

Transfer Keys to the Yubikey

Configuring the Yubikey

The Yubikey ships with two default PINs, one for administrative use and one for daily use (i.e. unlocking your key for signing/decryption).

  • Default PIN = 123456
  • Default Admin PIN = 12345678

We need to change both of these to non-default values:



$ gpg2 --card-edit



gpg/card> admin



gpg/card> passwd

First change the PIN (remember it needs to be 6-digits long).

Now change the Admin PIN (needs to be 8-digits lon)

Press Q to save and quit the password menu. Type quit and press enter to exit the card editing screen.

Export Backups

Exporting your secret key to a backup is vital if you ever need to recreate your Yubikey for any reason. Preferably, this storage location is encrypted and offline (i.e. an encrypted USB stick) and in a safe, secure location.



$ gpg2 -a --export-secret-key KEYID >> /some/secure/location/KEYID.master.key



$ gpg2 -a --export-secret-subkeys KEYID >> /some/secure/location/KEYID.sub.key

I have two Yubikeys configured with the same keys. One is the primary I use day-to-day, the other is a backup in case of emergency. By exporting your keys, you can re-import a key to another Yubikey if necessary.

You won’t likely need the backed-up subkeys any time soon, but if you ever want to sign someone else’s keys you’ll need the master key to do so. It’s a good idea to not keep your master key available – think of it like root access to your identity. Instead, using your master key should require intentionality – like getting something out of a vault across town.

It’s incredibly powerful; you should take care to protect it.

Actually Transfer the Keys

If you have other keys stored on your Yubikey, the following steps will overwrite them. It is impossible to extract a key from a Yubikey once it is there, so the previous step of exporting backups is vital if you ever need to recover a lost key or recreate your Key.

The following steps assume you created subkeys in the order specified above (signing first, then encryption, then authentication). If you followed a different order, your selections below might vary.



$ gpg2 --edit-key KEYID



gpg> toggle



gpg> key 1



gpg> keytocard



Please select where to store the key: 1 (Signing)



gpg> key 1



gpg> key 2



gpg> keytocard



Please select where to store the key: 2 (Encryption)



gpg> key 2



gpg> key 3



gpg> keytocard



Please select where to store the key: 3 (Authentication)



gpg> save

Once your keys are exported to the Yubikey they will no longer be present on your machine. Be sure to remove your master key (assuming it’s properly backed-up) as well to make sure your machine is safe.

Configure GitHub Commit Signing

Export a Public Key

To export the public signing key for use with GitHub, merely ask GPG to export it to a file (the key will have ASCII armor so it will remain human-readable):



$ gpg2 -a --export KEYID > KEYID.asc

Configure GitHub

  • Log in to GitHub
  • Go to your settings by selecting Settings from the dropdown by your avatar
  • Select SSH and GPG keys
  • Add a new GPG key, coping in the ASCII armored text exported in the step above

Configure Git

Adding a default signing key is straight-forward. Merely run:



$ git config --global user signingkey KEYID

This sets your key, but commits will not be signed by default (you must manually specify -S when committing to sign). To sign by default, run the following:



$ git config --global commit.gpgsign true

From this point forward, every commit you make will be signed with your GPG key (and will appear as “Verified” on GitHub). This has the advantage of proving that you and only you authored the commit (i.e. no one spoofed your identity in the commit logs).

Verified commit

GPG commit signature on GitHub

If for any reason you want to create an unsigned commit, add –no-gpg-sign in the command line when authoring your commit. This is useful if you’re working remotely and temporarily lack access to your Yubikey.

Configure SSH Authentication

SSH will still use your default id_rsa.pub key for authentication at this point. We have to tell the machine how to use GPG instead and, conveniently, GPG agent has a flag to do just that:



$ gpg-agent --daemon --enable-ssh-support --write-env-file ~/.gpg-agent-info

This command generates the environment variables necessary for SSH to use GPG for authentication and writes them to ~/.gpg-agent-info for future use. It’s easier, though, to add them directly to ~/.bash_profile for consumption with the following block:



# GPG Agent



if test -f ~/.gpg-agent-info -a -n "$(pgrep gpg-agent)"; then

  source ~/.gpg-agent-info

  export GPG_AGENT_INFO

  export SSH_AUTH_SOCK

  export SSH_AGENT_PID

else

  eval $(gpg-agent --daemon --write-env-file ~/.gpg-agent-info)

fi

This code will test for the file first and regenerate it if it doesn’t exist – if it does exist, it loads everything for you. From here on out, if you execute ssh-add -L to list out your loaded SSH keys, you will see one reported as an identity with your Yubikey’s card number instead of an email address or path name. If you want to grab your public key directly, run:



$ gpg2 --export-ssh-key SUBKEYID

Where SUBKEYID is the ID of the third sub-key you generated earlier. (This will often be the last key in the list if you run gpg2 --list-secret-keys as well.)

Next Steps

This walkthrough just covers the GPG features of your Yubikey. The hardware can also be used as a PIV card to house X509 certificates. It’s also a great 2FA device, supporting both OTP generation and FIDO’s universal second factor (U2F) spec.

I use my Yubikey daily to:

  • GPG-sign every email I send from my workstation
  • GPG-sign every Git commit
  • Authenticate to remote SSH servers
  • Encrypt/decrypt sensitive credentials on my machine
  • Respond to U2F challenges from services like GitHub and Gmail

How will you use your Yubikey?

Disclosure: SQL Injection in Cart66 Pro

by Leave a Comment

This vulnerability was reported earlier directly to both the Cart66 team and to Semper Fi Web Design (the maintainers of the GitHub clone). This post follows a 30-day responsible disclosure window.

Last month, a friend pointed me to the no-longer-in-development Cart66 Pro module for WordPress. The plugin ceased development about two years ago when the team moved to a hosted SaaS model, but it’s still available by way of a GitHub mirror for anyone still actively using the tool. Just one problem: it has some significant security holes.

Password Use

The first critical flaw in the plugin is the way protects it fails to protect user credentials. WordPress isn’t widely known for its strong stance on user password hashing, but at least leverages multiple hashing rounds and a random salt to prevent the creation of rainbow tables for brute forcing a login.

Cart66, however, uses a single round of MD5 hashing on the password. Without a cryptographic salt.

This fails to offer much protection at all on a user password. Further, MD5 is considered a broken hash and it’s relatively easy to use an aforementioned rainbow table to reverse from a hash to a user-specified string.

Considering how frequently end users reuse passwords, getting a copy of the unsalted single-round MD5 hashes from a Cart66 database would give any attacker a solid starting point for trying to steal a customers’ account elsewhere. Perhaps they reused the same password for PayPal? For another ecommerce site? For their email address?

The weak state of password hashing on Cart66 Pro-powered sites results in databases ripe for abuse if they can be stolen by a malicious party.

SQL Injection

Like all good ecommerce and marketing tools, Cart66 Pro presents an efficient way both to email customers and for customers to opt-out of receiving emails. Unfortunately, the opt-out mechanism is vulnerable to a somewhat trivial SQL injection vulnerability!

The opt-out system is powered by a WordPress shortcode. A WordPress administrator adds this shortcode to a standard post or page in WordPress, then visitors hit that page when they click an opt-out link in the footer of an email. PHP code running on the page will then extract certain query parameters from the URL to identify and flag the user as opted out of messaging.

One of these parameters is the customer’s email address (as that’s their primary identifier in the database). By default, the email address is passed as a Base64-encoded, URL-encoded parameter in the request.

For example, eric@thisisareallybadidea.com would be encoded as ZXJpYyU0MHRoaXNpc2FyZWFsbHliYWRpZGVhLmNvbQ==.

However, there is zero sanitization on this input. While a typical user would click a link in their email client, an attacker could craft their own URL with whatever parameters they want specified. Imagine instead that an attacker passed JTI3JTNCVFJVTkNBVEUrd3BfY2FydDY2X2FjY291bnRzJTNCLS0= as the email parameter in the request.

This decodes to ';TRUNCATE wp_cart66_accounts;--, which is obviously not an email address. To understand why it’s an issue, you have to understand that, after decoding the email parameter, Cart66 Pro passes the value directly into a SQL statement:



$itemsTable = Cart66Common::getTableName('accounts');

$sql = "SELECT id from $itemsTable where email = '$email'";

$id = $this->_db->get_var($sql);

Running through the interpolation, this will have the effect of running the following query directly against the WordPress database:

SELECT id from wp_cart66_accounts where email = '';TRUNCATE wp_cart66_accounts;--'

The first SELECT statement will obviously fail to match any accounts, but the second TRUNCATE statement will drop all account data from the database!

A well-armed attacker could also craft a request to insert arbitrary information into the database, manipulate the data already present, or even extract whatever contents they want from the WordPress database (including a list of all account logins and weakly-hashed passwords)!

If you are using Cart66 Pro and have not already patched this issue, please do so immediately as your database (and your customers’ information) is at risk!

Moving Forward

SQL injection attacks are one of the most prevalent in the open source software community. It’s incredibly easy to write insecure code and trust that the only inputs to our functions are legitimate. But every developer needs to occasionally put on their “how would someone break my code” hat and protect against the worst case scenario.

WordPress in particular has extensive documentation about how to properly prepare SQL statements to prevent this kind of injection attack. If you’re using WordPress and writing code that queries the database directly, use this approach to avoid a malicious party abusing your code to attack the platform.

If you’re writing PHP but not using WordPress, leverage tools like PDO that support prepared, parameterized statements to protect your code from abuse.

There is literally no excuse to not prepare your SQL statements in modern code. Anything less is reckless and opens not only your customers but also your business to attack and abuse. It’s worth it to take the time and do things right the first time. Security engineers will often find these issues in the wild and give you a head’s up; but usually a malicious party has already found and exploited the hole by then.

-~-

For more advice on writing secure PHP code, I’d encourage you to pick up a copy of my new book, Security Principles for PHP Applications. I’ll walk you through all of the updated OWASP Top Ten, and specifically through properly avoiding both SQL and other forms of injection attacks. It’s a great place to start to keep your project secure.

Introducing Secure Updates for WordPress

by 6 Comments

Skip to the announcement …


One of the earliest conversations I had in the WordPress community almost saw me immediately leave and never return. I’d released some code in a few plugins and was just finally starting to get ramped up as a (very sub-par) developer. I hung around on IRC, subscribed to the various mailing lists, and tried my hardest to learn, improve, and contribute.


Then someone pointed out that I’d never internationalized my plugins. Then they proceeded to go on a rant about how any developer who didn’t internationalize their UI was doing a disservice to the community and was betraying their personal bias against and hatred towards non-English speakers.


I was horrified.


I came to the development world from marketing. I used Windows. I was very comfortable with graphical (often skeuomorphic) interfaces and could work my way around things easily with a mouse. I didn’t understand the command line. I barely understood code. It took me months (and several misfires) just to learn enough Subversion to get my plugins out in the first place.


All of the tools for internationalizing a plugin were, at the time, heavy into a command line that I didn’t understand and couldn’t use.


I took a break and, ironically, this experience is what started me blogging. My break let me get some distance and gave me the chance to connect with other developers who did understand the command line tools. They taught me things I didn’t know and I came back a much stronger dev.


One of my most popular blog posts today is an old introduction I wrote for developers who wanted to use GUI tools to publish a WordPress plugin. Honestly, though, I wrote the walk through more to remind myself how to do things than anyone else … and that’s how I got started with most of my blogging work.


A topic I’ve focused on more recently has been cryptography. More specifically, using cryptographic tools to ensure the integrity of various packages and messages. It’s a heady topic, and a lot of the tools available for end users are painfully focused on power users who fully understand command line utilities.


I want to change this.


Code Signing


There’s been a lot of talk about the security of the WordPress updater. Primarily, the updater checks the MD5 hash of a package’s contents before proceeding to ensure its integrity, but that’s the only test it runs.


Consider what might happen if a malicious party were able to somehow breach the WordPress.org update server and present their own download package. This could potentially inject malicious code onto more than a quarter of the Internet all at once! Considering such a breach has happened with a few plugins in the past, it’s not outside the realm of possibility.


Now imagine if a hacker were able to drop themselves somehow between your server and the WordPress.org update system. Such an attacker could impersonate the updater and serve you whatever package they want. Your system wouldn’t know the difference.


In the middle of last year, I said I was working on a solution to bring formal code signing to WordPress. I held off for a while because it looked like the WordPress community might bring this feature to core.


That didn’t happen.


So today, I’m proud to announce the release of DGXPCO: Digital Guarantees for eXplicitly Permitted Core Operations. This plugin integrates directly with the WordPress core updater and requires that any core package have a valid signature in order for installation.


For the moment, I am personally signing the contents of every core package distribution and maintaining the collection of signatures in a separate repository that I serve through a secure CDN powered by Amazon Web Services.


Every WordPress release includes both the core download fornew installations as well as “partial” upgrade packages for anyone coming from an older install. I’m signing all of these and keeping a record in one spot so that everything from new installs to partial minor updates to major updates can benefit from the added security of checking a signature.


The signatures are leverage an Ed25519 public/private keypair and Libsodium to sign the files’ contents. I keep the private key offline, but have published the public key so everyone can keep an eye on things. This key will not change, and if anything is signed by a different key, you can be sure something is amiss.


That public key, encoded in Hex, is 5d4c696e571307b4a47626ae0bf9a7a229403c46657b4a9e832fee47e253bc5b.


Every commit to the release hashes repository is also signed with my personal PGP key so you can verify that I’m the one who added the new code.

Next Steps


Is this fool-proof? Probably not. It is, however, a huge step forward in terms of WordPress security. There’s quite a bit more we can do, and I want to outline some of my grand plan here.


The first release of the plugin checks signatures upon update only, but WordPress will still tell you about an update even if the signature check fails. The next release will not even surface an update unless a signature is available.


At the moment, this plugin only secures WordPress core updates. A future release will also secure plugin updates as well, in an opt-in fashion. I’ll start by securing my own plugins as a proof of concept, then allow for other developers to opt-in to the stronger security moving forward.


Today, I am the only one allowed to sign release packages. This is OK for the short term, but is not a sustainable model. As I prove out the update system, I’ll also begin adding sets of public keys that are scoped to specific sets of packages. This will, for example, allow me to whitelist a small number of trusted developers to also sign core packages. It might also empower plugin developers to sign their own releases (but not anyone else’s).


At the end of the day, I’m looking now for feedback. We don’t have this functionality in WordPress core yet, but DGXPCO is evidence that we can add it. We should add it. So let’s work on the feature together.


As I mentioned in my initial post last year, if you want to help with this endeavor, please let me know! If you want to contribute financially,donations are always gladly accepted.


This is the first project I’m launching under the name of my new WordPress-related business, Displace Technologies, LLC.

Open Letter to the Democratic Party of Washington County

by

Dear Washington County Dems,

I write to inform you of my resignation as a Precinct Committee Person (PCP) for Precinct 428, effective immediately.

Being elected to represent my precinct in 2016 was exciting. I was given opportunity to better connect with my neighbors and coordinate on policy recommendations with other Democrats in the county. Everyone was respectful, polite, and organized. I was incredibly dismayed when this proved to be a facade that quickly faded over the next several months.

Committee meetings quickly devolved to infighting. My formerly respectful peers were reduced to literally screaming at one another. The party of which I’ve been a member for over 16 years did not turn out to be the example of civility it’s claimed to be.

Our meetings purport to follow Robert’s Rules of Order but frequently depart from the rules and drag on as no one knows what to expect. Meetings are frequently filled with moral grandstanding and debates that turn into classist and ageist arguments rather than respectful discussions.

I will not continue sacrificing my time in service of a party that cannot respect one another.

On a national level, the party has also proven to be in decline. Democratic politicians speak with a level of arrogance and always presume the moral high ground. Even after being proven in the minority, they refuse to cooperate across party lines. An election that switches the alignment of the majority is a sign of constituent disappointment, not a call to resist.

While I will still vote for and donate to Democrats, it will be on the merits of their character; not their party affiliation. I cannot remain with a clear conscience as a member of this party.

This letter will be copied to the Washington County Clerk in accordance with ORS 248.024.

Sincerely,
Eric Mann

The Value of Repetition

by Leave a Comment

I took martial arts classes in college. They were a blast! Well, until the instructor decided I was his favorite demonstration tool and kept throwing me around the room to teach the class how to arrest falls.

Other than that, it was an exciting few terms of energetic classes and faux sparring with friends. One of the most memorable parts of the courses, though, were the forms we had to memorize.

These were patterns of moves that are used to judge skill and the level of expertise of the participant. Had I continued my studies past two terms of courses, I'm sure I would have learned many different forms as I progressed through the ranks.

Each form is a set pattern and is, at least among the lower levels, easy to memorize and repeat. For quite a while, practicing my forms became a daily routine. I'd repeat the same moves over and over again, turning them from a conscious effort at reproducing the pattern into subconscious muscle memory.

Repetition is the key to memorizing forms. It's the key to memorizing most anything, really.

Code Katas

Several developers have started cultivating a practice of completing daily or weekly code katas. These are specific challenges meant to test some of the more rudimentary skills developers need to hone to be good at their jobs.

This isn't to say that specific code katas are simple. Many are difficult and very challenging, but every one of them exercises the parts of our brains that solve coding problems on a daily basis. Practicing code katas regularly has the same effect on a developer as practicing forms does on a martial artist.

Converting something you need to think about into muscle memory.

Practice Makes Perfect

Whenever I see a coding interview, it usually involves a developer struggling to remember the correct boilerplate to bootstrap a project. Or searching for the correct argument order for a method in the language's standard library. Or re-deriving a common algorithm. Or … the list goes on.

But practicing these skills helps to perfect them. It gives you the ability to, from memory, bootstrap a method or an algorithm or design an interface. You've done this before, it's easier to do it again. It's easier still because you don't have to think, you can just do.

Practicing also helps you to learn and improve. Developers don't often have time available to refactor production code. But there's nothing that says you can't spend a few minutes each day practicing and rewriting a small component just for the sake of learning. You might even stumble upon an extra optimization that will make a difference in production.

Or you might just learn a new pattern that will save time and energy the next time you build a similar system.

The Value of Fiction

by Leave a Comment

I read a lot. By "a lot" I mean I read over 50 books in 2017. Some was fiction, some was non fiction, but all of it was enjoyable.

Every time I plow through a new book series, people stop to ask me why I bother with it at all. I read a fair amount of technical books, but I love to spend my time reading through various fiction stories as well. It's a bit of an escape for me, but definitely serves a greater purpose as well.

Fiction as an Analog

Almost everyone loves Star Wars. It's a great story that covers everything from action to philosophy to the hero's journey, with even a bit of romance thrown in. The original trilogy was groundbreaking filmmaking and has shaped the way many of us view movies ever since.

But one of the more brilliant elements of Star Wars was how it could be somewhat critical of world events without explicitly referencing world events.

The original trilogy features the evil Empire and their armies of stormtroopers bent on dominating the galaxy under a ruthless dictatorship. Without giving too much away for those who live under rocks and haven't seen it, when the Empire falls, we're left with a galaxy at peace for long into the future.

Until The Force Awakens, when we discover a new group has risen from the ashes of the Empire and is resurrecting the old ways to once again dominate the galaxy.

Consider that the Empire was less-than-loosely based on the history of Nazi Germany. Now consider what it would look like to have a new generation of people trying to follow in the footsteps of a defunct, evil dictatorship. Taking on their imagery, their names, their slogans, and trying to convince the world that said dictatorship was right in their worldview. That is the story of the new trilogy's "First Order."

And it's remarkably similar to contemporary veins of neo-fascists we're confronting in the real world today. Except, if you talk about current events, you'll likely end up in an argument. If you talk about Star Wars, well, you might still end up arguing, but about porgs rather than which side is the bad guys.

Creative Expansion

The value in having these somewhat abstracted conversations is that they stretch the bounds with which you can envision others' viewpoints. It's one thing to ask you to think from the perspective of someone who disagrees with you about something specific – say politics. It's another thing to try to describe the various leanings and motives of a political system you're not even a part of.

A (non-fiction) book I read a while back talked about this concept from the perspective of people studying religion. There are, ultimately, two groups: balconeers sitting in a balcony above a busy street and travelers walking on the street below.

The balconeers can overhear everything the travelers talk about. They can observe their behavior and opine on what's going on. They're onlookers; completely separated from the action but with a high-level view of everything and, possibly, an objective opinion on various matters the travelers are experiencing.

The travelers, on the other hand, are right in the fray. They have to decide where to go and when, and that decision matters to them. It determines where they sleep, if they get lost, when they get to eat, etc. They're intimately involved with a specific journey and can only see it from a subjective viewpoint.

We're all travelers in life. What we do, what we say, where we go – these all have ramifications for the outcomes of our lives. Fiction gives us the chance to be balconners observing someone else's travel and taking a higher, more objective view of things.

But the true value in fiction is when we draw parallels between the travelers in a story and ourselves as travelers in life. We can begin to apply the detached, objective view we gained as an onlooker to a more involved, subjective situation in our day-to-day.

Creative fiction gives us the ability to expand the conversation and view situations from viewpoints that would otherwise have been hidden from us. It's a very valuable tool, and one I treasure.