Let's assume that i use a telnet session and send an email with address alice#domain.com to bob#domain.com but in fact i am charly#domain.com...
On alice#domain.com i have a WCF web service running that's monitoring that specific mailbox using Exchange Web Services...
How can i tell that the message from bob#domain.com actually came from charly#domain.com?
I am using Visual Studio 2010, with .NET 4.0 and EWS managed API 1.1
The server is configured to use SSL and i have Exchange Server 2007 SP1.
i tried the two properties "Sender" and "From" but they are identical and both point to bob...
nothing in the message header actually points to charly... everything points to bob... any ideas? things that i might have overlooked?
If you want to make sure that identity spoofing is not possible using an email service, you can use cryptographic signatures. PGP / GPG and S/MIME are common technologies in use to implement this.
This requires every mail sent from alice#domain.com to be signed by her with a secret. The key or certificate she uses to do this must be trusted by your webservice. Your webservice can verify that a mail has really been sent by Alice by checking the validity of the signature. Only someone who possesses the secret of Alice can create such a valid signature. If the signature is wrong or missing, your webservice can trigger an alert.
Should the real Alice forget to sign an email, your service will trigger as well, because it cannot tell if it really was Alice who sent that mail. You also need to make sure that the secret in use can only be accessed by Alice. If you need further informations, you should read up on public key cryptography.
I don't think you can detect such practices with EWS Managed API at least I don't see anything that could be helpful in this situation. Unless valid sender is recognized with use of some cryptographic signatures or you can somehow mark messages from valid senders with your own extended property that only you (your software) create and uses you have to believe that mail was sent by whoever is showing up in Sender or From property
Related
From the docs:
Stripe can optionally sign the webhook events it sends to your endpoints by including a signature in each event’s Stripe-Signature header. This allows you to verify that the events were sent by Stripe, not by a third party. You can verify signatures either using our official libraries, or manually using your own solution.
Before you can verify signatures, you need to retrieve your endpoint’s secret from your Dashboard’s Webhooks settings. Select an endpoint that you want to obtain the secret for, then click the Click to reveal button.
The last paragraph suggests that the secret is truly something to be treated confidentially. Is there a reason why Stripe doesn't use a private-public key scheme for signing webhook events?
They could keep the private key in their DB, never displaying it on the UI. The UI would only show the public key. Every request made to a webhook by Stripe would be signed with the private key and verified at the receiving end with the public key. This way, malicious actors getting access to the public key would be irrelevant, as they could only use it for verification, whereas now — I assume — an accidentally revealed secret can be used for forgery.
I'm neither a Stripe employee nor a Stripe expert, but I think your question comes from an ideal world where HMAC has disadvantages compared to digital signature from the point of view you're standing on. I suppose the main reason behind this decision is the computational complexity. But for the sake of truth, why you don't consider this problem along with related factors? Stripe prevents replay attacks and publish their ip adresses. Taken together, these measures provide very real protection against message forgery.
I'm using the C# sdk for Docusign. My original plan is to make it receive POST data from another webapp, and from there, it will automatically send emails to the signers (akin to Remote Signing).
My question is, is there a way to do remote signing without having to run the webapp, go to the webapp url, and clicking the Remote signing option?
Well, you can, but then you won't be using remote signing.
You could use embedded signing and generate your own URLs.
Your server would get the information needed (presumably the envelopeID at least) and then on the fly generate an embedded signing and show it to the user in your own app.
This is not recommended, mostly because DocuSign is doing a lot on the email front, to ensure no spam/phishing issues etc. But you can do it if you wanted to for some reason.
We currently use the API for embedded signing in our web application. When reviewing doc reference guide for offline signing, I'd say it's less than crystal clear how that really works. If I'm offline when I obviously can't call the API, so how does one in fact "sign" with DS?
I can appreciate how our client app (again, which currently does embedded signing) can prepare an envelope 'request' offline, and then send that request once we have connectivity. However the REST API guide says the user in fact "signs" the doc while offline -- how does the user ever get to the Docusign interface to do signing?
from the docs
To use Offline Signing, the customer using a client application to
create an envelope on an Internet-capable device, such as a smart
phone or tablet, that is not connected to the Internet and has a
recipient fill out and sign (or initial) the envelope documents. When
the device later connects to the Internet, the client application
uploads the envelope information to DocuSign where it is processed.
Does our offline app (running, say, in/as a Chrome app) somehow connect to local client Docusign software onboard the laptop or mobile device while offline? Any pointers to more complete documentation?
From the docs:
"IMPORTANT: Access to the offline signing capability is limited by
integrator key information. If your integrator key does not have the
correct authorization, you cannot use offline signing. Access to the
offline signing capability will be evaluated on a case-by-case basis."
The reason is because your software would be responsible for providing the legal evidence that the transaction actually happened with the proper security checks. This requires a tighter business arrangement and agreement between your company and DocuSign.
Please get in touch with your business development manager and they can set up a time to talk.
-mb
I wish to code a little service where I will be able to send an e-mail to a specific address used by my server to send specific commands to my server.
I'll check against a list of permitted e-mail addresses to make sure no one unauthorized will send a command to the server, but how do I make sure that, say, an e-mail sent by "mrzombie#thezombie.net" really comes from "thezombie.net"?
I thought about checking the header for the original e-mail server's IP and pinging the domain to make sure it is the same, but would that be reliable?
Example:
Server receives a command from mrzombie#thezombie.net
mrzombie#thezombie.net is authorized, proceed with checks
Server checks "thezombie.net"'s IP from the header: W.X.Y.Z
Server pings "thezombie.net" for it's IP: A.B.C.D
The IPs do not correspond, do not process command
Is there any better way to do that?
If you can solve this for generic e-mails, you solved the problem of SPAM.
Given that the mail headers are free form text in which anyone can claim anything, you can't do any sort of authorization nor authentication based on the mail headers. Your best bet is to authenticate the content, and there are protocols for that like S/MIME or PGP. They rely on cryptography for authentication and your server will be able to verify that the content is signed by a certificate you trust. But you'll move the burden on the mail sender that will have to send a properly signed message. Most mail readers though support adding digital signatures to content.
but how do I make sure that, say, an
e-mail sent by
"mrzombie#thezombie.net" really comes
from "thezombie.net"?
You also may want to look at Sender Policy Framework, as it is at least in part trying to provide a means of verifying that email was sent from authorized domain servers.
Also, serverfault.com may have some helpful answers for you since it is a networking- and server-related question.
You can use SPF to verify that a given IP is/is not authorized to send email on behalf of a particular domain (assuming that domain implements SPF, of course), but that only gets you so far. For example, it may not prevent another user at the source domain from impersonating the authorized user.
Authenticating the content with a digital signature is really the best way to go.
When we talk about security we have the following requirements:
authentication
integrity
Non-repudiation
Isn't the third requirement included in the first two? If we know A sent the message (authentication) and it has not been changed since A sent it (integrity) then how can A repudiate sending it?
Please don't talk about dig-sig as it's in the technical level. I'm talking about the business requirements.
Neither authentication nor integrity protections prevent replay attacks. A malicious user can capture a signed and encrypted message and post it multiple times. Therefore a party can repudiate having sent the same message multiple times.
Making each message unique using timestamps and/or nonces addresses this and is therefore used for non-repudiation in combination with signing and encryption.
Non-repudiation is different than integrity and authentication because it implies that the sender is accountable for the contents of a message.
There are many systems that use a key for authentication and integrity, but the authenticated content doesn't mean anything. For example, suppose that in order to authenticate you on my system, I send an unpredictable challenge and ask you sign it and send it back. If the signature is valid, I trust that you know some secret and therefore are who you claim to be. I'd require the key you use for signing these challenges to be designated for digital signatures, but not necessarily for non-repudiation.
Now suppose instead of choosing a random challenge, I try to trick you by sending the challenge, "I will pay erickson one million dollars." If your system signs that, do I have a claim to a million dollars? The signed message is authentic and not tampered with, but unless you signed it with a key flagged for non-repudiation (for example, setting this flag in the key usage extension of an X.509 certificate), you can deny that you were aware of its content and reject my claim.
Non-repudiation makes sense for things like a signatures on documents in a business transaction—cases where you are obligating yourself to some action or payment.
With authentication and integrity, what you can achieve is message authenticity, ie. the recipient can be confident that the sender ID and message content are genuine.
Non-repudiation, on the other side, ensures that none of the involved party can deny having sent or received the message. In the previous scheme:
While the recipient can prove that the sender has indeed sent the message,
The sender itself has no proof that the recipient actually received it.
Non-repudiation systems will therefore include some kind of acknowledgment in order to provide these proofs.
Usually the three security requirements are CIA, i.e.
Confidentiallity
Integrity
Authenticity
But concerning non-repudiation, authentication and integrity dont necessarily provide non-repudiation since integrity says some message has not changed when traveling from point X to Y.
Authentication can tell you that some message is sent by anybody who has knowlegde of some (shared) secret that should be only known to a person.
Imaginge a virus stealing private keys from Alice, in that case you can have integrity of message X and authentication that the message is from Alice (although one can argue if this is real authentication) however, some eavesdropped used the stolen private key to send the message.