That seems like a GDPR violation waiting to happen. It shouldn't be possible for them to store an email address like that forever and be in compliance.

AWS support seems to be struggling. I just came to help a new customer who had a rough severance with their previous key engineer. The root account password was documented, but the MFA went to his phone.

We've tried talking to everyone we can, opening tickets, chats, trying to talk to their assigned account rep, etc, no one can remove the MFA. So right now luckily they have other admin accounts, but we straight up can't access their root account. We might have to nuke the entire environment and create a new account which is VERY lame considering they have a complicated and well established AWS account.

Good for them. It's amazing how pointless most security is when a 10/10 rating to some commodity communication service's support from a phisher is all it will take.

S3 was well aware of the pain when I was there ~10 years ago, just considered themselves handcuffed by the decisions made before the idea of a cloud was barely a twinkle in a few people's eyes, and even the idea of this kind of scale of operation wasn't seen as even remotely probable. The namespace issue is one of a whole long list of things S3 engineers wish they could change, including things like HTTP status code behaviour etc.

I've never really understood S3's determination not to have a v2 API. Yes, the V1 would need to stick around for a long time, but there's ways to encourage a migration, such as having all future value-add on the V2, and maybe eventually doing marginal increases in v1 API costs to cover the dev work involved in maintaining the legacy API. Instead they've just let themselves, and their customers, deal with avoidable pain.

Author here. Thanks for the call out! I've updated the article with attribution.

> especially with the really short name limit of only 24 characters.

And with no meaningful separator characters available! No dashes, underscores, or dots. Numbers and lowercase letters only. At least S3 and GCS allow dashes so you can put a little organization prefix on them or something and not look like complete jibberish.

You can always use plus-addressing if your email provider supports that. AWS considers plus-addressed root emails to be unique.

Help me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation.

And on the flip side I can easily see why not allowing email addresses to be used again is a reasonable security stance, email addresses are immutable and so limiting them only to one identity seems logical.

Sounds quite frustrating for this user of course but I guess it sounds a bit silly to me.

I recall being shocked the first time I used Azure and realizing so many resources aren’t namespaced to account level. Bizarre to me this wasn’t a v1 concern.

Notably Discord stopped using that format two years ago, moving to globally unique usernames.

Their stated reason[1] for doing so being:

> This lets you have the same username as someone else as long as you have different discriminators or different case letters. However, this also means you have to remember a set of 4-digit numbers and account for case sensitivity to connect with your friends.

[1]: https://support.discord.com/hc/en-us/articles/12620128861463...

>Help me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation.

Have you ever worked in a company of any size or complexity before?

1. Multiple accounts at the same company, spun up by different teams (either different departments, regions, operating divisions, or whatever) and eventually they want to consolidate

2. Acquisitions: Company A buys Company B, an admin at Company A takes over AWS account for Company B, then they eventually work on consolidating it down to one account

Doesn’t solve the SSO issue though unless you change your login email

This was a secondary AWS account in use by the company that had been in place for quite some time and that secondary account was just no longer needed. So to consolidate things down, it was deleted. Also at that time, SSO wasn't being used for anything with the company - and they were on a completely different email provider.

I'm not arguing that it was impossible to know the long term outcome here, but it doesn't mean it isn't frustrating. If you've spent any length of time working in AWS, you know that documentation can be difficult to find and parse.

I can certainly understand why the policy exists. What I think should be possible is in these situations to provide proof of ownership of the old email address so it can be released and reused somehow.

I did something similar.

When I started, AWS was in its infancy and I was just some guy working on a special project.

Now that same account is bound into an AWS Organization.

AWS Changed. My company changed. the policies change out from under you.

It’s not hard to imagine a case where maybe there’s 2 offices that had their own separate aws accounts and they closed one.

AWS has been around for quite a while now. It’s also not impossible to believe that there are companies out there that might have moved from aws to gcp or something, and maybe it’s time to move back.

> And on the flip side I can easily see why not allowing email addresses to be used again is a reasonable security stance, email addresses are immutable and so limiting them only to one identity seems logical.

If they aren't actually deleting the account in the background and so no longer have a record of that e-mail address, then they must allow re-activation of the account tied to that e-mail address using the sign-up process.

what if you stopped using AWS for a while, then came back?

I like it for buckets, but adding a four digit code won't help with the package hijacking side of things - in fact might just introduce more typo/hijack potential. It'll just be four more characters for people to typo.

The .NL gTLD used to work like that for personal registrations (ie individuals without a business registration). $name.NNN.nl where you were allowed to choose the number.

It won't surprise you the scheme never caught on and has been decommissioned (you can now register any available domain as an individual as well). The difference is probably few people use a personal TLD, but many use a name on some social media.

if your bucket name is ever exposed and you later delete it, then this doesn't help you.

I don't think that'd prevent this attack vector.

> email addresses are immutable

1. Use "admin@domain.com"

2. Let the domain registration lapse

3. Someone else registers the domain and now can't create an AWS account.

Rare but not impossible.

And the naming restrictions and maximum name lengths are all over the place: https://learn.microsoft.com/en-us/azure/azure-resource-manag...

Storage accounts are one of the worst offenders here. I would really like to know what kind of internal shenanigans are going on there that prevent dashes to be used within storage account names.

The actual reason here, implied but not stated outright in that one, is that Discord being a public platform, having only numbers to discriminate between users makes it extra-trivial to impersonate someone else. Obviously you can still do some of this with unique usernames (you see slight misspellings, adding harder-to-see characters like periods, etc, as strategies), but these are more complex to execute on at scale and easier to block once and reduce the impact, vs being able to use ~arbitrarily many post-username numbers.

IMO a better general solution is UUIDs and a petname system, at least as far as chat apps are concerned.

For buckets I thought easy to use names was a key feature in most cases. Otherwise why not assign randomly generated single use names? But now that they're adding a namespace that incorporates the account name - an unwieldy numeric ID - I don't understand.

In the case of buckets isn't it better to use your own domain anyway?

I just want to be able to use a verified domain; @example.com everywhere.

I think a better policy would be to disallow bucket names that follow the account regional namespace convention, but don’t match the account id indicated in the name.

The entire article talks about “guessing” the bucket name as being the attack enabler, not the leaking of it. What does the landscape look like once you start doing the basics like hashing your bucket names? Is this still a problem worth engineering for?

Sure they can. Use any other email address at domain.com to register.

(i work at discord)

Not saying that wasn't ONE of the reasons but the main reason was really that a large chunk of users had no idea that they even had a discriminator, as it was added on top of your chosen username. "add me on discord, my username is slashink" didn't work as people expected and caused more confusion than it was solving. This wasn't universally true either, if you come from a platform like Blizzard's Battle.net that has had discriminators since Battlenet 2.0 came out in 2009 it was a natural part of your identity. End of the day there were more users that expected usernames to be unique the way they are today than expected discriminators.

Addressing that tension was the core reason we made this change. We are almost 3 years past this decision ( https://discord.com/blog/usernames ) and I personally think this change was a positive one.

The stated reason is obviously not able to justify the change; either they have an internal reason they're not willing to admit to, or someone at Discord just went crazy.

Imagine trying to connect with your friends... by telephone.

Potential reasons I can think of for why they don't disallow name reuse:

a) AWS will need to maintain a database of all historical bucket names to know what to disallow. This is hard per region and even harder globally. Its easier to know what is currently in use rather know what has been used historically.

b) Even if they maintained a database of all historically used bucket names, then the latency to query if something exists in it may be large enough to be annoying during bucket creation process. Knowing AWS, they'll charge you for every 1000 requests for "checking if bucket name exists" :p

c) AWS builds many of its own services on S3 (as indicated in the article) and I can imagine there may be many of their internal services that just rely on existing behaviour i.e. allowing for re-creating the same bucket name.

I'd allow re-use, but only by the original account. Not being able to re-create a bucket after deleting it would be annoying.

I think that's an important defense that AWS should implement for existing buckets, to complement account scoped bucket.

Any workload that relies on re-using a bucket name is broken by design. If someone else can get it, then it's Undefined Behaviour. So it's in keeping with the contract for AWS to prevent re-use. Surely?

Ok; salt, and then hash your bucket names

I wonder if it's related to the fact that Windows as such weird rules about allowed file names. Like not directly obviously, more like culturally inside microsoft.

It was honestly a downgrade i ended up just putting the 4 digits I had before at the end of my username cause surprise the name was taken immediately

Ah you're right, they are always wildcard certs. I think I was mis-remembering https://news.ycombinator.com/item?id=15826906, which guesses names based on CT logs.

In either case, the subdomain you use in DNS requests are not private. Attackers can collect those from passive DNS logs or in other ways.

I can't accept a) or b). They already need to keep a database of all existing bucket names globally, and they already need to check this on bucket creation. Adding a flag on deleted doesn't seem like a big loss.

As for c), I assume it's not just AWS relying on this behaviour. https://xkcd.com/1172/

Then they should allow bucket ownership transfer...

Think terraform tests, temporary environments, etc. Or anything else: it’s Hyrum's Law.

I’m pretty sure Azure was built out with Hyper-V, which was built into the Windows kernel. So everything that relied on virtualization would’ve had bizarre case insensitivity and naming rules.

I’ve lost track of servers in Azure because the name suddenly changed to all uppercase ave their search is case sensitive but whatever back-end isn’t.

I would not dismiss something like that directly being the cause. Not the reason you can't name a file "CON" on Windows, but it's very likely some weird ass thing they were stringing together with Windows Server and Hyper-V and SMB backed them into the corner we're all in now

that doesn't help either. 'Salt' is public and usually different/unique per entry/name.

If you mean to use a "secret" prefix (i.e. pepper) then, that would generate effectively globally unique names each time (and unpredictable too) but you can't change the pepper and it's only a matter of time it'd leak.

But you already have a domain for whatever you're doing so presumably that's going to be a threat either way.

For particularly high risk activities if circumstances permit you can sidestep the entire issue by adding a layer of verification using a preshared public key. As an arbitrary example, on android installing an app with the same name but different signing key won't work. It essentially implements a TOFU model to verify the developer.

Random pepper. Or just, y'know, randomly generate the effing string. Can't be that hard.

If they can't make the bucket before you do then they are not "bucket squatting", and they can't do so for a salted and hashed bucket name without knowing the salt at runtime.

The public/private distinction seems moot here, too: the salt is a throwaway since you just need the bucket name.

Even if you do need to keep track of the salt, it should be safe for the attacker to know, at least with respect to this attack, because you already own the bucket which the attacker would otherwise hoard.

> No man-in-the-middle is needed [...] Check out passive DNS

How does one execute this "passive DNS" without quite literally being on the receiving end, or at least sitting in-between the sending and receiving end? You're quite literally describing what I'm saying, which makes it less of a "leak" and more like "others might collect your data, even your ISP", which I'd say would be accurate than "your DNS leaks".

> I wonder if they'll delete my account eventually

Just some days ago I received warning from Discord that they'll delete my account since I haven't logged in for two years.

> Your Discord account has been inactive for over 2 years, and is scheduled to be deleted on $DATE. But don’t worry! Dust off the cobwebs and prevent your account from being deleted just by logging in.

Your account has almost certainly been assigned a new username already. From the same link:

> Starting March 4, 2024, Discord will begin assigning new usernames to users who have not chosen one themselves. If your username still has a discriminator (username*#0000*), Discord will begin assigning you a new, unique username as soon as March 4, 2024. We will try to assign you a unique username that is similar to your current username.

There's a lot of online documentation about passive DNS. Here's one example

> Passive DNS is a historical database of how domains have resolved to IP addresses over time, collected from recursive DNS servers around the world. It has been an industry-standard tool for more than a decade.

> Spamhaus’ Passive DNS cluster handles more than 200 million DNS records per hour and stores hundreds of billions of records per month, providing you with access to a vast lake of threat intelligence data.

https://www.spamhaus.com/resource-center/what-is-passive-dns...

> collected from recursive DNS servers around the world

Yes, of course, because those DNS servers are literally receiving the queries, eg "receiving the data".

Again, there is nothing "leaking" here, that's like saying you leak what HTTP path you're requesting to a server, when you're sending a HTTP request to that server. Of course, that's how the protocol works!