By Will Braynen
Illustration by Donna Blumenfeld
A Hack-Along (Complete Fiction)
In a downtrodden economy, you decide to become a hacker. It's a Tuesday and you quit smoking. Trading one vice for another and because you are curious, by dinnertime you manage to steal, or purchase on a Ukrainian website a friend recommended, a little taste of goods freed from a more commercial site (which definitely wasn't this one). You first spend twenty bucks on Bitcoin. Then, equipping yourself with Tor, a good VPN and your newfound digital cash, you procure from the Dark Webs borrowed passwords, five lines worth. Because you are curious.
Do-along #1. Go ahead, try it: click on "Show passwords" above.
Like that one college professor of yours who hadn't updated his David Hume syllabus in the last twenty years, these passwords promise to be no longer relevant as their departure from the domain of property rights made the news some eighteen months ago. So it's not like it's a zero-day vulnerability. In fact, you don't even know what hacked business they came from exactly. So surely this won't do much harm.
These must have been hashed using a "cryptographic hashing function". Isn't that what they make Bitcoins out of too? "Extremely computationally difficult to calculate an alphanumeric text that has a given hash"; "mathematically invertible" even; in short, a "one-way" deal. Or so you read somewhere—The New Yorker or The Atlantic Monthly, or maybe Wikipedia during their donation drive. That would mean they are undecryptable, right? If impossibility snuffs out temptation, maybe this will put an end to your curiosities.
To not feel epistemically irresponsible—like you did your due diligence before putting meddling sleuthiness to rest—you google for "decrypt password online". No quotes.
Resist it, and your soul grows sick with longing for the things it has forbidden to itself. So, you follow the clues, one of which is a link to this tool, which promises to be "the most effective hash cracking service." The tool is almost free. A captcha is all that stands between an onlooker and what's behind the cryptic strings. (Do-along #2. Go ahead, try it: go to https://crackstation.net, a tool the use of which I in no way encourage or endorse, and paste in all five hashes; then write down the decrypted original of the one you crack.)
Hmm, this person must've really liked shoes. Or maybe it's the name of the band they had daydreampt up in homeroom. Interesting. A box with hinges, key, and lid, but what use are goods within if they be stale? The passwords on the hacked site have all been changed by now. Surely. You look at the username again: "sasha@cs.adalovelace.edu". Username on a different server + the different server name...
As a social scientist at heart and in an attempt to rationalize breaking and entering, you think of this as an experiment that answers a simple question: did sasha use the same password on two different servers? Or more generally and this as a way to sample a larger distribution: what are the odds that someone does? After all, a password ain't easy to remember and can even feel oppressive—like something someone makes you do that just gets in the way, like a bouncer you did not hire standing between you and your apartment door asking you for the secret word. There are different bouncers and they all have slightly different rules for what makes for an okay secret word or passphrase and, sometimes, they make you think of a new one every six months. And even when you are frazzled, rushed or tired and they've met you lots of times before, they show no sign of recognition and are robotically unyielding. Instead of protecting your property, passwords are the things that stand between you and what's yours, between you and your space. Or so it feels. You can relate.
Why can't a website identify me automatically based on my typing patterns, biometrics, or the devices I have on me? My devices and I spend so much time together. The internet and I spend so much time together. Why can't computers recognize me the way other people do? You know what it's like. Maybe sasha used the same password across different accounts and servers. You give it a shot. You ssh to cs.adalovelace.edu and are prompted for your username. You enter `sasha`. When prompted for a password, you comply. (Do-along #3. Go ahead, try it: go to the password-terminal-emulator and, for the username, enter `sasha` and then, when prompted for a password, enter the password you cracked earlier; if you see the "$ " prompt, then you are in!)
It's as if it waited just for you. As if:
if (username == "sasha" && SHA.hash(password) == "eb9062b08c649ae77c3f5772055d7f8cad687fec")
{
terminal.echo("Congratulations! You found me. Hello, you.")
}Next, were this a real server and not a stage prop, you might try to explore to see what permissions sasha has. Maybe ls around for a bit. Then see if sasha can launch a few phishing attacks and go from there. Maybe you'll even automate the process. Time for breakfast.
THE END
As a user, three things you can do to be more secure aside from keeping your operating system and web browser up to date:
Keep up to date your web browser and operating system (on your laptop and smartphone).
Enable two-factor authentication whenever possible.
Use a password manager like lastpass (which is free) on your laptop and smartphone to generate passwords with at least the following settings:
For advanced users: do not use ssh with passwords; instead, if you use ssh (e.g. to connect to your ec2 instance on aws), use ssh key-based login (using `ssh -i` with `chmod 400 myKeyPair.pem`).
As a software/system engineer, three of the many things you can do to help your users be more secure:
Know and reduce the number of entry points into your backend.
Store everyone's passwords in plain text! Juuust kidding. Salt your hashes and do so with unique salt per password. Hashes and salts are not meant to help prevent a breach; rather, they are meant to help reduce the breach's blast radius.
Avoid using outdated cryptographic hash functions. But keep in mind that using an unsalted SHA-2, e.g. SHA512 variant, instead of an unsalted SHA-1 wouldn't have saved the day. An SHA-1 hash with unique salt per password would be a more effective deterrent than an unsalted SHA-2 password. For example, try to crack the following unsalted SHA-2 password hash using crackstation:
49b61868c51c1ee843f16e0566f2df0e0d84acf9882dcfd4b2b019abbdfda645c573a037b85685ea5a69509c78c7d873861d754b663cadd358aa800d5dc0cb7b
Not sure what to yet make of Keccak, an "SHA-3" algorithm that won the NIST competition.