We're working on a site that will make use of the OFX standard to provide access to customer financial data. However, for security we make use of secret question/secret answer, machine tagging, etc. Does the OFX standard provide any mechanisms for security beyond just the simple username/password? I've taken a look at the schema and some sample data, but haven't seen anything that looks like it would fit our needs. Anyone with any experience in this area?
4.1.5 Channel level: Generally transparent to a client or server, channel-level security is built into the communication process, protecting messages between two ends of the “pipe.” To secure messages during HTTP transport, client and server applications use the Secure Sockets Layer (SSL) protocol. SSL transparently protects messages exchanged between the client and the destination Web server. SSL authenticates the destination Web server using the Web server’s certificate. Additionally, it provides privacy via encryption, and SSL-record integrity, i.e. the block of data sent in each transmission cannot be altered without detection.
Application level: Transparent to and independent of the transport process, application-level security protects the user password sent from the client application all the way to the server application that handles the OFX messages. The server application typically resides beyond the destination Web server, secured behind an Internet firewall. Application-level security requires channel-level security.
They have 2 levels of security. You probably would not need more than that. You put in extra security, you would delay sending your financial data. There is ample leverage to check and verify messages with OFX and it probably should suit your application.
Related
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
I'm looking for a simple authentication protocol (OpenID, Active Directory, ??) for users to log into my website. It's hosted on Windows Azure. High levels of security are required. What can you recommend and why that particular choice?
Note: At this point in time I will not be using SSL so no plain-text passwords can be transmitted. I will however be transitioning to an SSL environment in the future.
Is the data that your site/service is going to be transmitting across the wire private, sensitive, proprietary, etc? If so, it is ESSENTIAL that you implement SSL in order to prevent anyone with a packet sniffer from being able to syphon data straight from the wire.
In order to perform secure authentication you will need to employ something like SSL to establish a secure communications transport over which you can request and receive a SAML (or similar) identity token from an identity provider.
If you don't use SSL to protect your communications, it's trivial for a malicious 3rd party to steal the identity token and masquerade as the authenticated user and/or to log/monitor/modify every request for any user of your system!
What are your reasons for not using SSL?
I am developing Restful API layer my app. The app would be used in premises where HTTPS support is not available. We need to support both web apps and mobile apps. We are using Node/Expressjs at the server side. My two concerns are:
Is there a way we could setup secure authentication without HTTPS?
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
I think you are confusing authenticity and confidentiality. It's totally possible to create an API that securely validates the caller is who they say they are using a MAC; most often an HMAC. The assumption, though, is that you've securely established a shared secret—which you could do in person, but that's pretty inconvenient.
Amazon S3 is an example of an API that authenticates its requests without SSL/TLS. It does so by dictating a specific way in which the caller creates an HMAC based on the parts of the HTTP request. It then verifies that the requester is actually a person allowed to ask for that object. Amazon relies on SSL to initially establish your shared secret at registration time, but SSL is not needed to correctly perform an API call that can be securely authenticated as originating from an authorized individual—that can be plain old HTTP.
Now the downside to that approach is that all data passing in both directions is visible to anyone. While the authorization data sent will not allow an attacker to impersonate a valid user, the attacker can see anything that you transmit—thus the need for confidentiality in many cases.
One use case for publicly transmitted API responses with S3 includes websites whose code is hosted on one server, while its images and such are hosted in S3. Websites often use S3's Query String Authentication to allow browsers to request the images directly from S3 for a small window of time, while also ensuring that the website code is the only one that can authorize a browser to retrieve that image (and thus charge the owner for bandwidth).
Another example of an API authentication mechanism that allows the use of non-SSL requests is OAuth. It's obsolete 1.0 family used it exclusively (even if you used SSL), and OAuth 2.0 specification defines several access token types, including the OAuth2 HTTP MAC type whose main purpose is to simplify and improve HTTP authentication for services that are unwilling or unable to employ TLS for every request (though it does require SSL for initially establishing the secret). While the OAuth2 Bearer type requires SSL, and keeps things simpler (no normalization; the bane of all developers using all request signing APIs without well established & tested libraries).
To sum it up, if all you care about is securely establishing the authenticity of a request, that's possible. If you care about confidentiality during the transport of the response, you'll need some kind of transport security, and TLS is easier to get right in your app code (though other options may be feasible).
Is there a way we could setup secure authentication without HTTPS?
If you mean SSL, No. Whatever you send through your browser to the web server will be unencrypted, so third parties can listen. HTTPS is not authentication, its encyrption of the traffic between the client and server.
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
Yes, as you say, it is layer, so it's interface will be independent from client, it will be HTTP and if the web-app is on same-origin with that layer, there will be no problem. (e.g. api.myapp.com accessed from myapp.com). Your native mobile can make HTTP requests, too.
In either case of SSL or not SSL, you can be secure if you use a private/public key scenario where you require the user to sign each request prior to sending. Once you receive the request, you then decrypt it with their private key (not sent over the wire) and match what was signed and what operation the user was requesting and make sure those two match. You base this on a timestamp of UTC and this also requires that all servers using this model be very accurate in their clock settings.
Amazon Web Services in particular uses this security method and it is secure enough to use without SSL although they do not recommend it.
I would seriously invest some small change to support SSL as it gives you more credibility in doing so. I personally would not think you to be a credible organization without one.
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
I am developing an API for a web application. Desktop clients will interact with the API using simple HTTP posts (REST). I will be using SSL, there is no question about that. My question is this: should I also be encrypting the data before it is sent over SSL? The information being sent may contain confidential information. Is SSL enough or should I be doing more? My only concern with adding additional layers of security is that it will make it substantially more difficult for people to interact with the API. Any thoughts on this would be much appreciated.
No, SSL provides strong encryption as it is. Just make sure you force clients to use HTTPS, and if you're really paranoid, check if the cypher is strong enough.
The only reason you'd want to encrypt a second time is if your web application passes the data straight on to some other system. In that case, you could keep the web application ignorant of the actual data and provide end-to-end encryption between the client and the final destination.
If you trust your certification authority, your clients do, and your key is sufficiently secure (RSA 2048 will not be breakable for a while), there are no problems at all with SSL. You don't need to encrypt your data before SSLing, as SSL itself provides encryption.
If this API is to be used over the internet, the list of certification authorities here will be useful to you in choosing one.
You can also have your clients authenticate over SSL, with SSL client certificates.
IMHO, I would not add another layer of encryption on top of the already existing encryption. It will add overhead and as you say, complexity to the API. SSL exists to send secure data between two nodes, so why reinvent the wheel?
As Shtééf already pointed out, if you need end-to-end encryption instead of point-to-point then you need encryption. Other cases this might be relevant in is if your client application communicate with the server through integration services and service busses. In this case the SSL encryption is not enforced while the message is in an intermediary node and that node may do whatever it wants with the unencrypted confidential data.
Furthermore, if your clients use these integration services then they might not enforce SSL connections between the client and the integration service.
While working with highly confidential information I tend to go for end-to-end security instead of SSL encrypted communications channels for this reason.
Yes.
SSL would help with man-in-the-middle and wiretapping but there are other attacks SSL won't help with such as replay attacks.