Speaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware).
Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion.
This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user!
AWS support was rather terrible in providing help.
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.
Amazons assistance for account issues to organizations if an employee did anything individually is honestly horrible.
They treat it like the organization is attempting to commandeer someone else's account so all the privacy protections you expect for your own stuff is applied no matter how much you can prove it is not some other individuals account.
The best part is the billing issues that arise from that. In your example, if the previous engineer logged into that account (because they can) and racked up huge costs, assuming that account is getting billed or can be tied to your client, Amazon will demand your client pay for them, while at the same time refusing to assist in getting access to the account because it's someone else's. They hold you responsible, but unable to act in a responsible manner.
While true, the engineer would have to be a weapons grade tit to get themself in such legal trouble, and honestly deserves whatever criminal charges comes their way.
Is this something where you could pay a "consulting fee" to the previous key engineer to login and remove the MFA?
I know that that's not ideal, but as a practical matter perhaps it would be easier than creating a new account, if you can get the engineer to agree to it?
That's not an equivalent analogy. A better analogy would be to say I had a bank account and I told my bank to call up Joe on the phone when confirmations were needed. I still have the account, but I have fallen out with Joe. I want the bank to call somebody else, but they refused to do so, even though it's my account and I'm paying the bill for it!
Banks have established processes for changing signatories on business bank accounts, including in situations where a past signatory is no longer with the business.
In a nutshell: if a past signatory was a regular employee, it just takes any other signatory to remove them. If there was no other signatory, or if the past signatory was an officer, it takes a current officer (as set forth in the company's AOI or corporate minutes). Usually only the latter 2 situations of the 3 above require an in-person visit to the local branch office, and that only requires a few minutes.
I won't attempt to defend AWS here, but if any company has such incompetent IT management as to allow an individual employee to have that level of control then they kind of deserve what they get. Life is hard when you're stupid.
I don't really understand that problem, exactly. I'm not aware of any restrictions for using AWS Identity Center (SSO) with an email address that happens to be a root email for another AWS account.
I checked the documentation but I couldn't find anything to show this to be a problem other than that the practice is discouraged.
I create "job function" DLs. "Company-Region-IT Manager". Then give that DL it's own SMTP address. Then use that.
It's really nice when you have to hire someone new for the position. You add them to the DL and they're automatically in control of all those accounts.
Or you don't have employees using their personal email to open corporate accounts.
Still on Amazon to clearly tell people it is this way so they can properly plan for it, but employee's email addresses really shouldn't be used for the root account.
That’s not what’s being described here. What OP described is the much more common situation where employees use a personal phone for MFA. Sure, some places issue hardware dongles and disallow authenticator apps on your personal phone, but IME most places default to just having people use their phone.
You should not have the root account be a human anyway. Make that a special account, secure the credentials and only ever use them when you screw something up really badly.
I would expect the SSO configuration to map the IdP's given email into a role appropriate for the identity. What does "forever attached to the deleted AWS account root user" mean here? What is the mechanism blocking use?
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.
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.
If user foo@gmail.com violates our ToS and I suspend them, I can keep that email address forever to keep them from signing up again. They can’t just say “GDPR! You have to forget me, tee-hee!”
You can't derive the original better than guessing. With public identifiers you can just take a list of them and guess with those. If someone asks for your email they can hash it themselves and compare it against whatever databases.
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.
>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
It's such a common case, especially in tech with startups and small software companies getting gobbled up all the time I can't see how you WOULDN'T consider it a possible reason
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.
Yes. There are solutions to all of these issues, but what often happens is these situations come about through the natural course of companies changing over time - different people managing accounts, different providers, etc. The happy path is easy, but the happy path is rarely the one we find ourselves walking down when we inherit a previously made decision.
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.
And in this case, it’s actually less secure for this one user and the account if as a workaround I’m required to create an IAM user for them (even though I can limit their use of the system).
> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.
The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.
A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.
I hope Microsoft follows suit and introduces a unique namespace per customer as well.
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.
AWS has a privileged position compared to other deprecation struggles in the industry, though. They can price the v2 version aggressively/at a loss to incentivize migration without major bottom line impact.
And sure, v1 is forever, but between getting to the point where new accounts can’t use it without a special request (or grandfathered in sweetheart rates, though that might be a PR disaster) and incentivizing migration off for existing users could absolutely get s3v1 to the point where it could be staffed for maintenance mode rather than staffed as a flagship feature.
It’d take years, but is totally possible. Amazon knows this. If they’re not doing it, it’s because the costs don’t make sense for them.
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.
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.
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.
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.
Isn't case insensitivity a Win32 thing only? I would not expect it to impact stuff in Hyper-V or the windows kernel. AFAIK for example NTFS is case-sensitive.
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
> 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.
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names.
This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
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.
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.
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.
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.
> 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.
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.
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?
Having worked in this space for years, it's not nearly as bad as you think. IaC tools can all look up the accountId/region for the current execution context and you can use SSM Parameters to give you a helpful alias in your code.
Also, if you have a bunch of accounts, it's far easier for troubleshooting that the accountId is in the name: "I can't access bucket 'foo'" vs. "I can't access bucket 'foo-12345678901'"
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 requirement for unique user names is a little strange, I was putting together a small internal tool recently and after a bit of thought decided to use an opaque internal id for users and let the users pick and change their name and secret at will.
I think for a larger public service it would make sense to expose some sort of internal id(or hash of it. What bob am I talking to?. but people share the same name all the time it is strange that we can't in our online communities.
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.
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.
Why is x-amz-bucket-namespace header needed when creating a new bucket in the account regional namespace? Is an account blocked from creating a bucket in its own namespace if it doesn't specify that header?
Thank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1].
I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation.
The _really_ fun bucket squatting attacks are when the cloud providers themselves use deterministic names for "scratch space" buckets. There was a good DC talk about it at DC32 for AWS, although actual squatting was tough because there was a hash they researchers couldn't reverse (but was consistent for a given account?): https://www.youtube.com/watch?v=m9QVfYVJ7R8
Once they are not renewed, they eventually become available again. Then anyone can re-register them, set up an MX record, and start receiving any emails still being sent to recipients in that domain. This could include password reset authentications for other services, etc.
A name shouldn't be the same as the thing it names.
When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
If you ever produce and share a signed link for e.g. S3, this link contains your access key ID in it. Turns out you can just slice and decode your Account ID out of that access key, it's in there in base32:
It is not hygienic, but with only the account-id you are fine. In the IAM rules the attacker can always just use a * on their end, so it does not make a difference. You have to be conscious to set proper rules for your (owner) end tho.
Once again AWS waits an inexplicably long time to fix an obvious deficiency that the other providers solved long ago, and then does it in an inexplicably hacky way.
See also their recent innovation of letting you be logged into the console with up to five (???) of the many accounts their bizarre IAM system requires, implemented with a clunky system of redirections and magic URL prefixes. As opposed to GCP just having a sensible system in the first place of projects with permissions, and letting you switch between any of them at will using the same user account.
I think I'm not getting it. What's the problem if someone else can claim that bucket name? If it's deleted wouldn't the data be deleted too? Or is it there something I'm missing.
I think you can put malicious data in the bucket and „impersonate“ the deleted bucket, so old code referencing the bucket uses your data instead of throwing an error (?).
> If you wish to protect your existing buckets, you’ll need to create new buckets with the namespace pattern and migrate your data to those buckets.
My pet conspiracy theory: this article was written by bucket squatters who want to claim old bucket names after AI agents read this and blindly follow.
I started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info.
~As far as I know, bucket names are public via certificate transparency logs.~ There are tools for collecting those names. Besides you'd leak the subdomain to (typically) unencrypted DNS when you do a lookup and maybe via SNI.
> Besides you'd leak the subdomain to (typically) unencrypted DNS when you do a lookup and maybe via SNI.
"Leak" is maybe a bit over-exaggerated, although if someone MitM'd you they definitely be able to see it. But "leak" makes it seem like it's broadcasted somehow, which obviously it isn't.
You'd need to check the privacy policy of your DNS provider to know if they share the data with anyone else. I've commonly seen source IP address consider as PII, but not the content of the query. Cloudflare's DNS, for example, shares queries with APNIC for research purposes. https://developers.cloudflare.com/1.1.1.1/privacy/public-dns... Other providers share much more broadly.
> 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".
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.
> 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!
Putting a secret subdomain in a DNS query shares it with the recursive resolver, who's privacy policy may permit them to share it with others. This is a common practice and attackers have access to the aggregated datasets. You are correct that third-party web servers or CDN could share your HTTP path, but I am not aware of any examples and most privacy policies should prohibit them from doing so. If your web server provider or CDN do this, change providers. DNS recursive resolvers are chosen client side, so you can't always choose which one handles the query. Even privacy-focused DNS recursive resolvers share anonymized query data. They remove the source IP address, since it's PII, but still "leak" the secret subdomain.
Any time you send secret data such that it travels to an attacker visible dataset it is vulnerable to attack. I call that a leak but we can use a different term.
I just started using hashes for names. The deployment tooling knows the "real" name. The actual deployment hash registers a salt+hash of that name to produce a pseudo-random string name.
This is all good and we'll on the IaC side,yes. But at the end of the day, buckets are also user facing resources, and nobody likes random directory / bucket names.
That's a contradiction, a bucket name being treated as a secret in IaC, while being a user facing resource. So no, they're not user facing resources.
If anyone wants them to be user facing resources, then treat them as such, and ensure they're secure, and don't store sensitive info on them. Otherwise, put a service infront of them, and have the user go through it.
The S3 protocol was meant to make the lives of programmers easier, not end users.
It would be nice if the other end of this could be addressed: a configurable policy to limit resolution of bucket names within an account namespace. Ideally, if someone doesn’t have permission to resolve a bucket name, they shouldn’t even be able to detect whether it exists.
Good riddance. The number of production deploys I've seen pointing at bucket names that could've been claimed by anyone was wild. Glad this is finally getting closed off at the platform level instead of relying on everyone to not make the mistake.
There are other mitigations though: You can pass expected owner accountId on S3 operations and you can create SCPs that restrict the ability of roles to write to buckets outside the account. Unless you have an account that does many cross-account S3 writes, the latter is a simple tool to prevent exfiltration. Well, simple assuming that you're already set up with an Organization and can manage SCPs.
If you block name reuse globally, you introduce a new attack surface: permanent denial by squatting on retired names. Companies mess up names all the time from typos, failed rollouts, or legal issues. A one-shot policy locks everyone into their worst error or creates a regulatory mess over who can undo registrations.
Namespaces are annoying but at least let you reorganize or fix mistakes. If you want to prevent squatting, rate limiting creation and deletion or using a quarantine window is more practical. No recovery path just rewards trolls and messes with anyone whose processes aren't perfect.
That would be a huge breaking change. Any workload that relies on re-using a bucket name would be broken, and at the scale of S3 that would have a non-trivial customer impact.
Not to mention the ergonomics would suck - suddenly your terraform destroy/apply loop breaks if there’s a bucket involved
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?
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 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.
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.
this seems nice but it's a little annoying if you've been using terraform's `bucket_prefix` to create buckets. i wonder if/when they'll update that or if they'll add a new bucket_name argument that uses the new namespacing.
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?
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.
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.
The "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction.
1. You set up an aws bucket with some name (any name whatsoever).
2. You have code that reads and/or writes data to the bucket.
3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.
4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.
5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.
You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.
Speaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware).
Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion.
This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user!
AWS support was rather terrible in providing help.
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.
Amazons assistance for account issues to organizations if an employee did anything individually is honestly horrible.
They treat it like the organization is attempting to commandeer someone else's account so all the privacy protections you expect for your own stuff is applied no matter how much you can prove it is not some other individuals account.
The best part is the billing issues that arise from that. In your example, if the previous engineer logged into that account (because they can) and racked up huge costs, assuming that account is getting billed or can be tied to your client, Amazon will demand your client pay for them, while at the same time refusing to assist in getting access to the account because it's someone else's. They hold you responsible, but unable to act in a responsible manner.
While true, the engineer would have to be a weapons grade tit to get themself in such legal trouble, and honestly deserves whatever criminal charges comes their way.
Is this something where you could pay a "consulting fee" to the previous key engineer to login and remove the MFA?
I know that that's not ideal, but as a practical matter perhaps it would be easier than creating a new account, if you can get the engineer to agree to it?
This is why you either issue corporate phones or key dongles.
I named random Joe as the sole owner of "my" bank account and the bank wouldn't allow me to access "my" money!
That's not an equivalent analogy. A better analogy would be to say I had a bank account and I told my bank to call up Joe on the phone when confirmations were needed. I still have the account, but I have fallen out with Joe. I want the bank to call somebody else, but they refused to do so, even though it's my account and I'm paying the bill for it!
And we're paying extra for support!
Banks have established processes for changing signatories on business bank accounts, including in situations where a past signatory is no longer with the business.
In a nutshell: if a past signatory was a regular employee, it just takes any other signatory to remove them. If there was no other signatory, or if the past signatory was an officer, it takes a current officer (as set forth in the company's AOI or corporate minutes). Usually only the latter 2 situations of the 3 above require an in-person visit to the local branch office, and that only requires a few minutes.
What happens when someone loses their phone?
You print the MFA QR code, and give it to an executive that locks it up in a safe or offsite storage.
In a past life, we printed the MFA QR code and the head of finance put it into a safe.
I won't attempt to defend AWS here, but if any company has such incompetent IT management as to allow an individual employee to have that level of control then they kind of deserve what they get. Life is hard when you're stupid.
This is why you never use personal phones for MFA to critical accounts.
You can always use plus-addressing if your email provider supports that. AWS considers plus-addressed root emails to be unique.
Doesn’t solve the SSO issue though unless you change your login email
I don't really understand that problem, exactly. I'm not aware of any restrictions for using AWS Identity Center (SSO) with an email address that happens to be a root email for another AWS account.
I checked the documentation but I couldn't find anything to show this to be a problem other than that the practice is discouraged.
I create "job function" DLs. "Company-Region-IT Manager". Then give that DL it's own SMTP address. Then use that.
It's really nice when you have to hire someone new for the position. You add them to the DL and they're automatically in control of all those accounts.
I have no idea why more companies don't do this.
Or you don't have employees using their personal email to open corporate accounts.
Still on Amazon to clearly tell people it is this way so they can properly plan for it, but employee's email addresses really shouldn't be used for the root account.
That’s not what’s being described here. What OP described is the much more common situation where employees use a personal phone for MFA. Sure, some places issue hardware dongles and disallow authenticator apps on your personal phone, but IME most places default to just having people use their phone.
You should not have the root account be a human anyway. Make that a special account, secure the credentials and only ever use them when you screw something up really badly.
I would expect the SSO configuration to map the IdP's given email into a role appropriate for the identity. What does "forever attached to the deleted AWS account root user" mean here? What is the mechanism blocking use?
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.
I thought it worked the other way, you can have multiple accounts with the same username as long as they have different passwords
IAM users get usernames - they don’t log in with an email address. Root users log in with their email address.
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.
If user foo@gmail.com violates our ToS and I suspend them, I can keep that email address forever to keep them from signing up again. They can’t just say “GDPR! You have to forget me, tee-hee!”
This can be implemented without storing it. They could store a hash. No idea what they actually do.
A hash of a public identifier like an email is personally identifiable data.
Isn’t the entire point of a cryptographically secure hash that you can’t derive the original information?
You can't derive the original better than guessing. With public identifiers you can just take a list of them and guess with those. If someone asks for your email they can hash it themselves and compare it against whatever databases.
You can always encrypt with a public key instead of hashing.
GDPR says you are not allowed to store my data just because. If you have a good enough reason, everything is allowed.
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.
>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
In our case, this is exactly what happened. An acquisition of a company where their AWS accounts that were inherited were no longer needed.
It's such a common case, especially in tech with startups and small software companies getting gobbled up all the time I can't see how you WOULDN'T consider it a possible reason
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.
> 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.
Sure they can. Use any other email address at domain.com to register.
Yes. There are solutions to all of these issues, but what often happens is these situations come about through the natural course of companies changing over time - different people managing accounts, different providers, etc. The happy path is easy, but the happy path is rarely the one we find ourselves walking down when we inherit a previously made decision.
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.
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.
what if you stopped using AWS for a while, then came 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.
And in this case, it’s actually less secure for this one user and the account if as a workaround I’m required to create an IAM user for them (even though I can limit their use of the system).
> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.
The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.
A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.
I hope Microsoft follows suit and introduces a unique namespace per customer as well.
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.
V1 never dies. You support it forever, including for customers who desperately want v2-only features but would rather escalate than migrate.
AWS has a privileged position compared to other deprecation struggles in the industry, though. They can price the v2 version aggressively/at a loss to incentivize migration without major bottom line impact.
And sure, v1 is forever, but between getting to the point where new accounts can’t use it without a special request (or grandfathered in sweetheart rates, though that might be a PR disaster) and incentivizing migration off for existing users could absolutely get s3v1 to the point where it could be staffed for maintenance mode rather than staffed as a flagship feature.
It’d take years, but is totally possible. Amazon knows this. If they’re not doing it, it’s because the costs don’t make sense for them.
Laughs in CodeCommit and S3 Select
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.
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.
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.
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.
Isn't case insensitivity a Win32 thing only? I would not expect it to impact stuff in Hyper-V or the windows kernel. AFAIK for example NTFS is case-sensitive.
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
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.
Use 1 for your separator.
You also can't even have hyphens in the storage account name. It's a complete shit show tbh. Same with container registries and other resources.
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names.
This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
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...
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.
(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.
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
I haven't logged in since . I wonder if they'll delete my account eventually - as I essentially don't have a username because of that
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.
> 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.
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.
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?
Having worked in this space for years, it's not nearly as bad as you think. IaC tools can all look up the accountId/region for the current execution context and you can use SSM Parameters to give you a helpful alias in your code.
Also, if you have a bunch of accounts, it's far easier for troubleshooting that the accountId is in the name: "I can't access bucket 'foo'" vs. "I can't access bucket 'foo-12345678901'"
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 requirement for unique user names is a little strange, I was putting together a small internal tool recently and after a bit of thought decided to use an opaque internal id for users and let the users pick and change their name and secret at will.
I think for a larger public service it would make sense to expose some sort of internal id(or hash of it. What bob am I talking to?. but people share the same name all the time it is strange that we can't in our online communities.
I just want to be able to use a verified domain; @example.com everywhere.
That still has "squatting" risks as described in the original article though, domains expire and / or can be taken over.
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.
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.
I didn’t think it was possible to have a personal TLD - did you mean a personal domain?
Well, I guess it's possible now to have a personal TLD, but yes, I meant domain.
Why is x-amz-bucket-namespace header needed when creating a new bucket in the account regional namespace? Is an account blocked from creating a bucket in its own namespace if it doesn't specify that header?
Thank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1].
I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation.
[1] https://aws.amazon.com/blogs/aws/introducing-account-regiona...
The _really_ fun bucket squatting attacks are when the cloud providers themselves use deterministic names for "scratch space" buckets. There was a good DC talk about it at DC32 for AWS, although actual squatting was tough because there was a hash they researchers couldn't reverse (but was consistent for a given account?): https://www.youtube.com/watch?v=m9QVfYVJ7R8
GCP, however, has does this to itself multiple times because they rely so heavily on project-id, most recently just this February: https://www.sentinelone.com/vulnerability-database/cve-2026-...
DNS names have the same problem.
Once they are not renewed, they eventually become available again. Then anyone can re-register them, set up an MX record, and start receiving any emails still being sent to recipients in that domain. This could include password reset authentications for other services, etc.
AWS buckets still offer special features if and only if the name of the bucket matches your hostname.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Virtua...
A name shouldn't be the same as the thing it names.
When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
decision to make bucket (and not bucket + account id surrogate) a sole key for access was one of most annoying mistakes in S3 design
I take it advertising your account id isn't a security risk?
AWS does not consider it one.
“While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.” https://docs.aws.amazon.com/accounts/latest/reference/manage...
Armchair opinion, but shouldn't be too bad - it's identification, not authentication, just like your e-mail address is.
But probably best to not advertise it too much.
If you ever produce and share a signed link for e.g. S3, this link contains your access key ID in it. Turns out you can just slice and decode your Account ID out of that access key, it's in there in base32:
https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f...
It is not hygienic, but with only the account-id you are fine. In the IAM rules the attacker can always just use a * on their end, so it does not make a difference. You have to be conscious to set proper rules for your (owner) end tho.
That took a decade to resolve? Surprising, but hindsight is 20/20 I guess.
Two. S3 has been around since 2006!
While I understand where it's coming from I always had something like <bucket_tag>-<9_random_\d\w>
Once again AWS waits an inexplicably long time to fix an obvious deficiency that the other providers solved long ago, and then does it in an inexplicably hacky way.
See also their recent innovation of letting you be logged into the console with up to five (???) of the many accounts their bizarre IAM system requires, implemented with a clunky system of redirections and magic URL prefixes. As opposed to GCP just having a sensible system in the first place of projects with permissions, and letting you switch between any of them at will using the same user account.
Good solution. Thanks for popularizing it.
* Backwards compatible
* Keeps readability
* Solves problem
I think I'm not getting it. What's the problem if someone else can claim that bucket name? If it's deleted wouldn't the data be deleted too? Or is it there something I'm missing.
I think you can put malicious data in the bucket and „impersonate“ the deleted bucket, so old code referencing the bucket uses your data instead of throwing an error (?).
Or old code referencing the bucket _writes_ data to it, and the attacker can now read it.
https://www.aquasec.com/blog/bucket-monopoly-breaching-aws-a...
> If you wish to protect your existing buckets, you’ll need to create new buckets with the namespace pattern and migrate your data to those buckets.
My pet conspiracy theory: this article was written by bucket squatters who want to claim old bucket names after AI agents read this and blindly follow.
Why the hell is this a name suffix instead of just using subdomains?
myapp-123456789012-us-west-2-an
vs myapp.123456789012.us-west-2.s3.amazonaws.com
The manipulations I will need to do to fit into the 63 char limit will be atrocious.
I would guess that it can add one more DNS lookup?
I started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info.
This is where IaC shines.
~As far as I know, bucket names are public via certificate transparency logs.~ There are tools for collecting those names. Besides you'd leak the subdomain to (typically) unencrypted DNS when you do a lookup and maybe via SNI.
Edit: crossout incorrect info
I'm pretty sure buckets use star certs and thus the individual bucket names won't be in the transparency logs.
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.
> Besides you'd leak the subdomain to (typically) unencrypted DNS when you do a lookup and maybe via SNI.
"Leak" is maybe a bit over-exaggerated, although if someone MitM'd you they definitely be able to see it. But "leak" makes it seem like it's broadcasted somehow, which obviously it isn't.
No man-in-the-middle is needed, DNS queries are often collected into large datasets which can be analyzed by threat hunters or attackers. Check out passive DNS https://www.spamhaus.com/resource-center/what-is-passive-dns...
You'd need to check the privacy policy of your DNS provider to know if they share the data with anyone else. I've commonly seen source IP address consider as PII, but not the content of the query. Cloudflare's DNS, for example, shares queries with APNIC for research purposes. https://developers.cloudflare.com/1.1.1.1/privacy/public-dns... Other providers share much more broadly.
> 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".
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!
I think you are hung up on the word "leak".
Putting a secret subdomain in a DNS query shares it with the recursive resolver, who's privacy policy may permit them to share it with others. This is a common practice and attackers have access to the aggregated datasets. You are correct that third-party web servers or CDN could share your HTTP path, but I am not aware of any examples and most privacy policies should prohibit them from doing so. If your web server provider or CDN do this, change providers. DNS recursive resolvers are chosen client side, so you can't always choose which one handles the query. Even privacy-focused DNS recursive resolvers share anonymized query data. They remove the source IP address, since it's PII, but still "leak" the secret subdomain.
Any time you send secret data such that it travels to an attacker visible dataset it is vulnerable to attack. I call that a leak but we can use a different term.
> I think you are hung up on the word "leak".
What gave you that idea? Maybe because my initial comment started with:
> "Leak" is maybe a bit over-exaggerated...
And continues with about why I think so?
I raised this sub-thread specifically because I got hung up on "leak", that's entire point of the conversation in my mind.
So nothing to do with your DNS queries at all? Why did you bring it up?
I just started using hashes for names. The deployment tooling knows the "real" name. The actual deployment hash registers a salt+hash of that name to produce a pseudo-random string name.
This is all good and we'll on the IaC side,yes. But at the end of the day, buckets are also user facing resources, and nobody likes random directory / bucket names.
That's a contradiction, a bucket name being treated as a secret in IaC, while being a user facing resource. So no, they're not user facing resources.
If anyone wants them to be user facing resources, then treat them as such, and ensure they're secure, and don't store sensitive info on them. Otherwise, put a service infront of them, and have the user go through it.
The S3 protocol was meant to make the lives of programmers easier, not end users.
It would be nice if the other end of this could be addressed: a configurable policy to limit resolution of bucket names within an account namespace. Ideally, if someone doesn’t have permission to resolve a bucket name, they shouldn’t even be able to detect whether it exists.
Good riddance. The number of production deploys I've seen pointing at bucket names that could've been claimed by anyone was wild. Glad this is finally getting closed off at the platform level instead of relying on everyone to not make the mistake.
There are other mitigations though: You can pass expected owner accountId on S3 operations and you can create SCPs that restrict the ability of roles to write to buckets outside the account. Unless you have an account that does many cross-account S3 writes, the latter is a simple tool to prevent exfiltration. Well, simple assuming that you're already set up with an Organization and can manage SCPs.
[0] https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket...
Does it still take like an hour to rename one?
I hope nobody wanted "ecommerce-admin". sorry
Why all that stuff with namespaces when they could just not allow name reuse?
If you block name reuse globally, you introduce a new attack surface: permanent denial by squatting on retired names. Companies mess up names all the time from typos, failed rollouts, or legal issues. A one-shot policy locks everyone into their worst error or creates a regulatory mess over who can undo registrations.
Namespaces are annoying but at least let you reorganize or fix mistakes. If you want to prevent squatting, rate limiting creation and deletion or using a quarantine window is more practical. No recovery path just rewards trolls and messes with anyone whose processes aren't perfect.
That would be a huge breaking change. Any workload that relies on re-using a bucket name would be broken, and at the scale of S3 that would have a non-trivial customer impact.
Not to mention the ergonomics would suck - suddenly your terraform destroy/apply loop breaks if there’s a bucket involved
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?
Think terraform tests, temporary environments, etc. Or anything else: it’s Hyrum's Law.
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 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/
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.
Then they should allow bucket ownership transfer...
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.
So no bucket sharing across accounts?
I mean, why isn't this just the mandatory default going forward? Globally shared, unique bucket names always struck me as a horrible idea.
this seems nice but it's a little annoying if you've been using terraform's `bucket_prefix` to create buckets. i wonder if/when they'll update that or if they'll add a new bucket_name argument that uses the new namespacing.
Huh? Hash your bucket names
if your bucket name is ever exposed and you later delete it, then this doesn't help you.
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?
I don't think that'd prevent this attack vector.
Ok; salt, and then hash your bucket names
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.
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.
The "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction.
1. You set up an aws bucket with some name (any name whatsoever).
2. You have code that reads and/or writes data to the bucket.
3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.
4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.
5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.
You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.