Last Thursday we mitigated an attempt to breach customer data.
No customer data was obtained, and no domains or services were impacted, however in the wake of the attempt we have elected to accelerate our already planned security enhancements.
This is why, when you log in today and from now onwards you will be forced to reset your old password and we will start encouraging password aging, along with other security measures.
Those additional security measures include additional event notifications. As of today you will start receiving event notifications in addition to login notifications of the following event types:
- personal info edits
- password changes
- DNS changes
- whois record modifications
- nameserver delegation modifications
These event notifications will be turned on by default, but you may selectively disable them in your security preferences.
Please note that our system has supported IP/network ACLs and geo-country code limits for some time. We encourage all of our users to make use of them. They can be accessed via the “Security” option on the left hand side menu.
Additionally we are currently testing and will soon implement the following changes:
- optional two-factor authentication with the second factor being PIN delivered via SMS
- dynamic DNS clients will be forced to use auth tokens (the backward compatibility allowing account auth data via dynamic DNS clients will be disabled).
Mini-FAQ of the Attempted Data Breach
Was any customer data obtained, lost or stolen?
No.
[ Edit: We now feel that some member email addresses may have been exposed. See this post. No other data would have been exposed in this log file. ]
Were any customer settings or domains altered or had unauthorized changes made?
No.
What was the extent of the attempt?
Parties unknown began scanning our systems for vulnerabilities and attempting various exploits approximately 1 week ago. These attempts were detected and monitored as they occurred.
On thursday, Oct. 11 this culminated with the discovery of a third-party software plugin on a decommissioned web component that was still live over the web. A security weakness in that plugin facilitated the ability to read some of our user interface source code and server config files.
The issue was discovered within an hour of initial use and immediately plugged.
Did the affected server house any customer data such as user account passwords, domain auth codes or credit card details?
No.
All of our databases are firewalled off from any public facing web services and accessible only via our internal network VPN.
We do not store any credit card data within our systems and never have. All transaction processing has always been outsourced to our payment processors and we keep no payment data here. (There are also strong indications that this is what the perpetrators were after).
What are you doing about this?
In addition to accelerating our planned security enhancements we are undertaking the following measures:
- The legacy system shutdown is being accelerated and will be completed by the end of this week. If your userid has not already been migrated to the new system you will be notified via email when it happens and we plan to shutdown the legacy system on Monday October 22. Additionally, single-sign-on between the legacy system and the new system has been disabled.
- The RCMP Tech Crimes Unit has been notified and debriefed. In 2005 easyDNS was designated by the RCMP to be a “Critical Component” of Canada’s Information Infrastructure and we maintain close contact with their tech crimes unit (a.k.a “O Division”).
- We have brought in an outside security firm to conduct a source code audit and assist us with forensics.
- The affected web server has been decommissioned, snapshotted and removed from the internet.
Our decision to disclose this is in keeping with our ethos of transparency and brutal frankness.
If learning this rattles you just a little bit, enough to review your own security practices, maybe turn on the ACL you’ve been meaning to for awhile or change that password you’ve been using just a little too long, then at least some good has come out of it. I know it’s galvanized us to raise the bar further.
Conclusion
Security events happen to everybody, with varying degrees of success (and subsequent disclosure). What is important in this case is that your data is and remains safe, that there has been no compromise of your DNS, domains, email or any other service here, and we are accelerating our security enhancements to stay ahead of the next threat.
Is there any evidence that passwords become weaker as they age? What is the basis for requiring that users change passwords periodically? (I agree with with other security measures you are taking, however.)
Hi Steve,
That’s an excellent question. Password aging does not relate to passwords somehow degrading over time, but rather a requirement to change them at regular periods. This is considered good practice by some, and not as useful by others. It’s an industry debate of sorts, but it has one main strength
It discourages the use by users of a single password across multiple sites. One of the key issues with passwords is that due to the difficulty of remembering them, far too many people will use a single password for many different sites. This means that if site random domain.com where you have an account has bad password storage techniques (bad or no crypto, for example) and gets hacked, and you are using the same password for multiple sites, the hacker now has a good shot at accessing your info on other sites.
One drawback is that it is felt that this can encourage the bad habit of writing down passwords on paper or near computers. This, however, has long been a bad practice (as exemplified in old 80’s movies where the ‘hacker’ lifts the keyboard of the computer in question and reads the password), and is easily resolved by the use of cryptographic password stores such as PasswordSafe, Password Gorilla, and a number of others where passwords can be stored, protected by extremely strong cryptography.
Our feeling is that the inconvenience is outweighed by the protection against cross-system attacks based on a single hack.
Here’s a quick blogpost that outlines some of the pros and cons. I hope this has answered your question. Please let us know if there’s anything else we can let you know regarding this.
Arnon
In addition to what Arnon said, I think it is important to note that, along with other security enhancements, many of them will be available but not mandatory. In the case of password aging, we will make it an account option, aside from times when we upgrade algorithms or have some other reason to enact a global reset.
We have had a few enterprise customers asking for the ability to enable password aging and enforce it for their accounts.
Two factor is great until your working in an IT department and have a single use account for managing domain with EasyDNS.
Why SMS? Will this work with International customers?
Why not offer Google Authenticator based token access?
We’re looking at Google Authenticator as well, it’s a possibility.
As for the single account for managing domains there is also the ability to setup shares between multiple accounts, we also do virtual instances if you have a lot of domains under management. There’s another Australian company down there bringing on something like 1000 domains going that route. (It’s like having your own company “easydns” platform).
Good job guys. It sounds like you have handled this well, with timely disclosure.
BTW, I know this isn’t news, but if someone is using the same password on your site, as elsewhere…they are asking to be whacked… just such a bad idea.
+1 on using Google Authenticator for 2-factor auth. SMS would be clunky.
I applaud your transparency and swift reactions. Particularly good on you for giving thought to the nuances of password aging. I have too often seen this ISO-17799 recommendation interpreted as a mandatory requirement, without any thought for the consequences.
I would like to nominate one more candidate in the domain of “password managers”. Years ago I gave up trying to remember hundreds of distinct passwords, and opted for LastPass instead. It has served me well ever since.
No doubt there are pros and cons for all of the other alternatives mentioned; I like LastPass because it integrates with YubiKey. In effect, a single FOB gives the user access to all her(randomly generated) passwords.
Re: Password aging.
Every time a password is used, there is a chance that it has been observed, whether by shoulder surfing, sharing, keyboard logger, a tiger team zooming in with a camera from the next building (like in Sneakers, the 1992 film), or some other means. The longer a password is used, the more probable that has been exposed, therefor periodically changing passwords helps limit the probability somewhat of an exposed password being abused.
Mark,
Please check out Yubikey for another 2F auth option in addition to Google Authenticator. http://www.yubico.com/
2F auth for infrastructure providers is strongly recommended for the customer facing side these days. Please help raise the bar in the industry and lead the way in adopting 2F auth for customers.
Ping me if you want assistance.
Eric Carroll