So many products make email verification optional in order to improve their funnel. But it's a huge security risk, because it leads to bugs like this. Very few engineers and PMs will actually stop to think: "Wait, what if the user's email address isn't verified?"
I kind of wish we could just pass a law that says you have to validate email addresses before attaching them to accounts at all. Because otherwise, competitive pressure will keep pushing people towards not doing it and aiming this gun at their foot in the name of conversions.
In the absence of a law: If your service insists on allowing unverified email addresses, you should store them in a completely different place in your database from verified ones. Maybe even obfuscate them with some encoding. Do whatever you can to make it really hard for anyone to accidentally rely on an unverified address. Ideally make it impossible for anyone except the team in charge of authentication to even see an unverified address.
On another note, holy shit. So many people (myself included) chose Google Domains specifically because they thought it would be secure and trustworthy, because it's Google. Won't make that mistake again.
At a previous job I complained to company leadership that we shouldn't trust email addresses without verification.
I think the company eventually required verification, not because their trusted employee told them, but because a security review of the product pointed out the lack of email verification.
When it’s a security review and something is on paper, there is now documentation of potential liability.
When it’s just a random staff member complaining they want to do something that makes it harder to onboard customers, there’s no proof of incompetence, and incompetence can still be blamed on the developers.
Yes.
But for what purpose will you be sending it - to cover your ass, or to make yourself feel superior?
Also keep in mind that the company has full access to your work email account therefore they could delete the email if they wanted to. Not likely they would in general but people have been known to do all sorts of things in situations where a written record could hurt them.
To suggest a feature or describe an issue on a product you're working on can be most easily done by just talking to people, for example by bringing it up in a design or planning meeting with the team and management. If it gets picked up it will get added to the schedule in some written form. It does not need to specifically communicated by email or written down, unless explicitly asked for.
Therefore the main purpose of writing the initial suggestion down is so there's a record of it for future use. Either to cover your own ass when management/auditors/lawyers get involved, or to say you were right and management was wrong and make yourself feel superior.
It used to be every site would require a verification email be clicked through. Later on some didn’t. I thought they must have some extra and impressive security to pull this off. Turns out they likely all have nothing in place to make up the gap.
I might charitably and optimistically interpret the transfer to Squarespace as one of many short-sighted decisions that Google made that's unique to 2023, the period where Google had its greatest internal turmoil shortly after the layoffs. Every year before 2023 was better and Google will only get better from 2024 onwards.
Though personally, when I heard that Google is selling off Google Domains, I immediately transferred my domain elsewhere. Not necessarily because I hate any of the parties involved, but because a transfer at that time was fully within my control with fewer unknowns, unlike waiting for some bulk migration with no announced timeline.
I choose Google Domains just for the ease of use but when it came time to move there was no way I was transferring to Squarespace. I'm not sure how long I'll stick with Cloudflare, but for now they will do.
I went to joker, for much the same reason. Their initial login page is the only one I know which proffers the 2FA input along with the password, a design feature I really like. And, they correctly applied my "automatic renewal" to NOT pre-emptively renew now, but say it will happen on the anniversary so I don't lose any of the last day(s) value.
Joker was recommended to me by another techie. Its German.
I was extremely disappointed google walked away from the domain game, because their interface was simple, logical and ironclad. I do not see how they possibly had costs in this which were not exceeded by the profits, and "click here" benefits for GCP and related product.
I've been using joker for nearly twenty years and it has always just worked.
I'm probably misunderstanding you, but when you renew a domain you get an extra year (or whatever) measured from the expiry date, not measured from the renewal date. Renewing early doesn't lose you anything (except a bit of cash flow). This is true for .com and .uk anyway.
>kind of wish we could just pass a law that says you have to validate email addresses before attaching them to accounts at all.
We did, the government can only collect the data it needs to complete it's stated objective. fedramp compliance. This exact exploit has happened at nearly every Fortune500 company.
> otherwise, competitive pressure will keep pushing people towards not doing it and aiming this gun at their foot in the name of conversions
Market forces, people should be pressured to use more secured services.
One of the (many) problems with the market is that consumers have imperfect information. In this case specifically it's almost never possible to have an accurate picture of a company's security in advance of a mistake like this one.
> Market forces, people should be pressured to use more secured services.
There is no such pressure in the market right now. Look at the email-provider market, where secure offering like Proton Mail are nowhere close to less secure ones like Gmail, Outlook/Live.com, etc. Why don't people just flock to Proton Mail?
In theory, S/MIME and SMIMEA. In reality, normal users demand account data recovery in cases of lost encryption keys and passwords. So key escrow is required, which isn't E2EE. ProtonMail tells forgetful users to shove it, which limits its adoption; meanwhile ProtonMail also supports webmail (another feature requirement) which decrypts messages in the browser, weakening any E2EE claims.
> I kind of wish we could just pass a law that says you have to validate email addresses before attaching them to accounts at all. Because otherwise, competitive pressure will keep pushing people towards not doing it and aiming this gun at their foot in the name of conversions.
Would also help when people don't get their receipts or reminders or etc because they gave the company someone else's email. I think I've got three people who think my gmail is their address. And I can't just give up and close it because Google won't let you use a non gmail account as an Android account. Has to be gmail or whatever G Suite is called today.
I think this is genuinely a good takeaway, its so easy for these two sides to assume something about the other (ie we have validated) that you can see how it can happen.
> Taylor Monahan, lead product manager at Metamask, said Squarespace never accounted for the possibility that a threat actor might sign up for an account using an email associated with a recently-migrated domain before the legitimate email holder created the account themselves.
> “Thus nothing actually stops them from trying to login with an email,” Monahan told KrebsOnSecurity. “And since there’s no password on the account, it just shoots them to the ‘create password for your new account’ flow. And since the account is half-initialized on the backend, they now have access to the domain in question.”
This sounds like gross security negligence, and should probably be considered a crime when you're at the size of Squarespace with (assuming) a dedicated security team. Hopefully executives/management can be held responsible for whatever damage was done because of this.
Squarespace is directly responsible, my irrational instinct is to blame Google even more, in that their role involved active abdication of responsibility for purely self-interested reasons and involved more employees than just their security engineering team.
Domains are critical infrastructure, wasn't any reason to sell them other than Wall Street puffery. Obvious downside was leaving business customers who got them via Cloud exposed. Per my uninformed intuition at the time, there wasn't a secure way to do this sort of switchover without a lot of manual reaching out neither of them were going to do.
Additionally, Google went out of their way to sweeten the deal by A) making Squarespace the reseller for any associated Google Workspace records which B) greatly widened the vulnerability surface. [1]
This sounded uninformed to me, until it happened, so [2] quotes the retrospective at length to show there was no secure and automated choice.
[1] "Furthermore, as Squarespace is an authorized Google Workspace reseller, any teams who had purchased Google Workspace through Google Domains had their license transferred to Squarespace. This allows the threat actor to create new administrators in Google Workspace via the hijacked Squarespace account."
[2] "However, what happens for [domain owner] emails which are not already registered to an [Squarespace] account? Well, you could preemptively create a new account for that email and send them a temporary password, but sending passwords in plain text is not a good practice, it would be pretty complicated to create millions of users with temporary passwords, and most people migrating probably want to use their Google account to sign in, not a password. Maybe your systems don’t even support creating temporary users like this."
It's the Hunger Games inside, for a 1000 reasons. tl;dr: MBAs won, thoroughly.
The Great Game* is figuring out how to cut people without seeming cruel. Easiest way to do this is cut whole teams at once. This almost assuredly was seen as a massive victory inside: made money to cut people that no one will miss because it was a political orphan.
* i.e. "What does my boss' boss' boss' boss think their marching orders are?" -- the MBAs won, so it's a non-sequitor for them to think it is about products, quality, consumers, or simply doing the right thing. In order its spend less $, AI, get more $.
I'm yet another person who used google domains specifically because it was google and their security engineering is extremely good. I can't believe they sold it to squarespace.
Porkbun seems extremely competent, and they allowed me to register two yubikeys, reinforcing that. Hopefully we won't be back here in 2 years discussing where to hop to next.
It is already criminal for people to hijack websites like this. It is also criminal to defraud people.
If you are damaged by a company's negligence in this way you just sue them.
This isn't as hard as seems. I've known people that make it a practice to take corporations to small claims court every time there is a data breach or some other problem with a company that has a account with them. It is usually pretty easy to win those sorts of cases as Judges have little sympathy for these mega corporations.
If you are lucky and the company involved is actually incompetent then chances are they won't respond to the small claims lawsuit and you win by default. Get whatever you asked for.
The problem with making it a crime (it probably already is a crime) is that the blame will be placed on the developer when it probably was not the fault of the developer.
In these types of situations I’ve been in, usually the developers already complained, and it’s really not the fault of the developers.
This creates this weird situation where developers have to do more and more to protect themselves from situations like this.
It doesn’t take more than a few seconds of thinking to realise that google should have made some kind of way for authentication to be transitioned over. Even something as simple as sending out a “transfer” email link or even just an api that squat space could have called to allow customer transfer verification.
If the developer agreed to implement it then it is the fault of the developer. Making the developer liable both motivates the developer to not agree to things that are illegal and provides them with an argument for pushing back.
Simply making something illegal does not change culture. The lowest guy on the payroll has no leverage beyond leaving. Companies have no reason to change what they are doing.
> Simply making something illegal does not change culture.
Correct, you also need enforcement.
> The lowest guy on the payroll has no leverage beyond leaving. Companies have no reason to change what they are doing.
Leaving is a huge leverage. Even easily replacable corporate drones cost a lot to replace. If a company needs to find someone willing to risk going to prison they will are much less likely to be successful.
Wow that's a terrible way Google managed customers security, selling them to an incompetent buyer. So many red flags pushing me to stop using anything Google.
Google sold Google Domains to the worst possible buyer! Right after a bunch of my domains, one by one got transferred to those amateurs, creating a random subdomain for each domain, I started to receive notifications about somebody trying to reset my password!
Out of the thousands of product Google provides, domains was the one they were best aligned with their expertise and core business. I can’t for the life of me understand why they would get rid of it.
When I evaluated squarespace for a couple nonprofits I work with, they lost out to Wix because squarespace lacked a backup solution. I was stunned by that, but certainly not that such a cluefree team would cut security corners.
How is it possible that this team blew off backup functionality for a product that is targeted at low skill end users? Maybe they ran out of money paying designers for yet another template that utilizes a full screen image on the landing page?
Squarespace is targeted at technically illiterate small organizations. They make their workflows as simple as possible for that user base. I helped a local small nonprofit with their Squarespace site around 10 years ago, I know that's been long enough that it might not represent how things are today, but doing anything that wasn't implemented by their site builder tool was basically impossible.
> How is it possible that this team blew off backup functionality for a product that is targeted at low skill end users?
That sounds to me like the perfect target market for blowing off backup functionality. That market doesn't demand that functionality. Backups are something that a more technically-literate purchaser might demand.
Direct link to an unofficial and 3rd party retrospective, it would seem.
> As Squarespace has yet to release an official statement or postmortem, the following is our strongest theory on how the threat actor was able to gain initial access to Squarespace accounts. It is the most likely explanation given the information we collected from numerous affected companies and experiments we ran ourselves.
They're not competent. Data point: they sent me an email saying my domain would automatically renew in 30 days, and then renewed it in 2. While sure, I'm not upset that my domain renewed, I ended up moving to porkbun because I expect a registrar to accurately tell me dates and times. If you say something is happening in X days, I expect it to happen in X days.
Labeling a whole company with millions of domains under management "not competent" because they sent one wrong email or there's a misunderstanding on how it works on the customer side?
And exactly, I expect clear and correct communications. If you say "your domains will automatically renew in 1 month" then it needs to be in one month.
One thing that sucks when moving registrar is that some (Namecheap, Porkbun, Enom/Tucows) doesn't let you set DNS entries before migration. Move reg, updated NS and then add entries.
So, my process now is to put DNS service OUTSIDE the registrar - so that switching one doesn't have to impact the others.
Why these providers don't let me create the NS Zone before transfer confounds me.
Porkbun definitely lets you do that, they allow you to add an "external" domain which runs on their DNS (actually Cloudflare) but isn't registered through them, then you can seamlessly transfer the domain in to Porkbun later.
IIRC Spaceship (Namecheaps soft-relaunch) lets you set up your DNS records as soon as you initiate a transfer to them, before it completes, so the records are ready as soon as the nameservers switch over. Not sure about the original Namecheap, I haven't used them for a while.
They shouldn't publish a zone for a domain they don't control (yet). Regardless of who whois says manages the domain, if I were to query the new registrar's servers they could theoretically send people somewhere else than what was intended with the currently published zone information.
I don't want them to publish, I just want to create them before migration. Other registrar's had it for a while and Namecheap for sure still don't (maybe their new UI but they lost me years ago)
DNS is hierarchical so as long as the root servers point elsewhere it doesn't matter what they publish and once the root servers are updated then the new servers are the authoritive ones.
I point my computer to use a local DNS server, I ask it to resolve an ad domain... the request doesn't go out to the root servers, it gets RPZ denied at the DNS server. The root doesn't mean anything if the local DNS server claims to know the answer to your query. The same goes for a registrar's DNS server that is publishing zones it doesn't own.
What you are describing is a forwarding DNS query resolver, which can be configured to directly answer queries without forwarding them upstream in the DNS hierarchy. This is sometimes used for ad-blocking, but the archetypical example is the DNS resolvers your ISP usually provides. Their purpose is to forward your queries to the nameserver responsible for the zone you ask about.
Domain registrars, however, usually do not operate forwarding DNS resolvers. They typically only answer queries for zones that they are responsible for, and give you an NXDOMAIN response for anything else. For this reason, nobody would use a non-forwarding DNS as a resolver for their computer since it would make it near impossible to reach hosts on the Internet (unless you happen to query a record for one of the zones they provide service for).
I've been very happy with Dynadot. I don't like that domain hosting is just one of many products for Cloudflare and others (as we've seen come up for Google!) and have had bad experiences with Namecheap et al.
Porkbun here, and some AWS (which is a reseller of someone else iirc). Also we have a bunch of older domains at OpenSRS but tend not to use them for new work.
I tried cloudflare but am worried they're going to start restricting features or something because of how aggressively they try to upsell shit I don't need.
They say they sell domains at cost, which is a red flag since it means people who only use them as a register are going to be the first to go when they start loading up the enshittification bandwagon.
I don't care about the price of domains. They're relatively cheap even with the mark up from your typical registrar. What I care about is peace of mind that I won't lose my domain due to an incompetent registrar, or will have to scramble to transfer everything again because of reasons outside of my control. Cloudflare doesn't offer that.
I've now decided to move to Namecheap. Idk how solid they are, but they seem to have been selling domains for a very long time.
The problem with Squarespace remaining silent with this is that there’s a deafening lack of authoritative information about whether this issue has been patched. The researchers and Krebs are stopping short of making definitive statements because obviously only Squarespace can do that, and they aren’t.
I have emailed some former clients I knew to use Google Domains just as a heads up, with steps from the article.
It would be nice if Squarespace showed a modicum of ownership for their failings here.
When a CA issues a cert, the cost to the CA is essentially nothing.
When a registrar registers a domain, that costs the registrar money because the registrar has to pay a fee to the registry. So a registrar generally cannot give out domains for free.
Now, a registry could in decide to charge no fee. That's what .tk used to do. So you could get a .tk domain for free. Of course then .tk domains got the reputation of being cheap junk and spam.
Zero cost TLS certificates might be what Let's Encrypt is known for, but it wasn't the first entity to offer them. LE also disrupted the CA market because of IdenTrust's initial cross-signing, and ACME's development and rollout, under the banner of a well-funded reputable 501(c)(3). Nothing is stopping someone from starting an above-cost 501(c) non-profit registrar, similar to the ISRG or the PIR.
Not only are there wholesale per-domain fees for registries (which tend to increase every few years), and the small ICANN fee for gTLDs, domains also have high customer support overhead that can’t easily be automated away like the LE cert process.
Also keep in mind that domains are a “source of truth” unlike certs, which rely on the domains for verification.
If you do, be sure you're on the side that is intentionally trying to find vulnerabilities, not the side trying to defend against them.
The defense side sucks. You have to deal with security vendors that are eager to sell you snake oil. You have to actively fight against management that wants to save money. You have to fight against users who don't care about security.
If everything goes smoothly and you have no security problems, the bosses wonder why they even pay you. If you have a security incident, the bosses wonder why they even pay you.
For much of the last decade, my career seems to be more and more partnered with cybersecurity teams...I like the kinds of people, and i like partnering with such teams. I work so closely with such teams, and many of my peers/colleagues - both on the cyber teams and others not on cyber teams - have suggested that i should pursue a career in cybersecurity...they often say that i have the head for it...that i have a natural knack for actually working in cybersecurity...but I've hesitated and i can't always succinctly verbalize why. Well, i think you stated it much better than i could; the defense side sucks for the reasons you stated!!! :-)
Clearly Squarespace is the guilty party here, but man, I am still upset Google shut down Domains, and can't help but direct some ire their abandonment of yet another product.
They did? I missed that. It hasn’t lasted even ten years, has it?
I remember reading the Domains announcement and thought to myself - “you have to be a fool to trust Google to host your domains long-term”. Feels good to be right, but I feel bad for everyone who jumped on the bandwagon. I cant imagine trusting Google products to last those days.
The entire consumer registrar industry is untrustworthy. I can't think of a worse category of online services, ranked by security and sleazebaggery, with the possible exception of the VPN market.
It was useful because it integrated super nicely into workspace account administration. Unfortunately all the issues have been painfully predictable and the rollout has been bad.
I'm in your same boat. I had a bunch of domains with Google because of the brand recognition, but this acquisition annoys me immensely and clearly it's off to a great start!
For the impatient, what they did was: put a zillion DNS registration accounts into a limbo state where anyone who knew, or could guess the email address associated with an account, could supply that, and a password of their choice, to gain authentication credentials valid for the account because they stored the supplied password without any verification that it came from the owner of the associated email address.
So glad I migrated everything off of Squarespace. Just an awful experience. Slick website. Slow as mud movement for everything else. AND--the owner can't modify MX records, you have to create and grant admin rights as the owner to an entirely separate account.
I kind of wish we could just pass a law that says you have to validate email addresses before attaching them to accounts at all. Because otherwise, competitive pressure will keep pushing people towards not doing it and aiming this gun at their foot in the name of conversions.
In the absence of a law: If your service insists on allowing unverified email addresses, you should store them in a completely different place in your database from verified ones. Maybe even obfuscate them with some encoding. Do whatever you can to make it really hard for anyone to accidentally rely on an unverified address. Ideally make it impossible for anyone except the team in charge of authentication to even see an unverified address.
On another note, holy shit. So many people (myself included) chose Google Domains specifically because they thought it would be secure and trustworthy, because it's Google. Won't make that mistake again.