I have developed security sensitive App. I had to use TEA based algorithm to encrypt/decrypt data to communicate with server and follow Server protocols. I have used AsyncSocket for trasport level communication which uses CFNetwork APIs. I have noticed that TEA algorithm is not very secure and can be hacked easily. Moreover, AsyncSocket library isn't using Apple's Security Framework anywhere. I am planning to rewrite transport layer and redefining client-server security protocols. I have been researching on what kind of security algorithm should I use for data protection which has no or minimum performance impact and difficult to break. Moreover, I am going through Security frameworks but couldn't find any example that uses this framework to implement transport layer. Could someone please assist me on this? What are the things I should follow to code secure transport layer? what are the security measures that I could check against my App?
As #CodesInChaos notes, you should use TLS for this. You absolutely should not design or implement a new transport protocol.
The fact that CFNetwork supports TLS does not mean that you are using it. You need to actively use it. Your server needs a certificate that your client trusts, and it needs to negotiate a TLS session. In general, if you just use HTTPS and the standard NSURLConnection routines , then you're going to get most of what you need for free. But if you start building it by hand in CFNetwork, you need to make sure that you're configuring it correctly. My recommendation is to use HTTPS whenever possible. It's simple and makes a wide variety of problems go away.
That said, just because the transport is secured does not mean that your app is "secured enough." In particular, your server still needs to be able to deal with malicious clients talking over a secured transport. You need to properly authenticate the user and you need to handle malicious data gracefully. When the data reaches your server, you need to store is securely. You may need to encrypt data on the client. There are many aspects to securing a system beyond the transport.
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
We are building our applications in micro-services based architecture to implement our applications. As true with micro-services, we now see a lot of cross service interactions happening between services.
In order to safeguard the endpoints we plan to implement JWT based authentication between such secure exchanges.
There are 2 approaches we see helping us achieve it:
Embed an JWT engine in each application to generate the token (#consumer side) and evaluate (#provider side). With an initial exchange of keys, the token exchange shall work smooth for any future comms.
Have an external (to application) JWT engine, that sits in between all micro-service communications for the distributed application, and takes care of all token life cycle, including its encryption-decryption and validation.
There are lot of options to do it as per option #1 as listed on https://jwt.io but considering the over-head token generation and management adds to a micro-service, we prefer to go with 2nd option by having de-centralised gateway.
After quite some research and looking at various API gateways we have not yet come across a light weight solution/tool that can serve to our need and help us get centralised engine for one applications comprised of many micro-services.
Do anyone know about one such tool/solution?
If you have any other inputs on this approach, please let me know.
I prefer also option 2, but why are you looking for a framework?
The central application should only be responsible of managing the private key and issuing the tokens. Including a framework for solve one service could be excessive
You can also think to implement a validation service, but since applications are yours, I suggest to use an assymetric key and verify the token locally instead of executing remote validation requests to central application. You can provide a simple library to your microservices to download the key and perform the validation. Embed any of the libraries of JWT.io or build It from scratch. Validating a JWT is really simple
If you would need to reject a token before expiration time, for example using a blacklist, then It would be needed a central service. But I do not recommend this scheme because breaks JWT statelessness
Both scenarios could be implemented in Spring Cloud Zuul.
For more info:
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_router_and_filter_zuul
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_configuring_authentication_downstream_of_a_zuul_proxy
I'm at the beginning of trying to understand the requirements for developing a VoIP app. From what I've learned so far, frameworks that allow for communication using SIP/TCP are the best (I don't intend to implement SIP myself).
However, although SIP can be peer-to-peer, its recommended to use an SIP server service. But I'm finding it difficult to locate information about what SIP services are appropriate for an iOS application / what is required from me in terms of setup of the server so that I can concentrate on client-side development.
Any advice would be much appreciated.
You need to figure out your use-cases to decide. A SIP server is like an HTTP server, it will analyse the request URI, the request headers and whatever hints it can see to execute some resource at the backend. Think if you plan to have a user database and authentication. Do you want presence? Do you want voicemail, call transfers, pbx features? Do you want video, audio, IM? Do you want to support arbitrary endpoints? Encryption, NAT traversal, HA? Only then you can think about actual servers and hosting. Many "minimal" configurations will include at least one SIP/media front-end (for NAT/SBC), a SIP/media server (to act on requests), a database server (to store persistent state) and an HTTP server (for config/admin UIs). While there are products that combine some of these into single server, they are generally at least reasonably isolated modules.
I am working on an chat program with socket programming (Indy in Delphi).
What security solutions can I use to satisfy its security? From user authentication (I used a server to authenticate users) and type of packets security that can be used?
I don't have any idea what can make my app vulnerable.
Indy supports OpenSSL so yo only need to add and configure a OpenSSL handler, and make sure that the firewall allows connections over the secure port.
A popular source of information is the Open Web Application Security Project (OWASP).
Their pages include lots of technical article, for example
https://www.owasp.org/index.php/Category:Vulnerability
about vulnerabilities
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.