[HN Gopher] Bucketsquatting is finally dead
___________________________________________________________________
Bucketsquatting is finally dead
Author : boyter
Score : 294 points
Date : 2026-03-13 08:31 UTC (14 hours ago)
(HTM) web link (onecloudplease.com)
(TXT) w3m dump (onecloudplease.com)
| lijok wrote:
| Huh? Hash your bucket names
| Maxion wrote:
| I don't think that'd prevent this attack vector.
| alemwjsl wrote:
| Ok; salt, and then hash your bucket names
| xxs wrote:
| 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.
| lcnPylGDnU4H9OF wrote:
| 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.
| ethanrutherford wrote:
| 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.
| tosti wrote:
| Random pepper. Or just, y'know, randomly generate the
| effing string. Can't be that hard.
| why_only_15 wrote:
| if your bucket name is ever exposed and you later delete it,
| then this doesn't help you.
| lijok wrote:
| 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?
| calmworm wrote:
| That took a decade to resolve? Surprising, but hindsight is 20/20
| I guess.
| icedchai wrote:
| Two. S3 has been around since 2006!
| thih9 wrote:
| > 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.
| vhab wrote:
| > 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.
| ryanjshaw wrote:
| 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.
| mwalser wrote:
| 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.
| xmcqdpt2 wrote:
| 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.
| throwaway173738 wrote:
| 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.
| kg wrote:
| 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.
| mixdup wrote:
| 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
| iann0036 wrote:
| Author here. Thanks for the call out! I've updated the article
| with attribution.
| mirashii wrote:
| > 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.
| NetMageSCW wrote:
| Use 1 for your separator.
| Twirrim wrote:
| 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.
| shermantanktop wrote:
| V1 never dies. You support it forever, including for
| customers who desperately want v2-only features but would
| rather escalate than migrate.
| zbentley wrote:
| 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.
| coredog64 wrote:
| _Laughs in CodeCommit and S3 Select_
| Rapzid wrote:
| 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.
| Aardwolf wrote:
| Why all that stuff with namespaces when they could just not allow
| name reuse?
| CodesInChaos wrote:
| 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.
| wiether wrote:
| Then they should allow bucket ownership transfer...
| iknownothow wrote:
| 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.
| dwedge wrote:
| 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/
| orf wrote:
| 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
| afandian wrote:
| 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?
| orf wrote:
| Think terraform tests, temporary environments, etc. Or
| anything else: it's Hyrum's Law.
| hrmtst93837 wrote:
| 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.
| JoBrad wrote:
| 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.
| NetMageSCW wrote:
| So no bucket sharing across accounts?
| INTPenis wrote:
| 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.
| XorNot wrote:
| 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.
| Galanwe wrote:
| 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.
| amluto wrote:
| 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.
| INTPenis wrote:
| 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.
| 8organicbits wrote:
| ~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
| BCM43 wrote:
| I'm pretty sure buckets use star certs and thus the
| individual bucket names won't be in the transparency logs.
| 8organicbits wrote:
| 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.
| embedding-shape wrote:
| > 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.
| 8organicbits wrote:
| 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.
| embedding-shape wrote:
| > 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".
| 8organicbits wrote:
| 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...
| embedding-shape wrote:
| > 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!
| 8organicbits wrote:
| 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.
| embedding-shape wrote:
| > 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.
| NetMageSCW wrote:
| So nothing to do with your DNS queries at all? Why did
| you bring it up?
| iknownothow wrote:
| 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...
| alemwjsl wrote:
| I take it advertising your account id isn't a security risk?
| aduwah wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| otterley wrote:
| 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...
| thenickdude wrote:
| 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...
| josephg wrote:
| 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.
| donmcronald wrote:
| I just want to be able to use a verified domain; @example.com
| everywhere.
| Cthulhu_ wrote:
| That still has "squatting" risks as described in the original
| article though, domains expire and / or can be taken over.
| fc417fc802 wrote:
| 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.
| rithdmc wrote:
| 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.
| jorams wrote:
| 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...
| juliangmp wrote:
| 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
| ffsm8 wrote:
| 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
| embedding-shape wrote:
| > 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.
| jorams wrote:
| 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.
| thaumasiotes wrote:
| 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.
| shadowfiend wrote:
| 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.
| slashink wrote:
| (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.
| fc417fc802 wrote:
| 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?
| coredog64 wrote:
| 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'"
| brnt wrote:
| 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.
| NetMageSCW wrote:
| I didn't think it was possible to have a personal TLD - did
| you mean a personal domain?
| brnt wrote:
| Well, I guess it's possible now to have a personal TLD, but
| yes, I meant domain.
| jorams wrote:
| Small correction: .nl is a ccTLD, or country code TLD. Not a
| gTLD, or generic TLD.
| somat wrote:
| 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.
| ClaudeFixer wrote:
| 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.
| coredog64 wrote:
| 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...
| bulbar wrote:
| 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.
| etothet wrote:
| 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.
| jakobobobo wrote:
| 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.
| nawgz wrote:
| 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.
| dec0dedab0de wrote:
| what if you stopped using AWS for a while, then came back?
| clickety_clack wrote:
| 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.
| etothet wrote:
| 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.
| zenoprax wrote:
| > 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.
| otterley wrote:
| Sure they can. Use any other email address at domain.com to
| register.
| etothet wrote:
| 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.
| naasking wrote:
| > 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.
| etothet wrote:
| 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).
| mixdup wrote:
| >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
| etothet wrote:
| In our case, this is exactly what happened. An acquisition
| of a company where their AWS accounts that were inherited
| were no longer needed.
| mixdup wrote:
| 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
| twentyfiveoh1 wrote:
| 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.
| noahmasur wrote:
| You can always use plus-addressing if your email provider
| supports that. AWS considers plus-addressed root emails to be
| unique.
| hallway_monitor wrote:
| Doesn't solve the SSO issue though unless you change your
| login email
| noahmasur wrote:
| 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.
| mhurron wrote:
| 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.
| ksenzee wrote:
| 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.
| themafia wrote:
| 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.
| a2tech wrote:
| 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.
| kevin_thibedeau wrote:
| This is why you either issue corporate phones or key dongles.
| nightpool wrote:
| when your startup is three employees and only one
| technical? this person created their AWS root account, I
| think it's fair to assume that he's their first engineer
| and probably first employee
| NetMageSCW wrote:
| What happens when someone loses their phone?
| zikduruqe wrote:
| 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.
| UltraSane wrote:
| This is why you never use personal phones for MFA to critical
| accounts.
| mhurron wrote:
| 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.
| cyberpunk wrote:
| 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.
| dixie_land wrote:
| I named random Joe as the sole owner of "my" bank account and
| the bank wouldn't allow me to access "my" money!
| mcherm wrote:
| 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!
| a2tech wrote:
| And we're paying extra for support!
| gamblor956 wrote:
| 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.
| senkora wrote:
| 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?
| nradov wrote:
| 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.
| shmolyneaux wrote:
| 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.
| kstrauser wrote:
| 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!"
| arielweisberg wrote:
| This can be implemented without storing it. They could store
| a hash. No idea what they actually do.
| charcircuit wrote:
| A hash of a public identifier like an email is personally
| identifiable data.
| pfortuny wrote:
| You can always encrypt with a public key instead of
| hashing.
| jounker wrote:
| Isn't the entire point of a cryptographically secure hash
| that you can't derive the original information?
| charcircuit wrote:
| 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.
| silversmith wrote:
| GDPR says you are not allowed to store my data just because.
| If you have a good enough reason, everything is allowed.
| gnopgnip wrote:
| I thought it worked the other way, you can have multiple
| accounts with the same username as long as they have different
| passwords
| etothet wrote:
| IAM users get usernames - they don't log in with an email
| address. Root users log in with their email address.
| erikerikson wrote:
| 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?
| lokar wrote:
| 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.
| lsaferite wrote:
| I mean, why isn't this just the mandatory default going forward?
| Globally shared, unique bucket names always struck me as a
| horrible idea.
| ian_d wrote:
| 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-...
| CafeRacer wrote:
| While I understand where it's coming from I always had something
| like <bucket_tag>-<9_random_\d\w>
| PunchyHamster wrote:
| decision to make bucket (and not bucket + account id surrogate) a
| sole key for access was one of most annoying mistakes in S3
| design
| amne wrote:
| I hope nobody wanted "ecommerce-admin". sorry
| saurik wrote:
| 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...
| peanut-walrus wrote:
| 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.
| cyberax wrote:
| I would guess that it can add one more DNS lookup?
| Bridged7756 wrote:
| 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.
| echoangle wrote:
| 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 (?).
| returningfory2 wrote:
| Or old code referencing the bucket _writes_ data to it, and
| the attacker can now read it.
| tekla wrote:
| https://www.aquasec.com/blog/bucket-monopoly-breaching-aws-a...
| pooplord69 wrote:
| Does it still take like an hour to rename one?
| GuinansEyebrows wrote:
| 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.
| SoftTalker wrote:
| 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.
| arjie wrote:
| Good solution. Thanks for popularizing it.
|
| * Backwards compatible
|
| * Keeps readability
|
| * Solves problem
| wrs wrote:
| 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.
| emddudley wrote:
| 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?
___________________________________________________________________
(page generated 2026-03-13 23:00 UTC)