Bucketsquatting is finally dead

Original Article ↗ Hacker News Discussion ↗

AWS is introducing account- and region-scoped S3 bucket namespaces, effectively ending “bucketsquatting” attacks where deleted bucket names could be re-claimed by attackers and silently receive sensitive reads or writes from leftover code. Commenters generally welcome the change as overdue, contrasting it with similar global-naming pain points in Azure and DNS, and debating alternative mitigations such as hashed bucket names, stricter reuse policies, and IAM/SCP safeguards. There is also criticism of AWS’s slow, sometimes awkward evolution of core primitives (like S3 naming and multi-account handling), alongside pragmatic notes on how IaC tooling and naming conventions will need to adapt.

Clarifying the Bucketsquatting Problem

  • Some initially think hashing/salting bucket names prevents “guessing”; others clarify the core risk is recycling names, not guessability.
  • Typical failure mode:
    • A bucket is deleted while some code/CI still references its name.
    • An attacker (or another user) later creates a bucket with that same name.
    • Old code resumes working, silently writing sensitive data to, or reading from, the attacker’s bucket.
  • Real-world example: Terraform stack teardown deletes a bucket; another stack still has the bucket name hardcoded; CI starts uploading artifacts to a newly created, unrelated bucket.

Proposed Defenses and Remaining Risks

  • Suggestions:
    • Use long random/hashed bucket names and treat them as secrets (via IaC).
    • Use conditions like “expected owner account ID” on S3 operations and SCPs to prevent cross-account writes.
  • Counterpoints:
    • If the name ever leaks and the bucket is later deleted, randomness doesn’t help.
    • Bucket names are exposed via DNS and potentially passive DNS logs; secrecy is limited.

Reactions to AWS’s Namespace Change

  • Many welcome account‑regional namespaces as overdue “good hygiene,” closing off a common production footgun.
  • Others see the solution (account/region suffix in the name) as hacky compared to subdomain-based names or a true v2 API.
  • Concerns about:
    • Name length limits when suffixes are appended.
    • Backward compatibility with tools like Terraform that relied on bucket_prefix.
    • Continued existence of special S3 behaviors tied to specific naming patterns and a new header (x-amz-bucket-namespace) whose necessity is unclear.

Cross-Provider Naming & Namespace Issues

  • Azure storage accounts also use a global namespace, viewed as equally problematic, with stricter length and character limits and no dashes.
  • Some hope other providers will adopt per-account namespaces too.

Account IDs, Emails, and Identity

  • Consensus: AWS account IDs are identifiers, not secrets, though best not overshared.
  • Separate thread on AWS root emails: deleted accounts permanently “reserve” the email, blocking reuse and causing SSO friction; some see this as reasonable security, others as overly rigid and operationally painful.

Broader Naming Debates

  • Discussion of alternative schemes (Discord-style discriminators, UUIDs plus human “petnames,” domain-based names).
  • Domain expiration and DNS reuse are noted as an analogous, unresolved squatting risk.