> Some of data was much more detailed than just the email address and included personally identifiable information (PII) ... ‘Emailrecords’ was structured to include zip / phone / address / gender / email / user IP / DOB
How messed up is it that random 3rd parties collect and assemble all this information to begin with, leaks aside? Sounds to me like all this data fell into unscrupulous hands way before any hackers may have found it on the public internet.
I've seen a demo where given my email address they could pull up my name, address, profession, age, and I forget what else. Yes, it's already in unscrupulous hands.
My data is empty, even though I'm not that paranoid about privacy (but I do take some care).
This specific API seems pretty innocuous. They're not doing black magic, it's just aggregating data that people willingly put out there about themselves.
I'm sure I'm out there in many datasets with stolen (or just "shared") information.
> This specific API seems pretty innocuous. They're not doing black magic, it's just aggregating data that people willingly put out there about themselves.
That's has always been illegal in my country though (you can't even keep a record of people with pen and paper), and now with GDPR would of course be illegal with actual consequences if it contains data about EU citizens.
Regardless, they're not based in Europe. Unless they do business in the EU, they can't touch them. This is due to the fact that extradition requires something to be a crime in both countries, so unless the EU has assets to seize, nothing they can do.
And if they try, any American court will be very leery of setting the precedent that Brussels can tell Americans what to do in any sense, particularly with respect to data stored on their servers.
Perhaps not directly, but if they're processing the information of EU data subjects on behalf of another company that does business in the EU, then that company will have to justify using this service, which is clearly not GDPR compliant.
I imagine the company using them will want to recover financial losses they incur after getting reamed by whatever european Data Protection Authority decides to go after them - especially if the culprits did promote themselves as being GDPR compliant.
The point of the EU's strong data protection rules is to have accountability - and it will fall on someone along the chain that caused the mess. Companies can't be allowed to completely disregard how they collect and store data and then go "Oops, haha sorry about that!" when the shit inevitably hits the fan, and just continue their business as usual.
Hi, Gilles here CEO of Livestorm. Thank you for surfacing this.
What is this URL: This is not a public API route, it is a proxy to a service called Clearbit to enrich professional emails with public company and person data from multiple public sources such as AngelList or LinkedIn (cf https://clearbit.com/enrichment and https://clearbit.com/our-data).
By using this route, you are using Clearbit with our credentials. Most importantly, we don’t store any data on our end when accessing this route. We don't own this data, it is stored on Clearbit servers.
Why are we using them: We entered in business with Clearbit to help our users get more insights on their webinar sign ups from public data sources.
We took all the steps necessary with Clearbit to ensure our process was GDPR compliant. However, this information makes us double guess it. Therefore, we are revaluating the compliancy of this specific process and in the meantime, we have deactivated this route.
Actually (after contacting their support because of wrong data that was returned for my contact), they seem to be using https://clearbit.com/ instead as backend.
What surprised my is that when you go to https://clearbit.com/ at "Understand your customers" it actually showed our company logo. Probably based on Ip address because I'm at the office right now and cleared my cookies.
Mine has information harvested (provided by?) from about.me. (I had a page there about my dancing activities) So this API tells anyone where and when they can meet me for a dance. (9 years ago, that is) :D
people were so afraid of BIGTECHs getting their hands on all your personal data. When in reality, a 13 year old can just ask around on some forums and get it.
30 years ago you could already buy almost all of this + estimated income and education on 90% of americans. It's how credit card companies know who to send mail to.
20 years ago my first roommate worked for a company that did direct mail marketing, and they regularly engaged a "cleaning" firm that would scrub and update their mailing lists.
This company had a huge databases of information on people (name/work/address/DOB/income/etc) and they would send them data and they would clean it up.
Now they would not give them any new data, they could only update records they already owned.
Back then in Canada there were apparently only a small handful of well-known cleaners like this who traded on their reputation for accuracy and dataset completeness..
Does anyone have this dump, or at least a way to check exactly which of my data was in it? HIBP doesn't tell you, unfortunately, even though it definitely could, since I have verified my email address with them.
In the United States, simply accessing a publicly accessible URL can put you in prison, assuming the government doesn't lose the appeal on the technicality of a choice of venue, which they won't do a second time... https://www.eff.org/press/releases/appeals-court-overturns-a...
Not just peers, peers who didn't get out of jury duty.
Personally I think jury duty should just be mandatory (with the only exceptions being extreme circumstances) because it being so easy to get out of creates a major bias in the set of people actually doing jury duty.
That's a much harder question and one I don't claim to have an answer to. It doesn't change the fact that I don't trust my peers. I don't trust your average American to be informed enough and educated enough to make decisions about my life. Jury of peers might as well be trial by mob.
Physical analogies for security like the one you just made are useless because they don't reflect how the computers and the internet work. You can't just ping a rock and ask it if it's got a key. The rock isn't expected to exist in a world where some script kiddie in China is going to ask it if is has a key every 5min. The analogy simply falls flat on its face once you try to use it to reason about anything because existing as an internet connected device is far different than existing on private (but easily accessible) property.
If you'll refer to what I was replying to, I wasn't talking about physical security being analagous to digital security. I was saying it is illegal to attempt to open and access property that you do not own.
That's an absurd analogy. How are you supposed to know if a completely unauthenticated URL is meant to be private or not?
If we're going to try to force physical analogies to represent the digital, I would say it's more like every store, house, and public building looks exactly the same and you don't know if the door is locked or what's inside it until you try to open it.
Your point is good of course, but I think the question has already been answered in society. If you aren't explicitly allowed into someone else's property, you aren't allowed.
I'm allowed to look at property from the street. There's nothing stopping me from walking around the neighborhood looking into everyone's property. I can even walk up to the house in most cases, and peering into windows is usually legal as well. I would even argue that trying the doors is also legal, though entering is probably illegal in most areas.
Accessing a URL is like walking around the neighborhood looking from the street. Trying different URLs is like peering into windows. Trying the door is like testing default credentials.
To make something a crime, you need to prove some kind of loss as well as intent. If there's no intent, it's likely a civil case to get restitution (e.g. you won't arrested for breaking something in a store accidentally). Likewise, you could get arrested for intent without loss (e.g. tried to break something in a store, but failed).
IMO, it should only be illegal if there's intent to harm. Likewise, if you accidentally harm something without intent (e.g. accidentally DOS a server), you should be expected to make restitution. Both need to be proven in a court of law, criminal if there's intent, civil if there isn't, and if there's no harm or intent, there's no crime.
It's not analogous because in internet protocols the server has to actively send the "property" in response to a specific request to access it. If a request is made and a response freely given with no further authentication required then it is a stretch to compare this to coming onto someone's property without invitation. Perhaps if one is accessing unauthenticated services on a private network this analogy would sort of work, but the assumption is that if you run a service that responds to random requests on the public internet you intended the responses to be public. It is more like an owner hiring someone to stand on their property and invite people in then complaining that they gave their employee poor directions and faulting the public for trespass.
I wouldn't try to use physical property as an analogy. You can't even see what properties there are until you enter them. If the door wasn't locked you won't know until you're already inside.
Here's an analogy I think is closer: I ask you for all your personal documents and bank account numbers. You promptly give them to me with no questions asked. Was I accessing private property improperly? If you refused and demanded I identify myself as someone authorized to have access, and then I forcibly took them from you anyway, that would be criminal.
Web addresses aren't property, I think that's the wrong analogy. The web is made of requests and responses, and you don't know what response you'll get until you make the request.
I strongly believe that we should be keeping our email addresses as secure as our passwords. It’s a really important attack vector as it’s often the starting point for any targeted attack, and although it’s not usually considered as a factor, it is the 2nd factor required for most logins (email and password). Triggering important security processes (eg reset password, social engineering attacks) are trivial once you know someone’s email address.
It’s clear from this hack that the owners of the hacked site didn’t see emails as something worth securing (stored in plain text on a wide open mongo server)
If you want to keep your email address private (you should), generate a new, random email address whenever you give yours out (the same way you use a password manager). If you have your own domain you can use a catch all/wildcard address, eg. *@mydomain.com, if you use gmail you can use their plus support, e.g. John+uniqueidentifier@gmail.com, if you use neither or want more security I’ve recently launched https://idbloc.co which aims to help deal with this.
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.
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.
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.
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.
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.
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.
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...
I agree with most of what you said, but it's even more important to keep access to your email secure than it is to keep the address private, so why should I trust your relatively unknown service to be the gatekeeper to all my accounts?
I like the idea, but I'd like it better if my existing email provider that I already trust gave me unlimited aliases (long random ones are fine, and I'd even be willing to pay, say $0.10 each). "+" suffixes are a start but they still leak the original email address.
Sendmail and postfix both allow you to configure that. I have my mail set up so '+', '.', and '_' all work the same. I've never seen any site deny the '.' or '_' character.
There are other privacy respecting email providers who give aliases. Posteo and Mailbox.org provide three aliases to begin with. Additional aliases on Posteo are EUR 0.1 per month. Runbox provides 100 aliases per account, and more can be purchased later. Fastmail provides about 600 aliases per account.
Practically, Runbox gives you much more aliases. You can use their own set of domains for each alias which is not small. Can't tell exact number now but around 30 or so. Really handy. There is another problem though. After you've done with many aliases and domains it's getting more and more difficult to maintain. You have to at least vaguely remember which one you have used already. I wish they could introduce a better way of managing aliases.
That’s not true. Fastmail provides about 600 aliases per account, not unlimited. [1] That’s quite high, but it’s also easy to run out of if one hands out aliases on a per-site basis.
Keeping emails private defeats their purpose as communication address and can lead to a false sense of security instead of properly controlling passwords and multi-factor authentication.
Yes because that's the same as requiring two passwords. It's even more secure to get three or five. But using the email address serves a different purpose, people rarely forget them.
While that is of course true enough, I go to a fair amount of trouble to remove my name, age, address, etc, from public databroker sites because I value my privacy. I don't want my email going around either. Any information leakage can be used to harm me.
They're a public endpoint and are open to receiving from any other address. It's no different than your physical address. You don't use them for authentication or marketing, they're just an identifier. Keeping them private accomplishes nothing.
One major issue with email address reuse is social engineering. It's a lot harder to attack someone's account if you can't even provide the email address.
Right now if you know someone's personal email, you can be pretty sure they use it everywhere. It's not a good practice, but it's hard to understand why until you've been the target of wtf-level social engineering attacks where someone got into one of your many accounts starting with nothing but an email address they don't even control.
Of course, there are some issues with the OP's email forwarding service:
1. You have to be someone concerned enough about security to want to generate email addresses, yet you have to be cool piping them through a third party. Ouch.
2. Niche product. I didn't realize how bad social engineering could be until I started hosting bitcoin services. I've had people break in to my AWS accounts twice (with bogus information) after Amazon told me they made a note on my account and that it should now be impossible. As we speak, I cannot get into nor cancel an AWS account that someone SE'd that's charging my CC every month even though it has my CC on file. I have to issue a charge-back. It's hilarious. Amazon thinks an email is more authenticating than a CC that's been on file for years before the attacker changed the email. They literally don't even have a customer support process for this situation. 99% of people even on HN have no clue how pwned they'd be if they're ever a target.
3. It's more of a feature on an existing product than a standalone service. I'd expect players like 1Password to implement it themselves.
It’s not too hard to set up your own VPS with Debian/OpenBSD and do the email forwarding/server yourself. The key is that it’s then literally a matter of a bash script to generate and accept one-time email addresses.
You have to jump through a few hoops for gmail to accept your emails. The documentation is there.
If you’re already running a VPS for other reasons, then this is free. If you’re not, then VPSs are extremely cheap anyway.
Emails are not used for authentication. Access to an email account can be used for authentication the “reset password” approach.
Emails are an ID on most sites, that’s it. Just because you provide the email as an ID for the account you want to authenticate against doesn’t mean it’s a factor of the authentication.
Your service looks very interesting, but I have one concern and some suggestions.
The auto-generated email addresses seen in the screenshot look very long. There are sites that restrict email addresses to 30 characters, 40 characters, 50 characters, etc. A quick count on one of those on your site showed the length to be more than 50 characters. So this may not work unless you provide a way to specify the length of each generated email address.
Now for the suggestions: the pricing on the Plus tier seems quite high. In fact, one could pay less than $4 a month (the Plus pricing) and get a Runbox mail account with 100 aliases and a Fastmail account with 600 aliases. So the only value in using your service at that tier seems to be the auto-generation part. The pricing for the unlimited tier is also much higher than the average prices of any paid privacy respecting email service. With the services mentioned above, one wouldn’t get tied into an @users.idbloc.com address either if one were to use their own domain.
>Triggering important security processes (eg reset password, social engineering attacks) are trivial once you know someone’s email address.
Sure, but that alone isn't an issue unless you have weak passwords for your email accounts.
>If you want to keep your email address private (you should), generate a new, random email address whenever you give yours out (the same way you use a password manager)
If you're already using a password manager how's that going to provide any additional security? No one is going to crack your 128 bit entropy passwords even if they have your email.
It helps avoid most phishing emails. I have a DB with a list of randomly generated aliases and services I've provided them to. My e-mail client is set up so that these individualized per-service aliases are highlighted (and renamed to the name of the service I provided the secret alias to) in the message list, so I instantly know when I receive e-mail from a service, and when someone is trying to spoof it by sending e-mails in the name of the service to my public address.
I can also whitelist some of these private addresses, so that my spam filter can't hide e-mails from services I depend on, no matter who sends them (it can be automated no-reply address, or some support person's address, etc.), so it's not really whitelistable based on the sender. I can't whitelist my public addresses.
It has plenty of benefits with regards to security.
It's basically a secret passphrase you give to a company that it can use to reliably contact you, and that you can use to verify that you're talking with someone you've given this secret to. It's not perfect, but much better than public addresses.
Your system looks useful and at the same time seems to involve some manual work. Please consider writing one or more blog posts about your setup. It could be very helpful to others.
- I have a simple custom web UI for managing mailboxes and aliases in the PostgreSQL database.
- I have postfix/dovecot setup with virtual mailboxes. I avoid DB/postfix interaction by simply dumping DB into a static postfix config files (this is much lighter on resources, than having postfix connect to the database, and much less complicated). I don't use catchall address.
- I use POP3 to get mails from my VPS, to avoid storing archive there, and to avoid having to deal with IMAP in my mail client and filtering scripts
- I use neomutt as a mail client. It has some nice options, like reverse_alias (which I use to display names of my private aliases)
- Neomutt can read configuration from a stdout of some command. I use this to generate aliases and other config options, that make it so that when I reply to something delivered to a private alias, the reply will be sent from that alias too. Using this I can have a single Inbox.
- I filter e-mail using a PHP script (it parses the e-mail, checks the alias database, and decides whether to pass the message to bogofilter, Junk, or Inbox)
Aside from adding aliases to the database, there's no other manual work.
You can probably avoid the database by having some scheme, where address is servicename.[substr(sha256(servicename+secret), 10)]@domain.com and filter/whitelist/highlight on the hash validity.
Totally agree that generally speaking no one is breaking high complexity passwords. Why break the password when you can just convince someone to change it for you?
Easiest way is just to put up a fake service and they’ll give you their real password (same one they use everywhere). I can do this in a day and get thousands of real passwords and emails if I wanted to.
Are you sure all your passwords are secure? Are you sure your accounts can’t be broken into with social engineering? Is your password manager infallible? It’s defence in depth.
Of course you may also do this for privacy reasons as well, when your reddit account is leaked do you want that linked to your LinkedIn account?
>Are you sure your accounts can’t be broken into with social engineering?
And who's to say that you can't also use social engineering to recover the real email? eg. "I forgot which email I used, but it's on my domain, example.com". This is even more plausible if you use any of the "tricks" that the GP mentioned, like putting random characters, since it further lends credence to your "forgot my email" story.
>Is your password manager infallible?
Considering you have to store all those different emails somewhere, I don't see how this mitigates the treat.
>It’s defence in depth.
Sure, it's defense in depth, but the gains in security is so marginal.
>Of course you may also do this for privacy reasons as well
Sure, I'd buy that aspect, but catchall domains or dot/plus tricks aren't going to cut it because they're relatively easy to deanonimize. Not to mention all the data you leak on those platforms just by using them (location references, friend lists, interests, etc.)
Been using a wildcard for one of my email domains for years (facebook@..., linkedin@... etc) and never once have I had issues with spam. Everything for services I dont care about goes through SpamAssassin on the mail server and items that pass get dumped to Gmail, where only "ham" messages will get forwarded through to my real inbox.
I think they were using their catch-all for non-transactional/newsletter emails. I have a catch-all for websites and then another that I give to people to email me on. This lets me see emails sent to me by a person easily while having separate email addresses for each site.
Do you have catchall directly on the second level domain (@mydomain.com) or do you only catchall a specific subdomain (@mail.mydomain.com)? I'd expect a very big difference in the volume of blue sky spam between those two. If GP sbov has the catchall directly on mydomain.com, then restricting the value space to *.r will make a meaningful difference.
Having the "validating substring" in front of the @ will actually make it easier when you have to use the email address in vocal communication: many humans are unaccustomed to encountering more than one dot after the at.
> I recommend suffixing the user of all addresses with something you want to go to your inbox.
I use a subdomain. *@abc.example.com goes to my CatchAll folder. usernames@example.com go to their respective users. There are no equivalent names between @abc.example.com and @example.com so if anyone gets cute[0] and tries stripping out subdomains, the messages are rejected. Also, subdomains are common enough that no one thinks anything of it.
As a nice bonus, the subdomain can also be directed elsewhere. I've aimed it at various "we automatically file your e-mail" type scripts and services before, just to try them out.
0 - Spammers absolutely try to get cute and drop the subdomain. For example, in the Dropbox leak, dropbox@abc.example.com and db@abc.example.com of mine were leaked. I see tons of spam attempts to dropbox@example.com and db@example.com daily.
Thats a good solution. For 15 years or so I just used the user.site@domain.com approach. But in the last 4 or 5 years, the spammers have gotten smarter and now are stripping off the site and just emailing user@domain.com.
Since we’re sharing anecdotes: I do this presently and get very little spam to random addresses. I’ve been on this scheme for about a decade now. All spam is to a specific address, which I’d given out.
You don't use wildcard addresses for this, you use sub/plus-addresses. That way the spam problem is completely avoided and multiple users per domain will work normally.
Sure, but from a security/authentication standpoint that won't be an issue.
Even if you have my John+ajf@example.com address it still won't help you with login in on other sites as the address used on another site is still unknown.
Yes, it is- however it could stop an automated attack where the bad agent isn’t targeting you specifically or is not a particularly knowledgeable agent. It also might help you find out where a leak or spam is coming from (eg if you get a reset password email from John+facebooksecretlogin@gmail.com, you know your Facebook email address is known to an attacker). So it’s better than nothing.
Obviously this only works if all emails to john@gmail.com and john+unrecognisedidentifier@gmail.com are rejected without notifying the recipient. This was how Yahoo's scheme worked (I never actually used it, not sure if it's still active). If gmail's doesn't, then I agree it's worthless.
then if you get any email to `j.o.h.n@gmail.com` you can filter it
Of course, they can start stripping dots in gmail addresses too, but then they'd have to be targeting gmail specifically or they'd break for most services where dots do matter.
Pretty easy reason why you shouldn't; under GDPR you don't have consent to use this email (though this reasoning is a bit shakier) and scrubbing the suffix runs afoul of spam laws in my country (if you're given an email for contact, you use THAT email, not anything else).
Sadly, "+" doesn't work. Too many web email validators fail when given a "+" character. Gmail has made some of that a little better, but I still bump into it too much.
I generally use "_" or "." for wildcard start as any email validator that hangs on those will get smashed immediately.
It unreasonable to assume anyone could ensure his email is kept private the moment she shares it with at least one other entity.
Rather than trying to fight windmills, it's better to use unique emails for sensitive/high-risk purposes. That way they cannot be used as primary key.
Company policy here is to never register any company account under a generic <admin@company.tld> email but use a partly randomized email for each provider <provider-xyz-123@company.tld>. That way no one can use one leaked email to even identify other services we use (think reset password/login dialogs leaking information about an email being registered or not).
> I’ve recently launched https://idbloc.co which aims to help deal with this
Nice! I just started working on the same thing, and it would be great to be able to drop the project… except trusting a new service with your e-mail is hard. (It’s even hard to trust established names like Google or ProtonMail.) If only every service supported encrypting e-mail so providers couldn’t read it. :(
I've been working on similar project since last year as well. (I slacked a little bit -- grad school and stuff).
Too bad the SMTP protocol is limited. I was thinking of ways such a service can be designed in a provably secure way (where we don't get to actually read the messages, just apply rules based on headers only). Any thoughts?
(Actually, replace “trusting a new service” with “trusting 3+ new services” – it’s probably hosted on AWS or something, and https://idbloc.co/privacy mentions that mail is forwarded with MailGun.)
The irony lay in that email addresses were originally designed as communication channels (like snail mail), but have since been co-opted into serving as a unique identifier (like SSN).
So, you need to share your email address to be able to communicate properly, but you also need to hoard it because it is part of how you identify yourself. Aliases are one workaround but are not universally accepted as identifiers.
A catch all address is just asking for a sunami of spam.
But maybe something*@example.com
I have two Gmail addresses. A public and a private. For anything that is public facing, that exposes the email or that I don't trust as much, I use the public email. For everything important, I use the private one (and sometimes with the + method).
My private address is set to forward to my public. I only respond and send email from the public email.
BTW this is how you market a product. Intimately knowing the space. Providing insightful context on the importance of the problem in a public forum. Offering the free solutions, which are usually manual and cumbersome. Then, finally, offering your service as an easier alternative. Well done.
I think we need to completely reimagine email, though a proper fix is likely pretty easy. I think social networks have done a pretty good job at the basic idea:
- ask to connect, perhaps with a short message as to why (maybe limit to 100 text characters)
- once approved, communication is encrypted (PGP keys are exchanged behind the scenes)
I think that would drastically limit the amount of spam, phishing, and intercepted messages, which is good for everyone. Unfortunately, I think it's also quite unlikely to hit the mainstream.
I wonder if an email masking service would make sense. You register with it, and give it your real address. You then can generate a new public email anytime you like. Control how it behaves, etc. [/me hits up google]
So, I just looked to see, and there is already a service doing this: https://www.abine.com/. The email forwarding is the easy part. They also do "burner" credit card numbers. I don't know that domain to know how you do that, but that seems good. They also do phone numbers. Neat idea.
Email is not a factor in authentication, it’s a user identifier. There is a huge difference between the two. Requiring users to also provide their first name is also not a factor.
Email is just a worse version of the same factor in a login. They are both just “something you know” only email is even worse because it’s something everyone who knows you knows.
Just to drive the point home, if a website asks you to set three passwords that it asks you for on each login, that’s not 3-factor or even 2-factor authentication. They are all just part of the “something you know” factor.
I highly suggest using a catch-all on a subdomain, not a top level domain. Top level domains get dictionary-style spam/phishing storms (eg alice@, bob@, charlie@, etc), but those don't seem to occur with subdomains. You can also create just an MX record for a subdomain, which helps 'hide' it to some extent.
The first time I setup a top level catch all, I had the first dictionary style attack within a day or so. I've been using a catch-all mail-only subdomain for well over a decade, and have had no such attack.
> I strongly believe that we should be keeping our email addresses as secure as our passwords.
That doesn't make any sense. Just create multiple email addresses, one for talking with people and a separate one for signing up for services.
The one problem is there are companies like Facebook where even if you sign up with a secret email address, they will send password reset tokens to the other public-facing email addresses you have on your profile.
idbloc looks good. Maybe consider a one-time price option too. Or for people on the free plan, consider allowing them to buy a one-time top-up pack of email "credits" if they use up their free 100.
Personally I have a bunch of spare email addresses from google, yahoo, and others that I created many years ago before they demanded a phone number when signing up. I just use those for website logins.
there is also theothermail.com to generate throwaway email addresses that forwards emails to your original inbox, you don't need to use your personal email address to sign up for a newsletter
we created the service theothermail.com to generate throwaway email addresses that forwards emails to your original inbox, you don't need to use your personal email address to sign up for a newsletter
Thanks for the tip about gmail's "+" support. I'll start using it. I don't think it does anything to keep your email address private, though. Recovering the original valid email address from "John+uniqueidentifier@gmail.com" is trivial.
this is like saying that you should keep your public street address private... you are thinking about it backward. What needs to be done is don't use your email address as a login or worst, as a password recovery option.
While not of any value for 95% of users, for techies a great workaround is to have your own domain and use a distinct email for each service that all go to one catchall account.
Forget about email addresses, the network should scale globally from the user's public key that can be stored on any number of nodes as the user id with the data.
"Should not be" and "is not, ever" are, unfortunately, two wildly different world states.
The fact is that email is often the keys to the kingdom, if compromised, or the baited hook to be used in phishing. With consequences which have had globally-significant consequences, to date.
Absolutely. If software needs configuration before it is secure than the default behavior should be to throw an error while starting up with a link to the documentation for configuration. The default should NEVER be to just start up unsecured.
I believe more of the blame should be put onto markets that provide images with insecure settings as MongoDB doesn't bind to the public interface by default and hasn't done so for years.
Which is true for most popular systems, which I appreciate. I need to consciously decide to put something on an externally accessible port, which reminds me that it's time to make sure everything is secure (TLS, authentication, user privileges, etc).
Did MySQL let you connect to instance from remote without password like ever? I used it first time like 16-17 years ago and don't remember anything like that.
PS: And yeah I remember that famous password bypass bug from 2012, but that's all.
MySQL's "security model" used to be that it only bound to 127.0.0.1, but beyond that there was no passwords. I may be recalling incorrectly, but root did have access via `%` on most systems I used.
I'm not sure if the reason MySQL was open with no password is MySQL's fault or the various distribution packagers, they have a lot of say in how its ultimately configured, but it wasn't a good look.
I really can't recall if / when it's changed, but for many years you just wouldn't be able to connect to MySQL as root unless you set the password. Also if someone have access to your localhost it's almost always mean you're already in trouble no matter how well database configured.
>They do this by literally sending the people an email. If it does not bounce, the email is validated.
That's a pretty dumb way to validate an email address. You can just end the connection after a successful RCPT TO and no one needs to be the wiser. The method causes a false validation in the case of an intermediate mail relay that accepts everything but that is such a bad idea that no one does that.
Actually a lot of email addresses cannot be validated this way since most ESPs including gmail have adopted an 'accept-all' approach to incoming email. So getting the email accepted by the server is no indication that the address exists, or that the email will actually be delivered to that address even if it exists.
I wish Google would build an OAuth flow that would provide an obfuscated and unique email address to services that need an email address for logins or any communication at all.
I’d just be happy if Google made it harder for third parties implementing “login with google” to not get access to your entire org’s user list (when the org uses gsuite.)
Can you elaborate? I thought "login with Google" meant a pretty useless token (granting access to that user's basic profile info).
Can additional OAuth scopes be requested and do the third parties request the contacts permission, then harvest the organizations' contacts, and is there no setting in the admin menu to prevent either the OAuth grant or the contact access?
Lots of SaaS companies have a “sign up with google” button which gives them access to the employee directory assuming your org uses google suite. It’s unfortunate yesteryear’s shit growth hack for consumer apps is reappearing in a worse way.
[WAS: If I'm reading the Wired article[1] correctly, the haveibeenpwned.com database of email addresses has itself been leaked?]
EDIT: Replies have corrected my misunderstanding, thanks! Troy was saying that his own personal email was also in the dataset.
Hunt says some of his own information is included in the Verifications.io exposure. "The main takeaway for me is that this is just another case where someone has my data, and hundreds of millions of other people’s data, and I’ve absolutely no idea how they got it," Hunt says. "I’d never heard of the company until now and I certainly can’t ever recall consenting to their use of my data. Of course, it’s entirely possible that buried in some other service’s terms and conditions it says they’re allowed to pass my data around in this fashion, but that’s not really consistent with my expectations of how my data should be used.""
No, he's adding this email dump to his DB. And I don't exactly understand why, I mean is there any evidence that this mongodb was actually harvested? Other than by security researchers.
If someone gains unauthorized access to a system you own, you assume it's compromised and take it down, even if logs don't show anything. If you leave a system unsecured on the internet, assume it has been compromised and take appropriate measures.
In this case, it is more likely than not that this guy was not the first to discover the database. In the absence of proof, assume it has been compromised before.
I do what others have said - I have domains and use pre-defined (DreamHost, no catch all) addresses different for most sites. I also define a bunch of generic ones I cam reach for on the go. I have about 150 now.
Is it worth it?
I don't know. It's part of the patchwork of steps I take, better than many people but by no means failsafe.
Company I work for was using an email verification service for the first time. We have a lot of brands, so I was being my white hat self and checking it out before we risked importing our largest subscriber brands.
It took me all of 10 minutes to find a convenient JSON endpoint with incrementing IDs that didn't disallow cross-account pulls. It wasn't a public MongoDB endpoint like the above, but we did get a pretty sweet discount rate for reporting it to them and, you know, not abusing some other customer lists with 300M+ emails.
This is why I sign up with a different email address for every site. You need your own domain to do that properly, but Gmail users can use (for example) "email+hackernews@gmail.com" to end up with a unique address. Of course it would be simple to get your real address out of that, but I doubt anyone but a spear phisher would bother.
Fair warning on the second link: it's Tumblr and redirects https -> http (probably intentionally, given the content), and I didn't see an obvious way to search.
The first is an awesome resource, and they publish password leaks as well, and they have a secure way to check if your password has been in a leak (my password manager, Bitwarden, integrates with them).
How messed up is it that random 3rd parties collect and assemble all this information to begin with, leaks aside? Sounds to me like all this data fell into unscrupulous hands way before any hackers may have found it on the public internet.