Cybersecurity Missteps Passwords Security Trial by Fire: A Series

Misstep 9: Trial by Fire, the Perfect Storm that Created Me

Welcome to the second misstep of 2020… A series of hindsight. Back in late 2006, I started a small forum site where I learned that building desktop applications != hosting web applications that other people use. The former may be breakable, but it won’t hurt myself or other people. The latter can devastate a business and other users.

It wasn’t that I didn’t care, it was that I didn’t know better. A lot of developers are in the same boat. They want to build systems well, but they simply do not have access to the training or tools to determine if it was built securely.

Today, I want to take you on an adventure back to 2006/2007. I was working overnight 12-hour shifts in a factory, convinced I wouldn’t find a career in information technology. I’d get off at 6:30am, drive home and usually hop online to my new creation. I didn’t have a smart phone, so I couldn’t check my sites and see if there was spam or other issues, so it would go all night long unwatched. Here’s what that site looked like:

My first forum site, with blogs and articles

First things first, it was a WATP site… Windows, Abyss, Text File, and PHP site. If I recall correctly, it was PHP 5.1.6. I was a bit apprehensive learning MySQL at the time, or Linux, and wanted to focus on PHP only. This is why PHP is called “insecure”, it is simple to get something up and running that is terrible. So, people like me write legit crap and publish it.

The forum posts were all stored in text files, as were sessions, user logins (plain text the first few weeks, then unsalted MD5!), etc. This works reasonably well since I would extort a handful of friends to use my site and, even then, nobody wanted to use it. There were no chances for a race condition to happen.

Race Conditions Happen

A race condition happens when two or more actions are applied to the same datastore at the same time. My file structure was simply a random number. PHP’s random number generator is awful, and this practice is awful. Let’s take a peek:

$titl = strip_tags($_POST["titl"]);
$dat = strip_tags($_POST["dat"]);
$msg = strip_tags($_POST["msg"]);
$poster = strip_tags($_POST["poster"]);
$rnd = rand(0,999999);

//Convert linefeeds to bbcode key and remove. Apo's are done in edittopic.php
$msg = nl2br($msg);
$msg = str_ireplace("<br />", "[br]",$msg);
$msg = str_replace("\r", "", $msg);
$msg = str_replace("\n", "", $msg);

$file = fopen("forum/" . $rnd . ".txt", 'x');
fwrite($file, $titl . "\r\n");
fwrite($file, $dat . "\r\n");
fwrite($file, $msg . "\r\n");
fwrite($file, $poster . "\r\n");

So, I’m taking a random number as a file name, and adding each “field” as a newline within the file.

PHP’s random number generator is seeded by the current timestamp, so within a few milliseconds of each other, two posts can create the same topic, throw off the posts, or cause some people’s posts to be overwritten. It was a hot mess.

Race Condition + c:\site\sessions.txt

I had committed several “sins” of secure development at the time:

  • I did not use atomic identifiers on files, meaning two writes would cause an error in some conditions.
  • I did not turn off error reporting, I was editing the site live on the server, so I thought I needed to display errors.
  • I stored the “sessions” file within the webroot.

So, I had a few folks who would use my site who also had some legit curiosity into a site’s inner workings. It so happened when this user, we’ll call him “Cody”, logged into the site and spotted a write error on the site. Something along the lines of:

Parse Error: Could not open c:\site\sessions.txt for writing.

Quite possibly, accessing this file via would be the next thing that was attempted. And, this Cody did. Inside this file, he seen my username, next to a session ID. He then copied that into the browser, and he was in my account.

I get home from work, to find I was online all night…

Several posts were made from my account, mostly about how I’ve been owned and such. I totally deserved it. As a matter of fact, here’s the forum topic that told me about the exploit. Sadly, I don’t have the site running, so I can only show you a (Somewhat anonymized) forum “file” instead:

Attention Bob
Fri, 16 Feb 2007 16:24:34 CST
This is why SQL > TXT.[br][br]Love,[br]Cody
Fri, 16 Feb 2007 21:17:06 CST
I been hacks.
Tue, 27 Feb 2007 20:25:48 CST
Should be fixed now.

This post was from my account, since my session ID was exposed. I was able to fix it, but even my fix was implemented somewhat poorly.

Security by Obscurity, and other hilarious antics

$cok = $_COOKIE["COOKIE"];
$filses = @fopen("" , "r");
while ($names = @fscanf($filses, "%s\t%s\n")) 
	list ($userkey, $username) = $names;
	if ($userkey==$cok)

So, the sessions.txt file was changed to “online.bmp”. Still in the webroot, but a little less likely to be spotted. Also, I added the error control operator “@” before the file functions (fopen, fscanf, and fclose) to hide the errors. Now, we’re getting errors that nobody knows about, but hey, it’s not giving away my clever fix.

Later, I added in an additional check. You would have to have both the session ID, and be on the same IP address as you were at login to stay logged in. Hey, this sounds fantastic! And it would be, except for these two failures (which I don’t have the code for anymore):

  • I typo’d… I used a single equals sign (=) or assignment, instead of a double (or triple) equals sign (== or ===), comparison and strict comparison, respectively. So, what ended up happening is that sessions were now disregarded, and the IP address is what was important. So, living at home with the rents at the time, my younger brother kept accidentally posting from my account and didn’t know why. This took an embarrassingly long time to correct.
  • Some users were using AOL’s custom-wrapped Internet Explorer, which proxies requests via different cache servers. This means that the IP wasn’t steady, and some users were randomly being logged off as a result.

I remember sharing my IP-following idea with Michael Coates at THOTCon 0x1 back in 2010, who liked the idea, but was immediately familiar with the issue you’d face with transient IP addresses.

Over time, I’ve improved how I’ve handled sessions, using PHP’s in-built session mechanism, ensuring proper entropy, proper cookie flags, and so on. This resolved my authentication woes, but there were still plenty more problems I was tempered by.

Join me again next Tuesday to see what other awful mistakes I’ve made.

Cybersecurity Passwords Phishing Security Software Engineering

Stop Using Security Questions

Please stop using security questions.

Why security questions were designed with good intentions

If you forget your password, a site can ask you a series of security questions. This allows you to recover your account while still potentially authenticating you with questions only you know.

Account recovery options are always a great idea, but doing so with security questions is bad.

Insecurity Questions

Seriously — they introduce insecurity. In my experience, I’ve come across a form like this:

What is your favorite color?

Your security question must contain at least five characters!

What do you think the most popular colors are? Red? Blue? What about: teal, gray/grey, etc. A form I’ve came across actually had a 5-character minimum, which removed options from this answer and made guessing black/green/white/yellow a bit easier. My wife will tell you that everybody from the 90’s would say “Crayola Cerulean” is their favorite — I’m inclined to agree.

Facebook even has a feature where people can “know you better” where you can answer questions about yourself and paste it on your profile. Yikes!

Mother’s maiden names are easy to get from your social network (click you, click your mom, look at her friends names, or look at whom you call “aunt”, “uncle” etc).

Distributing Security Questions

I’ve once seen an admin that would screenshot a page that shown user’s security questions. This page existed to help admins verify users are who they say they are over the phone. In lieu of using it for this function, people were screen shotting this info and sending it to users who “forgot” them. Yikes.

I’m a site user — what should I do?

If a site insists you complete security questions, generate random text and throw that in the box. If you need to recover the account later, paste in that random text. While there, look for the company’s security@ e-mail, Twitter, etc. Tell them to fix it.

I’m a webmaster on the world wide web

Heh, old terms. Disable the requirement for security questions, remove account recovery until you can fix it. Replace it with CAPTCHAs and allow them to reset it via an e-mailed link. Make the link valid for <30 minutes, and with a bunch of entropy in the query string. Don’t store the expiration in the query string. If their e-mail is compromised, they indeed can steal this account. For this reason, it is imperative for users to have secure e-mail accounts. Also, wipe the security questions out of the database. If you’re compromised, those answers can quickly become public.

What if I follow the email reset and security questions?

You could. It’s better than no email reset.


Cybersecurity Passwords Uncategorized

Telltale Signs of Impending Password Breach

For most, password restrictions are an annoyance that prevents them from using easy to remember passwords, like “password” or “123456”. You can generally tell how a company handles your private information, and I’ll teach you a few tricks on determining which sites potentially store your password insecurely.

Smart Password Complexity Requirements

(none of these should be taken to indicate an insecure storage methodology)

  • Minimum character limits (for example, your password must contain at least 8 characters)
  • You must use numbers/uppercase/lowercase/symbols
  • You cannot use a dictionary word
  • You cannot use your name/username/email/other identifier in your password

Stupid Password Complexity Requirements

(it is probable that sites with these requirements are storing your password wrong)

  • Disallowing -any- symbol, be it dollar sign, comma, quotes/double quotes, hashes, less than/greater than, ampersand, and so on
  • Mentioning any upper limit to the length of your password (maximum 10 characters) *
  • Odd requirements, for example, requiring your password start or end with certain characters (letters, numbers) or prohibiting the ends of passwords from having specific characters.

*- There are functional limitations here, like the maximum POST size practical in a browser, yes, but if you can’t use a 100 character password, this is a problem.

What is a Password Hash?

There’s a separate blog post for that wee lil’ question:

What is a Password Hash?

In short, companies that care, use hashing for your passwords.

So you’re calling a company dumb, why?

Properly hashed data will return a relatively short hash from any sized input data — this is important to know, as it highlights exactly why having a maximum password length is a bad thing — it is a clear sign they’re storing your password in a really stupid way, or their devs are stupid. Either way, means bad security for you.

Now I love Southwest Airlines — a lot, I love flying with them I love their attendants, and none of their pilots have killed me. What else can you expect?

Well, I’d expect a certain level of hashing on my passwords:

Their reply wasn’t what I wanted. Basically reiterating the limitations of the form. It should be noted that this does not mean they’re vulnerable or are storing your passwords wrong, but it does make a pretty solid case that it’s possible.

Another company I used a very long time ago was TCF Bank. Now I know what you’re thinking — lmao, TCF. Yeah, their bill pay was garbage, their online banking from the 90’s, etc. I can’t speak for the interface now, but one thing that stuck out to me was the password length limit.

I’m done calling companies out now…

…Mostly because I don’t have more examples from the top of my head. When you see stupid password policies in place, it is generally in place because of a poorly configured WAF, or poorly built site. They are worried you’ll pass variables or SQL injections into their software so they filter the characters you use. Properly hashed passwords are completely inert — they are made up of hexadecimal letters without spaces, they will not execute as code.

Oh — One more thing, password resets:

If you reset your password and you get an e-mail back with your password, then they are clearly storing it WRONG. Change all of your passwords (except this site) and stop using it immediately. Close your account if possible. This site, once breached, will present no difficulty to anybody wanting your password.

Finally: Security questions suck really bad. Tell me what your favorite flavor of ice cream is in the comments!

Cybersecurity Passwords Security

What is a Password Hash?

What is encryption?

Encryption is a reversible message obfuscation technique which applies keys or mathematical models against a string of text. The key here is that, with the proper password or key, you can retrieve the original contents of the message.

Remember making up codes like “A=Z, B=Y, C=X” in school (this is a ROT13 Caesar Cipher by the way)?

That is encryption. Horrible encryption, since it is really easy to break, but it still counts.

What is Hashing?

Hashing is an irreversible message digest technique which applies mathematical models against a string of text. The same string of text will always generate the same output hash.

Let’s use MD5 because it’s old and people will comment on my blog if I mention it:

If I MD5 the word “hello”, I get the string “5D41402ABC4B2A76B9719D911017C592”

Go ahead, try it for yourself!

Every time you run a word through a hashing algorithm, it comes up with the same value. In theory, you can never “decrypt” a hash since the original information is no longer stored in it, just a representation of that data. This is the formats best selling point, and also it’s greatest weakness.

Password hashes, if unsalted/unpeppered, are vulnerable to these issues right out the gate:

  • Collisions, since we are using a limited amount of characters (in the case of MD5, 32 hex or 128-bits), it would be fundamentally impossible to ensure there is no collisions when hashed strings are both longer and shorter than 32 hexadecimal bytes.
  • Precomputed hashing tables “Rainbow Tables” — With enough time or storage, it is trivial to generate an MD5 hash of every common password (these lists are very easy to get). It is easy to reverse MD5/SHA1/any improperly handled hash. One of the biggest threats to password hashing is evolution — it used to take a “long time” to generate an MD5 hash, now GPUs can spit them out at astonishing rates. When your password is leaked by a company improperly storing your passwords, this is usually the first step — reverse all of the hashes.


What is a salted or peppered hash?

Due to the risks of precomputed hash tables, programmers have to work around the users. People will still pick terrible passwords that rainbow tables will contain. For this reason, a properly salted password is one that contains a randomly generated string for each password on the site. This is important, as using the same salt is as good as using no salt. People will get an export of your database, and generate a new table specific for your application. Having a salt for each password drastically increases the time to successfully attack your userbase (this is where password expiration come into play).

A peppered hash is a bit more uncommon, but still has it’s place. This value is an additional salt that exists only in the software. These are generally common across all passwords or are generated from other repeatable values. The purpose is layers — if the database leaks, and the pepper didn’t, it will be harder to get a password.

What is a Password Hash?

Finally — the question the post was made to answer. A password hash is simply a representation of your password that is repeatable and difficult to recover for the owners of the system and for attackers.

When you create an account, your password is hashed, therefore the site has your password but stores it in a secure manner.

When you log into the site later on, your password is again hashed and that hashed value is compared to the one from the time you created your account. If there is a match, you’re logged in. If not, it is “Forgot my Password” time.