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?

I named random Joe as the sole owner of "my" bank account and the bank wouldn't allow me to access "my" money!

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.

This is why you either issue corporate phones or key dongles.

What happens when someone loses their phone?

This is why you never use personal phones for MFA to critical accounts.

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

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.

IAM users get usernames - they don’t log in with an email address. Root users log in with their email address.

If user [email protected] 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!”

>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

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 "[email protected]"

2. Let the domain registration lapse

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

Rare but not impossible.

I did something similar.

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

Now that same account is bound into an AWS Organization.

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

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

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

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.

V1 never dies. You support it forever, including for customers who desperately want v2-only features but would rather escalate than migrate.

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.

Use 1 for your separator.

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.

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

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.

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'"

That still has "squatting" risks as described in the original article though, domains expire and / or can be taken over.

I didn’t think it was possible to have a personal TLD - did you mean a personal domain?

Or old code referencing the bucket _writes_ data to it, and the attacker can now read it.

I'm pretty sure buckets use star certs and thus the individual bucket names won't be in the transparency logs.

> 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.

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.

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?

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

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

Then they should allow bucket ownership transfer...

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?

Ok; salt, and then hash your bucket names