Sysadmining Like an Amateur

A little over a year ago, I bought a domain at since the .tech TLD is pretty cool and the domains there are fairly cheap. I never really knew what to use with it, but I always wanted a server that I could put some of my files and maybe run a little web server. Over the past couple of years, I have been using my school’s SSO connected with a NFS for the CS department at my school to store my data. That was a simple solution because I could access the data from anywhere, and I knew my data was relatively secure.

Still, the goal of any security-conscious computer science professional is to own their own data. There are some services you can trust, and some you have to use due to work related use of services. For me, it especially doesn’t help that I’m graduating this year, so in a matter of months all the data that I have stored on the school’s server will no longer be accessible. Now I have a specific criteria I need to fulfill if I want to own it:

  • Easily accessible
  • Verifiable
  • Secure
  • host and serve files as I deem necessary
  • Bonus: sandbox server, install and configure what I want

There are a few services available online that provide the above. The two big names are Amazon Elastic Compute Cloud (EC2) via Amazon Web Services and DigitalOcean. While DigitalOcean provides a more simple interface and potentially better support, EC2 has a free tier (for the first 12 months, anyways), and provides a way to upgrade an instance if necessary. For a single core and 1GB of RAM (and up to 30GB of storage on SSD), it seems small but should be entirely manageable for a minor web server. It’s also worth mentioning that you can run multiple “free” instances under the same account. If you want modularity, you aren’t hampered by your frugality. If it is not obvious at this point, I decided to go with EC2.

In terms of easily accessible, it depends on how I hook it up to my domain and what security groups I assign to my instances. The biggest pain of working with DNS is waiting until whatever TTL that was defined for a field expires and the new one that I created takes over. It is only a matter of time, but it can be a pain to figure out whether the problem is on my end or if it is because of the TTL. As for security groups, I have managed a firewall before, and it is not a difficult concept. I created a key-pair for SSH and only opened up inbound ports for the services I want accessible.

As for whether an instance is verifiable and secure, that comes down to how I manage the system and if I can install what I want. For web services, the biggest piece is Let’s Encrypt. If you have not heard of it, it is an open certificate authority that supplies free digital certificates for purposes of enabling HTTPS. It was fairly smooth configuring Apache and enabling the certs. Now the instance is verifiable and the back end is still strong.

In order to host and serve files, I decided to split this into two categories, files I want to face the web and files I want behind a wall. Apache was already serving some simple content I created, so there was little to change on that side (aside from installing PHP7 😀 ). For more private files, I created a separate instance and used SSH for the SFTP server, ensuring accessibility by sandboxing a local account with password access.

Finally, I was able to install and configure what I wanted on my instances, much more so than I probably should have. Running RHEL7.3, I desired to upgrade OpenSSL and Apache to include some of the more modern SSL features. That meant downloading, configuring, and compiling newer versions of OpenSSL and Apache. The most difficult part was trying to compile the mod_ssl module for Apache to use – I ended up having to include compiler flags for OpenSSL for Apache to build on. It was a long and frustrating process, but I’m convinced that it has made it at least that slight bit more secure. The main issue now is that if I want to update Apache or OpenSSL, I have to do it manually.

All this goes to show that AWS is pretty alright. I definitely appreciate having little sandboxes with which I can mess around, but even cooler is the fact that it can act as a small but powerful front end. Just wait until next year, when I have to decide between continuing to use EC2 or moving to DigitalOcean. (I shudder at the thought of dealing with those certs issues.) For the first year, anyways, cheap sysadmining is available to all who dare. I would say that it is very much worth it.

P.S. If it was not clear, this post was not meant to be a tutorial, but as a sort of personal update and “hey this thing is possible and exists.” If you would like any help and you are trying it out yourself feel free to contact me.


[Many StackOverflow pages saying helpful stuff like “no, OpenSSL compiler flags can actually be passed through ./config and they’ll just be appended”]

The Problem with Password Requirements

“People are stupid. We need to make sure they use stronger passwords.”

“Yeah, you’re right. The amount of people that use simple passwords like ‘password’ is way too high.”

*requires a number, a special character, an uppercase and lowercase letter, and at least 8 characters*

In terms of security, that sounds good, right? I mean, it gets people away from using passwords like “12345678” or “password” and using safer and more complex passwords, so that must mean that they’re harder to crack… Right?

Interim factoid here: in order to count the number of possible configurations for a “string,” or a collection of letters and numbers, you calculate (# of possible characters)^(length of the string). For a length of four with all lowercase letters, we have 26^4, or 456,976 possible combinations of letters.

Actually, no, it isn’t. In fact, in some cases, it makes it easier for computers. Think about it – if you’re brute forcing against an encryption key, you want to be able to narrow down and use as few characters as possible. If you assume that everyone uses typical lowercase letters only for their passwords, and at minimum length, then you only have to compute 26^8 to find every single password. That’s almost 209 BILLION combinations of letters! That’s crazy! Nobody would be able to type that fast!

First of all, computers are a lot faster than that. If they even take an entire 1KHz to compute a hash on a password, on a modern computer (4GHz dual core), they can compute 8,000,000 hashes per second (8 Mhps), which means that it would finish cranking out all the possible combinations of letters in 7 hours and 15 minutes. The thing is, if you have a machine dedicated to hashing, they can go even faster than that, and if you’re just producing hashes until you find the one that matches the hash for the password you want, it would take even less time than that: on average, 3 hours and 7.5 minutes. That’s not much time at all, so we should create more possibilities, to make it harder for computers, right?

Yes and no. If you figure into the equation all of the special characters that would be included, according to this document, you have 23 special characters, plus 10 digits, plus 26 lowercase letters, plus 26 uppercase letters. That means, with a eight-character minimum, you’d have 85^8 possibilities, or 2.7 QUADRILLION possibilities (in comparison, 2724905 billion compared to 209 billion, or by a factor of 13,038). That means that the full hash time would take over 94,524 hours, or 10.8 years. The average would be half that, 5.4 years. Anybody would be crazy to try making computations for that long – by the time that 5.4 years passed by, the person may have changed their password, or they might not even have an account there anymore, since technology is like a fast-flowing river – they may have changed services to a different or better company, or the company may have changed their security protocols.

However, again, computers are faster than that, and humans are lazy. I mean, many people just put “password” as their password. Would the new protocols – special characters, et cetera, actually change anything? While I am not aware of any password hacks of facilities that use this specific protocol, I would bet that 90% of people that would make their password “password”, would make their new password “P4ssword!” or “P4ssword.”. If you try to account for small variations on common passwords (in a database of passwords, which is often used by crackers), then suddenly that 2.7 quadrillion computations shrinks to a much smaller number (small note: technically, “P4ssword.” is 9 characters, so the actual number of computations would be 231 quadrillion hashes – a minor difference), and instead of trying to brute force all possible combinations of characters and numbers, you just try to think like a human, suddenly passwords are much easier to crack. Then the issue for password crackers becomes, not how long it is going to take, but how good their algorithm and database are to try to figure out any given password.

See, the problem isn’t with computers – it’s with humans. For the first example, special characters and numbers are still able to be used – if crackers are still applying their algorithms to common passwords, then yes, the issue still exists. However, if the majority of people practiced using longer passwords instead of the minimum, guess how long brute force hacking takes? Even if we assume only letters, and no numbers or special characters,

(52^8 = 54 trillion, 52^9 = 2.7 quadrillion, 52^12 = 3.9 x 10^20, 52^16 = 2.9 x 10^27)

If you account for special characters and numbers, that must be to the power of infinity, right? Actually… not really. Even with 16 characters, 85^16 = 7.42 x 10^30, which is only a factor of a few thousand, compared to the difference between the first and second examples we did, which was a factor of over thirteen thousand. While that can still mean a lot of time, it doesn’t really make much difference if we’re talking about brute forcing a “LongStringLikeThi” (16 characters).

Not only does it not make much difference, but it is also harder for people to remember a random phrase like “L3#7pAs%” which is quite short AND hard to remember. Mathematically speaking, there are more password combinations if you have more general requirements than specific, complex requirements, as in our second example, because there aren’t limitations on what you can create as a password. In fact, the more creative we are with our passwords, rather than more complex, the harder it is for computers to guess, as crackers need to create better algorithms and larger dictionaries (or databases) to compensate for all the computations they would have to do.

In conclusion, we need to get companies to stop requiring complex passwords as a form of “higher security”, and instead teach people how to make creative passwords that are not as easy to crack, for the ease of ourselves, and for the sake of our personal security.