121–130 of 141 posts
[1] https://www.facebook.com/notes/protect-the-graph/securing-em...
Thanks Every Employer I've Had In the Past 6 Years For Putting My Email In A Service I'd Never Want Otherwise. Also Thanks Me for just using docusign w/ our employees when I was in charge.
I strictly started handing out "companyname@mypersonaldomain.tld" as email when interacting with companies. That at least makes routing the inevitable spam to the trash bin slightly easier when a breach occurs. It also provides an indicator of who has (in)voluntarily given away my data.
Thanks Every Employer I've Had In the Past 6 Years For Putting My Email In A Service I'd Never Want Otherwise. Also Thanks Me for just using docusign w/ our employees when I was in charge.
I strictly started handing out "companyname@mypersonaldomain.tld" as email when interacting with companies. That at least makes routing the inevitable spam to the trash bin slightly easier when a breach occurs. It also provides an indicator of who has (in)voluntarily given away my data.
1. Pay a reasonable rate for a full time server in services that are just truly awful, have no redundancy options, and are associated with a lot of unsavory activity or...
2. You pay a totally unreasonable rate to host it in a more reputable cloud service.
3. You run it out of your home or office and deal with your locale's interent. In my case (California Bay Area) it's bad.
Earlier quoted context omitted.
It doesn't really spell out, though, how they differentiate CC info and avoid storing it with the rest of the data in the pdf form. There's just some hand wavy language about "Bank-grade Security". I suspect this means they store the CC data, which would be significantly different from how must online merchants operate.
As someone who has worked on a similar product, I would imagine they only store a token given to them by their payment gateway. The actual CC information is held by the PCI compliant payment gateway, while Docusign can use the token to charge a card without storing compromising information.
Earlier quoted context omitted.
There are indeed policy implications. Each such alias reduces the available namespace, where +-aliases do not. If I had to guess why Google doesn't implement this feature, I'd guess that's the reason - their namespace is already hotly contested enough. (Of course, you can do this, quite easily, if you run your own mail domain. You need not administer an MTA - I gather you can wire up a domain you own to Google Apps o…
All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If this is a concern then Google can generate an immutable part of it (with high entropy), for example I said "j45rsdfjdocusign " of which "j45rsdfj" may be generated and the user may rewrite only the end of it. The reason it's good for the user to be able to write…
Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N aliases, you are likely adding a new network hop and loads more memory storage before the MTA can accept/reject. When you are processing many billions of email (lookups), this is a significant change.
Again, it is solvable if they wanted to do it. But it is nontrivial. Add onto this the need for the product team prioritize the work, other work to be de-prioritized, planning, testing, etc.
I'm not sure DocuSign has a full handle on what happened here yet. I received six (6) DocuSign emails, half of which used a convincing subject derived from actual DocuSign documents I have signed or processed through the system. Perhaps a coincidence? Or these hackers gained access to more than just "email addresses".
I am skeptical as well. I feel like the standard procedure these days is for a company to acknowledge that their security has been compromised but that the breach was limited to only non-sensitive data.
Earlier quoted context omitted.
All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If this is a concern then Google can generate an immutable part of it (with high entropy), for example I said "j45rsdfjdocusign " of which "j45rsdfj" may be generated and the user may rewrite only the end of it. The reason it's good for the user to be able to write…
There is one thing you are forgetting, and that is working with data at scale. That is not to say it is not solvable, but it requires more thought than just shitting it out in an afternoon. Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N alia…
Nothing that you have stated is difficult or a choice, because johnsmith23+sketchy is live today. If you have a gmail account, you can give out your accountname + marker to anyone you want, so that later you can start filtering it.
This is security by obscurity, since this can be removed by a regex. I would like them to fix this.
As for your other point, where you call the extra data "nontrivial", I am afraid you are wrong, it is almost the definition of trivial. If you have a gmail account, go to it and type a name or any word into the search field. You will instantly receive search results from the entire history of your email archives.
That is because your email archives are fully indexed for fast searching. This takes a not-insignificant amount of space.
Adding a few bytes of aliases is absolutely trivial compared to the amount of storage and lookup that Gmail does on your behalf. It's almost the definition of trivial.
This isn't 1964!
Earlier quoted context omitted.
I presume canary is an established term in this context but since I don't know what it is I don't understand your service. It sounds good though.
Canaries were used in mines to signal pockets of unbreathable gas; they would die before the humans giving them an opportunity to escape. Canary has developed into a standard term for warnings which are detecting the danger allowing mitigation as opposed to predicting the danger which would allow avoidance.
More succinctly, a canary is an early warning system.
Earlier quoted context omitted.
I strictly started handing out "companyname@mypersonaldomain.tld" as email when interacting with companies. That at least makes routing the inevitable spam to the trash bin slightly easier when a breach occurs. It also provides an indicator of who has (in)voluntarily given away my data.
Yeah, I should stop being lazy and host a personal domain again. It just is such a bad situation these days. Either you: 1. Pay a reasonable rate for a full time server in services that are just truly awful, have no redundancy options, and are associated with a lot of unsavory activity or... 2. You pay a totally unreasonable rate to host it in a more reputable cloud service. 3. You run it out of your home or office a…
Earlier quoted context omitted.
A catchall on my domain was all fun and games till the second dictionary spam run.
The way I get around that is by having a static keyword that must also appear on the user side of the email address. So, if I'm dealing with Walmart, I would give them: [keyword].walmart@example.com or walmart.[keyword]@example.com Then I configure my catch-all settings to reject any email addresses that don't have that keyword. Of course, the keyword is not secret, so it's possible for someone to infer what I'm doin…