We have an automatic reporting and notification system written in .net that sends emails with plain text. We are having to encrypt the messages that we send our clients.
The possible implementation approaches we have:
Send messages as S/Mime email with attachments.
Plain text email with that just contains a link to a web site that will display the message over https.
It seems like S/Mime is a simpler solution, as we won't need to create the web application or secure it.
Our concern is our interoperability with our clients email clients and more importantly their email filtering software.
Has anyone had success or issues deploying a Secure MIME messaging solution?
Given the wealth of different clients people use these days for email, like BlackBerry, Iphone, Android, Samsung, Nokia, Thunderbird, Outlook (Express), Apple Mail, web mail etc, I would go for the web application over https. It does take an extra step of clicking the link, and logging in, but it could be used from a lot more devices without extra configuration steps.
How are you going to solve the problem of provisioning the destination certificates? If you send mail to 1000 users, you need to send it 1000 times, and each time use a different public key, the one for the current destination (so that only he/she can decrypt it and read it). Having each individual report final user create a key for himself and send you the associated public key so you can associate the report mail with it is problematic. Some PKI infrastructure products can help, but only inside a (tighly run) organization.
Securing only your web site seems easier to manage, since you'll have all the ends under your control. You still have to handle authentication, but that can be handled at the HTTP level (eg. Digest, or even Basic over HTTPS).
SideNote: (you can edit this in an answer) Not all mobile clients support SMIME. sadly the native android mail client (on Nexus 4, Nexus 5 etc...) does not support S/MIME . also, I personally have issues with the samsung galaxy SMIME support. Best (external and paid for...) solution I have found so far for android is MySecuredMail.
Related
I have a Delphi application, that needs to send a generated PDF file by email to one recepient of a predefined list of recepients.
I do not want to mess around with MAPI (not all customers have configured this)
I do not want my customers to enter their mail account details (this means SMTP is no option either)
Therefore I consider to use / setup a PAAS web service to receive the email text, the pdf file and the index number of the recepient to actually do the work.
My question is: Does an out-of-the-box solution exist to do this in Delphi, or what would be a preferable way?
For instance I considered using Google App Engine but there seems to be no builtin support in Delphi. I would prefer an out of the box solution or a tested solution with decent documentation. The server part should be as simple as possible.
Edited: Some clarifications:
The resulting exe is installed at the customer computer. I think setting up an extra mail account therefore is no option, because someone could extract the credentials from the exe and abuse the mail account. The same seems to be true for web services that provide only one (login/password) access.
Using OAuth2 seems to be no option either because I do want to send the email without user interaction.
If credentials need to be saved in the executable, and the existing answers suggest so, they should at least provide only very limited rights.
Is this solveable at all?
Is this solveable at all?
No.
If you require that neither the user (by filling in a login form, as is the case with OAuth 2.0) nor the program (by providing hard-coded credentials) authenticates with the web service, the communication with the web service can not be secure.
I suggest to re-think the security requirements and make them much clearer in your question.
To send mail you can use a webservice like http://www.mailgun.com/ or http://aws.amazon.com/ses/
They provide you with a http(s)-api that you can use to send email messages.
You can use Google App Engine with some programming in Python, PHP, Go or Java:
define a HTTPS address where your GAE application listens for POST requests
POST the PDF and the Email text with TIdHTTP
receive the PDF amd theEmail text in the GAE HTTPS server and forward it to the recipient
Here is an excerpt of a Python example for Google App Engine which handles a POST request
class Guestbook(webapp2.RequestHandler):
def post(self):
self.response.write('<html><body>You wrote:<pre>')
self.response.write(cgi.escape(self.request.get('content')))
self.response.write('</pre></body></html>')
Regarding OAuth: GAE supports OAuth but it is not required.
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
I'm currently building an oAuth2 server so that external clients/devices can access data from my service without having to send over user credentials with every request. I've finally grasped how oAuth works after spending an entire day reading numerous tutorials and online documentation, however, there's still one thing that I'm rather unsure of...
When sending a request for an authorization code to an oAuth server, how should I deal with a callback to mobile devices and devices that aren't a webserver?
E.g. this request to my oAuth server will send an authorization code as a callback to a specified webserver (http://client-url.com in this case)
http://mydomainname/oauth2/?client_id=test&grant_type=authorization_code&client_details=test&redirect_uri=http://client-url.com&response_type=code
The server at http://client-url.com will receive a response containing an authorization code and the developer will be able to store a user's oAuth credentials accordingly.
Obviously a mobile device isn't a webserver, so is there a standardised way of dealing with this? I've read online that you can define something called a custom URI scheme within iOS and Android apps. But what about the other mobile platforms out there? And desktop apps? I want my API to be accessible from as many platforms and devices as possible.
The reason why I'm asking this question is because I want to add validation to my oAuth server so that users can only register apps with valid callback URL's. I wasn't sure if should allow any other type of input as a callback apart from a valid URL.
Can anyone shine any light on this? I want to avoid spending hours validating and testing this across all devices as I'm sure anyone that has developed for multiple mobile platforms in the past must have some knowledge about this.
Thanks in advance.
I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation
The way I plan to use it is:
At the seminar, have people send SMS to a number to vote.
On the backend (assuming that the data comes back to my Web server), I will display the voting results on my Web site.
After say 10 minutes, I would like to press a button on my Web site so ONE of the people who sent an SMS earlier receive an SMS saying that person is a winner.
I'm an ASP .Net developer, so I just need an API to code against. One such company I saw that does this (but is limited to US) is:
* http://www.twilio.com/sms/
Do you know any international providers that are similar to Twilio SMS? I'm based in Sydney, Australia.
I've used SMSGlobal http://www.smsglobal.com before. Check out their API (the documentation is available on the website) to see if they have this functionality - I think from memory they do.