More from: GoDaddy

GoDaddy, MySQL, and the Time Zone Problem

My public charity helps senior generational social dependents (hereditary poor due to a number of factors) learn middle class work ethics and job skills through a Federal program know as the “Senior Aides” or SCSEP program. This program pays seniors minimum wage to learn job skills in a working context. We must sign off on their time sheet every other week to attest that they really, truly, did actually work the hours shown on the time sheet, however these seniors sometimes forget days that they called in sick or left early, so I wrote a simple script as part of our web site that provides a time clock. One button for IN and one button for OUT and the MySQL database records the timestamp perfectly.

The problem I ran into is that we buy hosting on GoDaddy.com which is on the Pacific coast on Pacific time, my agency is located in Fort Wayne, Indiana in the midwest on EDT, and the normal MySQL commands to set the time zone do not work.

mysql_query("SET time_zone = 'America/Fort_Wayne';"); // Does Not Work
mysql_query("SET time_zone = 'America/Indianapolis';"); // Does Not Work

Apparently GoDaddy has not loaded the standard TZ file and they refuse to disclose what I should tell the MySQL server my timezone is. Several of their customer service people told me that if I knew how to tell MySQL which time zone I am in it would leave them open to cyber attack. I have no idea how knowing your timezone string would leave GoDaddy.com open to attack. Moving right along…

This left me changing the timezone manually every spring and fall, which is tedious and occasionally results in very confused Seniors telling me that the time clock is broken because it shows they clocked out an hour early (they never complain that it shows they clocked in an hour early).

// mysql_query("SET time_zone = '-5:00';"); // Uncomment in Fall
mysql_query("SET time_zone = '-4:00';"); // Uncomment in Spring

I found a way around this today in the comments on a post at http://www.electrictoolbox.com/mysql-set-timezone-per-connection/

date_default_timezone_set('America/Fort_Wayne'); // set timezone in php
mysql_query("SET `time_zone` = '".date('P')."'"); // set timezone in MySQL

Some of the comments say this does not work on BlueHost, but it does work for me on GoDaddy.com.

Hope this helps!

–Kubulai


Protecting Your Web Site from Loss of Business

Yesterday 9/10/2012 the GoDaddy.com DNS servers were not working from about 12:00 noon until around 5:00 pm. This left several million business web sites unavailable, even through the web sites themselves were fine, because the name servers (that point browsers to the web sites by name, e.g. google.com, facebook.com, or jdnash.com) were broken. Although an individual claiming to be a rogue Anomyous “security expert” claimed credit for the outage, GoDaddy revealed that it was an internal error, not an external hack, that scrambled the DNS data. See http://www.networkworld.com/news/2012/091112-godaddy-hack-262342.html for details.

The event can be a wake up call for business, both to back up our web sites and to use a little wiser implementation of DNS servers in our domain registry entries — in particular, to specify name lookup via more than one DNS company so that if one company is unavailable, the other will still work and access to our web sites will be unaffected by a single point failure. Blogger Robert Simpson writes about how to do this on his blog at SpitBall.comhttp://www.spitballs.com/Blog/Entries/2012/9/10_How_To_Keep_Your_Web_Site_Up_During_a_DNS_Outage.html.


GMail for Non-Google Domains

You can have GMail handle your email even if Google is not hosting your web site. See this document for detailed instructions to fit MX Records on GoDaddy.com DNS here: http://support.google.com/a/bin/answer.py?hl=en&answer=33353&topic=1611273&ctx=topic. There are like instruction sheets for many other registrars here http://support.google.com/a/bin/topic.py?hl=en&topic=1611273. There was also a *VERY* handy tool that looked up the current, working, DNS MX Records for me. It is located here http://www.dnsstuff.com/tools. There are several tools on this page: you want the one called “DNS Lookup”. Enter the domain and click submit. It wants you to join (pay) HOWEVER if you run the tool from the Google help page at http://support.google.com/a/bin/answer.py?hl=en&answer=140038 it is free.

Finally! Started to change the DNS for a customer at about 18:00 and after the switch was in progress he mentioned his email is hosted on GMail, not his old web host. Now I should have ASKED that question before we began, but we backed out of the switch and I started digging. And digging. And Finally, I Found Instructions at 24:00 for setting up the MX record to point to Google GMail. And very NICE instructions they are, finely documented with pictures and nicely typeset.

The one I needed was for GoDaddy, but there is an extensive list here http://support.google.com/a/bin/topic.py?hl=en&topic=1611273. If you are not clear on what an MX record is, or why it is needed, this explanation http://support.google.com/a/bin/answer.py?hl=en&answer=140038 is very nice.

So if you are really constrained by your email host, you might consider using GMail: it will still show up as your domain name, but it will work oh so much nicer. And since I have done the research for you, you won’t need to spend 6 hours digging.

Hope this Helps!

–Kubulai


The COST of Customer Inconvenience in Passwords

“The Customer may not always be Right, but the Customer IS ALWAYS the Customer.”Bob Parsons of GoDaddy.com author, entrepreneur, entertainer, motorcycle enthusiast, elephant hunter.

I have previously written about the folly of unreasonable demands placed upon customers concerning password assignment by well-meaning but misguided hosting service providers. Typically these password requirements include:

  • password must be at least eight characters long
  • password must contain numbers
  • password must contain lowercase letters
  • password must contain uppercase letters
  • (sometimes) password must contain a non-alphanumeric character
  • (sometimes) password must NOT contain a non-alphanumeric character

As I have stated before, of these six common rules the only technically valid requirement is that the password must be at least eight characters long. The reason for this is that the most common method of cracking passwords after harvesting password data from an insecure server is the rainbow table attack: the criminal generates a table of all possible passwords in one column, encrypts those passwords in a second column, then matches the encrypted column of the “rainbow table” to the harvested passwords and reads the original password. If we were talking about Private Investigators we would be discussing something like the “upside down” phone book where things are sorted by phone number instead of customer name.

This kind of attack is only practical for passwords less than eight characters long so passwords more than eight characters long make it more difficult to use a rainbow table to crack passwords. In a rainbow table the computer does not care if the characters are upper case, lower case, numbers, “special”, or even non-printing characters — they are all the same to the computer. The only ones affected by this complicated set of rules are people who have trouble remembering what exactly they used for a password.

The most common mistakes that lead to an account being cracked are: 1. using the same password on more than one web site, 2. negligence in script design or coding that does not limit or validate data before passing it to the database, and 3. failure to escape all special characters in user input before passing it to the database. Typically the crooks will harvest passwords from some insecure web site then identify interesting logins — names of high profile people — and try the passwords on Yahoo, or Google, or some other site.

The problem with the hosting password demands listed above is that other than the first rule they do absolutely nothing to improve security: the opposite is actually true; they greatly reduce the customer’s ability to recall the password.

Today I attempted to check my email accounts on my main email hosting account using a new smart phone. I was certain my password contained a zero, 0, in the second character position, but I couldn’t remember the sixth and eighth characters with certainly. As it turned out, the second character was a capital O (“Oh”) not a zero, the attempts to login exceeded some limit and the account was locked. I could not check for customer email until I got back to my hotel room 10 hours later. There was email from a customer urgently awaiting my attention, on a Friday, and I could not help that customer before he went home for the week.

Hosting companies earn money by selling hosting to businesses. Those businesses earn money by providing web services to their customers. When customer service is stopped because those businesses cannot respond to their customers in a timely manner because the owner could not remember the password to their hosting account and got locked out they start to loose money.

I realize that my motivation for pontificating on this topic was stimulated by my own experience, but this is not the first time I have called for change in this area: my purpose is to call for rethinking of general password policies — that password policy should be making things more secure for everyone, not just making it hard for the business customer to remember his or her password.

I’m not writing in anger: I’m not calling out my hosting provider: I did not even name some web sites who have a reputation for being notoriously sloppy with their customers private information and provide a prime source for hackers to harvest passwords.

The cost of unreasonable password requirements not defensible by technical facts is greater than simply inconveniencing one or two non-technical individuals who can’t remember how to log in to their web sites: unreasonable password demands cause technically adept people to have trouble remembering passwords too, and that can become expensive.