Site Setup Journal: ACT I

ACT I: Domains and Hosting

In Site Setup Journal: Prologue, I set the scene for an ordinary website setup project. The plan: re-up a hosting account gone dormant, make sure the registrar is a domain pointing there, install WordPress, add a few miscellaneous plugins, install BuddyPress, do some configuration and maybe a little theme tweaking, and then have a nice private group site for the students of a class I’m in. Simple, right? I figured maybe an hour or two. Boy, was I wrong.

Once I removed the option to ping knowledgeable friends and get a fast, accurate answer to any question (a privilege I appreciate even more after this experience) and had to rely on public documentation and support services, I re-discovered just how woeful they are. I’ll try to describe each of the steps I took.

Step 1. Getting a Domain

An average person creating a new site would need to buy a domain, but I knew I had an unused domain sitting around from when I used to freelance, so figured I’d save the money and the addition of another domain (because the class site might get moved to the school site eventually). I had hosting accounts on both Bluehost and Dreamhost, but wasn’t sure where I had hosted  the domain I had in mind.

First I logged in at Bluehost. The hosting account had been deleted in July, which I hadn’t realized because the email address was one I no longer check, tied to an old business. The domain listed wasn’t the one I was looking for, though, so I went over to Dreamhost. I had to do some login gymnastics there also, because I’d had two accounts there, and as it requires login to be an email address/customer ID rather than a self-chosen username, I had to try a LOT of times to get the right combination of email and password and domains (I’d had accounts under 2 email addresses because one was for helping non-profits get sites set up). Finally after resetting passwords on the emails still in use, I got in. The non-profit account was still active, but I wanted the paid account for this project. In retrospect that was unnecessary, since the school is a non-profit, but oh well. The paid account had also expired over the busy summer. This one I did vaguely remember seeing emails about, but had never taken the time to go and do the login hoop-jumping to pay for the coming year because I was busy with work. I paid to re-up the hosting account, and it was back in business.

The domain was still listed there, so I wanted to make sure the registrar was still pointing at the Dreamhost nameservers. I went to Namecheap first, but it wasn’t listed there, so I had to check GoDaddy. I have a couple of domains there still that I hadn’t transferred yet due to timing around expirations. I couldn’t log in because I didn’t remember my password (hey, lots of people don’t use password managers). I went through the reset process, and got access. A domain I’d been registering for my brother had apparently expired (oops, another victim of my changed-email status), but the domain I wanted to use for the class was still there, and it was still pointing at Dreamhost.

I wasn’t keeping track of time, but I’d guess this all took about 30-45 minutes of going back and forth between sites and emails (often not instant but instead a few minutes later, or later, or later.

Summary: Requiring email address and/or customer number as login instead of allowing user-selected username does not result in a good user experience. Only doing password resets via sending to the email on the account does not address the reason why a lot of people need help resetting a password, which is lost access to the email address on the account. User-selected security access phrases or questions are a more user-friendly path to password reclamation.

Stay tuned for Act II, Setting Up WordPress. This is when we get into the fun stuff.

2 thoughts on “Site Setup Journal: ACT I

  1. User-selected security access phrases or questions are a more user-friendly path to password reclamation.

    Yes, and they are also, by far, the easiest method to exploit from a security perspective.

    There’s two routes most sites take in this manner: Pre-generated questions and user selected answers, or self-generated questions and answers.

    If the questions are premade, then they are usually overly simplistic and broad. “What is your mother’s maiden name?”, “What is your favorite color?”, “What was the name of your first pet?” Generally speaking, if people treat these as real questions, then they may not realize that these answers can be easily found through searching, or that they may be available elsewhere, like on their own Facebook page. These are also prone to social engineering or even malicious account attacks, where you sign up for an account on some website, and fill in the same types of “security” questions, only to have that site then use your answers to gain access to your other accounts.

    If the questions are self-determined, then they’re usually extremely weak, because people are dumb. “What is 1+1?” or “Type in password” or things like that happen a fair amount.

    People are bad at security. And like it or not, requiring them to be truly secure for *their domain name* makes sense. Nowadays, anybody who doesn’t use 2FA for their domain registrations is nuts, in my view. Security and user-friendliness are at odds here, I think.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s