Yeah. Email addresses aren't secrets. If any one server or inbox gets popped you're fucked.

Though if you run a full domain you can use emails as one-use affairs. Most don't though and, really, what's the point? It only saves you from journalists, not from a motivated attacker.

> if you run a full domain you can use emails as one-use affairs

or, if you use a service that lets you generate aliases, like gmail's "+", or a service like mailinator.

The problem is that the attack vector of email addresses is they are sometimes used as a username, and therefore contains more information than what is strictly required (for the purpose of a username). Leaking the "real" email address not only leads to spam, but allows a more dedicated attacker to use that email address as a starting point on a different site, or hack the email address altogether.

And with sites increasingly blocking disposable email addresses like mailinator, or disallowing email aliases, the problem can only get worse.

Having your own domain is cheap. Generating an email that’s a function of the target website is trivial. I’ve done it for 20 years.

I can confirm the source of every email breach that contains one of my addresses.

Yep, I do the same. I typically use <sitename>@sites.<domain>.<whatever> for website logins (stored in my password manager, so I don't need to think about it to login), so that if my password ever leaks, I know where it was leaked from.

sadly using elite hacking skills this is easily circumvented

    p0wn3r $cat  testerm
    test@gmail.com
    foo+netflix@gmail.com
    foo+ycombinator@gmail.com
    foo+amazon@wizmail.com
    
    p0wn3r $cat  testerm | sed 's/+.*@/@/'
    test@gmail.com
    foo@gmail.com
    foo@gmail.com
    foo@wizmail.com

and so if you set up your email filters right, you can find out who is doing this sort sort of "hacking" to get your real email address. What you do afterwards is up to you.

By definition, if someone is offloading your data to a 3rd party and they sanitise the addrs, then you can't tell.

The "+" is not limited to Gmail, it's standard. The problem is many services with fancy mail validation don't accept it.

Does Gmail allow sending from the + addresses? There's quite an issue if somebody contacts you on that address but you reply without the alias.

They do allow it, but it’s a pain to set up for each + address, especially on iOS.

I have not find a way to send email from Gmail, using either the web interface of their SMTP server, from a custom username (left side of @ symbol). I have a custom domain using Google Apps, but to send mail I use a third party SMTP server to customize the username portion of the From field.

I've never had an issue using a different email for support, I always mention that I own the domain or email suffix and they can verify that if they want to (though nobody has so far).

I'd forgotten about the gmail trick. You're certainly right about that. Though I will say one thing: I've not been hiding my email this past decade and—as far as I know—it has not bit me.

> you can use emails as one-use affairs [..] what's the point? It only saves you from journalists, not from a motivated attacker

Can you explain this claim?

If you generate your single-use email addresses wisely, then you should know that the one you gave to - say - Marriott should only ever receive emails from Marriott.

If - say - Marriott gets hacked and that particular one of your many different email addresses leaks, then:

a) you'll find out that address is burned just as soon as anyone other than Marriott uses it (you immediately generate a new one, give it to Marriott, and stop accepting any mail at all on the old one)

and

b) if anyone other than Marriott uses it, you know immediately that that message can't be legit.

c) chances are that all your incoming phishing traffic will arrive at mismatched addresses. Makes it even harder to fall for it in that moment of mental blackout.

But if someone phishes you on you+BankCo@example.com you're probably more likely to imagine it's legit. Swings and roundabouts.

No-one would know that you+BankCo@example.com is an email address you can even be reached on, unless it leaks out from BankCo.

ADD: and of course, you aren't really going to stick +BankCo after your real name to generate an email to use with BankCo. You're going to give them something generated like you'd generate a password - "ol48eILm@example.com" or similar - so if anyone finds out that particular email address for you it doesn't tell them with whom you use it.

But that's a big if because phishers will always aim for the weakest individuals in the flock.

You can do a lot with a SSN in Finland. The first 6 digits are your date of birth followed by 4 random characters. If I had your SSN (and address) I could:

- Phone up the tax office and find out about all your finances, and make adjustments to your tax percentages and affairs.

- Phone your medical provider, and very possibly socially engineer them into revealing medial information. I could book an appointment with your doctor for example and impersonate you on the phone appointment.

- Call all your utility providers and cancel contract without you knowing about it.

- I highly suspect I could call your phone provider and take over your phone number, and in some cases use this to take over your email.

Whilst SSN should not be treated as a non-secret, the reality is that it is a secret and is often the only line of defense when dealing with companies.

And it shouldn't be.

The problem is that using a government issued ID is easy since everyone has one. That's the wrong use for something like a SSN, but you're right, it's what's done in practice.

We should be moving away from that. Government issued ID should merely be the equivalent of a user name, with any real use requiring additional factors of authentication (password, security key, etc). Unfortunately, most of these other factors are also easily accessible (mother's maiden name, date of birth, etc).

Ideally, we'd have something like:

- number issued at birth (like present system), frozen until individual activates it - individual sets password when unfreezing - all accesses must be explicitly allowed by the user - user can grant/revoke/audit access, and access is denied by default - no private data is stored in the account - companies that use the account for authentication are required to delete user data when the user requests it, and these systems are audited to ensure this happens

However, that's not the case. We should be fighting to change that. Having something like an email address or identification number become public knowledge shouldn't matter one bit...