> services should allow me to easily create lots of aliases. Right now the best defense against social engineering seems to be my fastmail account which allows me to create 1 email address alias per service What you may want is a catch-all email - which lets you do @domain.com -> nmjohn@domain.com (where is everything besides already defined addresses) - that way you can make up emails on the fly without having to se…
Fastmail and Gmail support a local suffix of the form yourname+amazon@gmail.com. That's a plus character between the local name and local suffix. If you use a password manager, you can replace a predictable suffix like "amazon" with random hex value. Unfortunately, many sites borked their e-mail address validation and do not accept the plus character. (Amazon permits it.) Also, you'll ocassionally find a customer ser…
Amazon's customer service backdoor
71–80 of 366 posts
Re: Amazon's customer service backdoor
#72Whois is great for social engineering attackers. You get a name, email, address, and the first service to attack. Meanwhile, the ICANN is working around the clock to make it illegal for us to protect our personal information, and whois protection is becoming an increasingly niche service for registrars. For example, gandi.net (and thus Amazon) doesn't hide your name when you have it turned on. By the time you find th…
A related word of warning: Namecheap updated their registration page last year. Now, when you register a domain it tells you free Whoisguard is included, but it doesn't make it clear that it's disabled by default." Previously it just worked. Now you have to check another box to turn it on. This change makes no sense to me. (If you want free Whoisguard, why would you not want it turned on?) I was white-hot furious* wh…
I switched to Namecheap based on recommendations here, and their previous stance on certain privacy issues, but I'm running out of alternatives.
Re: Amazon's customer service backdoor
#73Re: Amazon's customer service backdoor
#74Earlier quoted context omitted.
While that's true, and perhaps even needs to be "the default", there really needs to be a way to say "Hey, I'm concerned, and am prepared to take responsibility for my own access credentials. I demand you categorically _do not_ disclose any of my personal information to anyone without a warrant or court order." And for that sort of demand to have appropriate legal teeth to ensure people collecting that data are suffi…
Unfortunately, far more people think they want that than can take full personal responsibility for it. See also: people who don't understand that full-disk encryption means they lose their data if they forget their passphrase. That doesn't make full-disk encryption in any way bad, but if you train people to think that all accounts have a "forgotten password" option, they might get a nasty surprise.
Most of "us" already deal with these things though - there's no "forgot password" for my ssh keys or my ssl keys or my topt seeds - there's no "forgot password: for my 1Password and Keypass safes. We occasionally get to laugh at out less diligent colleagues and peers who belatedly reveal the time they "lost" the ssl private key or the production webserver ssh key, but it's not like we see critical infrastructure falling apart regularly because of forgotten-but-unretrievable passphrases.
But I suspect you're right, there'd probably be a whole lot of "Hold my beer and watch me turn on full personal responsibility here! Oh, hang on - shit. Oooops..." if Ama-Face-Goo-Yah-stagram allowed this...
Re: Amazon's customer service backdoor
#75> services should allow me to easily create lots of aliases. Right now the best defense against social engineering seems to be my fastmail account which allows me to create 1 email address alias per service What you may want is a catch-all email - which lets you do @domain.com -> nmjohn@domain.com (where is everything besides already defined addresses) - that way you can make up emails on the fly without having to se…
Note, though, that catch-all emails will also catch a ridiculous amount of spam. Creating each account name individually avoids that problem, at the cost of some extra trouble when registering a new service. An intermediate step that may work if you don't expect people to target you individually: have one or more required substrings for the email local part, and catch all mail to addresses containing that substring.
I haven't found this to be true, or at least Google's spam filters have gotten sufficiently good to prevent it.
I have a catch-all address @morgante.net and rarely ever see spam—maybe once a week.
Re: Amazon's customer service backdoor
#76"The problem is, 9999 times out of 10000 support requests are legitimate, agents get trained to assume they’re legitimate. But in the 1 case they’re not, you can completely fuck someone over." That's why nothing will change if these estimates are even in the right universe. Nobody wants to inconvenience the vast majority of customers to prevent a minuscule number of issues.
Except if they became reliable for the damage caused by the infromation they released of course. They would then have a financial incencitive to have better security checks.
Re: Amazon's customer service backdoor
#77Earlier quoted context omitted.
Note, though, that catch-all emails will also catch a ridiculous amount of spam. Creating each account name individually avoids that problem, at the cost of some extra trouble when registering a new service. An intermediate step that may work if you don't expect people to target you individually: have one or more required substrings for the email local part, and catch all mail to addresses containing that substring.
One method that I've seen used (heard it described by a guest one of Leo Laporte's podcasts a looooong time ago) is to iterate account names by year. For example, this year the email address would be pyre2016@example.com, and next year it will be pyre2017@example.com. Not sure how well it works, but the idea is that by that every year you start over with a fresh address (that takes a while to get onto spam lists). I'…
Re: Amazon's customer service backdoor
#78Earlier quoted context omitted.
A related word of warning: Namecheap updated their registration page last year. Now, when you register a domain it tells you free Whoisguard is included, but it doesn't make it clear that it's disabled by default." Previously it just worked. Now you have to check another box to turn it on. This change makes no sense to me. (If you want free Whoisguard, why would you not want it turned on?) I was white-hot furious* wh…
Worse, they'll happily sell you Whoisguard for domains that don't support it. When you discover it's not usable, they'll give you a refund, then include it again in the next billing cycle. I switched to Namecheap based on recommendations here, and their previous stance on certain privacy issues, but I'm running out of alternatives.
Re: Amazon's customer service backdoor
#79Earlier quoted context omitted.
Unfortunately, far more people think they want that than can take full personal responsibility for it. See also: people who don't understand that full-disk encryption means they lose their data if they forget their passphrase. That doesn't make full-disk encryption in any way bad, but if you train people to think that all accounts have a "forgotten password" option, they might get a nasty surprise.
While ago I setup FDE on a new drive, put the passphrase in my encrypted password file, put the new copy of the password file on the encrypted drive, and then proceeded to wipe machine that had the only other copy of that password file (well at least the up-to-date version with that passphrase). A nasty surprise indeed. Thankfully I only lost a month's worth of files (mostly photos).
One time I had my carefully encrypted secrets thoughtfully spread across my laptop drive, my iPod as backup #1, and an external hard drive as backup #2. All of which I had in my backpack one night - which I proceeded to leave at a restaurant where I'd been sitting outside on the sidewalk tables, and I didn't notice until _way_ after they'd closed for the night. (I used up a _great_ deal of luck that night - we went to that restaurant enough to be "regulars", and the waitstaff found it and knew it was one of ours, and it was waiting for me when they opened the next day...)
Re: Amazon's customer service backdoor
#80Earlier quoted context omitted.
So, commit criminal fraud to prove a point? Bad idea.
If there is written, explicit permission to perform this attack, how is it different from a corporate penetration test?