I've setup a web server and can exchange data between it and my iPhone by using JSON.
Is JSON already encrypted? I'm trying to make an app that people can use. I'm not sure how to securely verify a user. Right now I'm having them send some information that uniquely identifies them along with their GET requests.
But couldn't someone easily pick this up, and then replay the GET request to the server to access the same information?
What's the right way to do this?
JSON is not automagically encrypted, no.
Secure your server with SSH. This should prevent most MITM type attacks. If you are extremely worried about replay attacks from the client side (browser), you will probably need oAuth + a secure nonce.
No security measure will protect you 100%, you have to compromise security vs performance.
If you are worried about MITM attacks, most likely someone sniffing requests on your network and then replaying them, you could set up SSL and send the JSON request via that, which would prevent the attack.
The only other thing is that via GET your security variables will be exposed in the URL.
Whether it is ideal form is what kind of information you are transferring and what other authentication you are using.
http://joekuan.wordpress.com/2010/05/08/quick-steps-on-setting-up-apache-ssl-php-json-on-freebsd-8-0/
Related
I've edited this question. I hope this version is a bit more clear.
I am seeking to have a programmer build a process for me. I need to ensure what is recommended is a best practice for the below process.
Here are the steps I need to have built:
Have a https: webform on my server that submits client inputted data into a database on my server. The data is personal identifiable information and needs to be securely transmitted in the next step.
Once the data is loaded in my database, I need to transfer the data in an encrypted/Json format to a third-party server. The third-party will unencrypt the data, score it and send it back to my server encrypted.
While the data is being sent and scored by the third-party, the client will see a browser screen indicating processing...
Once the data is scored and sent back to my server, it will be unencrypted and it will update the client's browser with options based on the score given by the third-party.
Based on what I understand, I think an API on both my server and the third-party server might be best.
What is the best practice approach for the above process?
Below are some questions I have which would be very helpful for me to understand in your response.
Is the API approach the best?
What process is used by the third-party to unencrypt data I send and vice versa? How do I prevent others from unencrypting the data if it is intercepted?
3)While the data is being scored by the third-party, the client browser will show processing. From a web development standpoint how does this work? Also, from a web development standpoint, how exactly is the processing screen triggered to update with results on the client's browser screen when the data is sent back from the third-party?
The file that you will be transmitting, as you mentioned is encrypted so it will totally depend on the encryption algorithm you are using, generally encrypted data are stored as BASE64 or HEX so after encryption the data will be passed in the above-mentioned format.
To answer you second question on "how will the receiving website receive the file?", there are several ways you can do this:
You can share the backend database your website is using then it will just be a simple query away (by shared I mean both the websites use the same database).
Another way of achieving this is to use an API which can store your data and can be globally used in any application it is called at
Or you can set up a simple php server locally at your machine and send data between websites using the HTTP: GET or HTTP: POST requests.
also avoid using un-necessary tags like web-development-server or data-transfer or transmission etc. these tags are useless and unrelated to your question. You should only tag those which are related to your question, a simple tag for web-development would be enough.
also edit out your question to make us properly understand, what problems you are facing? what have you tried? what do you expect from us in the answer?
please clarify your question more.
Your concept of files being sent around is kind of wrong, because in most cases none of this is ever been written to disk, and so there is no JSON file with a file-name - and these are not directly being encrypted, but only pushed through an encrypted channel. Most commonly both sides either use HTTPS or WSS as the protocol, which encrypts / decrypts the data being exchanged transparently (all by itself). And depending on the protocol which is being used, this requires either a combination of client & server, server & server - or a P2P network - to be installed.
Further reading: Internetworking Basics - Computer and Information Science.
I'm trying to wrap my head around oauth2 and am comparing the server and client side flows. To me the server side flow sounds much more simpler - the user authorizes once and then everything remains on the server (converting the code to an access token, requests to the remote api, etc).
So, why would someone want to use the client-side flow?
One possible answer to that might be to reduce server traffic. Does anyone have any evidence that client-side reduces a significant amount of traffic from the server?
I think that it would be unlikely for approvals and access token grants to make up any sort of significant fraction of a server's traffic load unless it's implemented in a very obscure way. One might use the client-side flow if the application is very javascript-centric and has no other reason to contact a web server specifically for its service. For example, you could imagine some browser extension written in javascript that uses OAuth 2 to request someone's favorite YouTube videos, Facebook friends, or some other data, and display it to the user in some fashion. It may not make sense to dedicate a web server for serving those grants if it would perform no other function for the application.
My users are using MS Access and ODBC connector to connect to my remote MySQL database. I wonder how secure this is, in the sense of possible password disclosure to 3rd party. Is the mysql protocol authentication safe to eavesdropping or even man-in-the-middle attacks? I would be quite happy with safety against eavesdropping. Note that my concern is only authentication, I'm not concerned about data disclosure.
Please don't reply that I should use SSL. I know this would be ideal however the setup doesn't seem very simple. Anyway, I would like to know what is the safety level of plain mysql protocol.
What is it that you want to be "safe to eavesdropping or even man-in-the-middle attacks"? Your password, or your data?
The title of your question refers specifically to authentication. MySQL does a reasonable job of protecting your password from eavesdroppers (it is not sent plaintext, and the use of a nonce defeats replay attacks). Citing MySQL protocol internals:
MySQL 4.1 and later
Remember that mysql.user.Password stores SHA1(SHA1(password))
The server sends a random string (scramble) to the client
the client calculates:
stage1_hash = SHA1(password), using the password that the user has entered.
token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash
the client sends the token to the server
the server calculates
stage1_hash' = token XOR SHA1(scramble + mysql.user.Password)
the server compares SHA1(stage1_hash') and mysql.user.Password
If they are the same, the password is okay.
(Note SHA1(A+B) is the SHA1 of the concatenation of A with B.)
This protocol fixes the flaw of the old one, neither snooping on the
wire nor mysql.user.Password are sufficient for a successful
connection. But when one has both mysql.user.Password and the
intercepted data on the wire, he has enough information to connect.
However, authenticated sessions continue in plaintext: an eavesdropper will be able to see all queries and results; and a MITM would be able to make alterations to the same. As stated in the manual:
By default, MySQL uses unencrypted connections between the client and the server. This means that someone with access to the network could watch all your traffic and look at the data being sent or received. They could even change the data while it is in transit between client and server.
Whilst you may not like the answer, SSL is the tool designed to defeat both data eavesdropping (how else can the communications be encrypted?) and MITM attacks (how else can either party verify that its peer is who it thinks it is?). Indeed, if the mysql client-server protocol alone defeated these threats then there would be no reason to use mysql over SSL (and thus it would be unlikely to be a supported configuration).
Short answer: Yes, the protocol is safe from Eavesdropping and MITM attacks.
Only if the attacker manages to sniff an authentication attempt AND if the attacker knows the contents of mysql.user, then he can subsequently authenticate against the server. For example if you're using the same password on two different mysql servers and the attacker gains access to one of them, he can also connect to the second server.
Would be a good or bad idea to use localStorage for sensitive data (assuming the current HTML5 implementations)?
What methods can I use to secure the data so that it cannot be read by a person that has access at the client computer?
Bad idea.
Someone with access to the machine will always be able to read the localStorage, there is nothing much you can do to prevent it. Just type 'localStorage' in firebug console, and you get all the key/value pairs nicely listed.
If you have an XSS vulnerability in your application, anything stored in localStorage is available to an attacker.
You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.
If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.
Public Key Cryptography can be applied to prevent any kind of intrusion. Also, data integrity checks (such as CRC or hashes) may be used to make sure data is validated by the server.
First let me explain the data flow I need
Client connects and registers with server
Server sends initialization JSON to client
Client listens for JSON messages sent from the server
Now all of this is easy and straightforward to do manually, but I would like to leverage a server of some sort to handle all of the connection stuff, keep-alive, dead clients, etc. etc.
Is there some precedent set on doing this kind of thing? Where a client connects and receives JSON messages asynchronously from a server? Without using doing manual socket programming?
A possible solution is known as Comet, which involves the client opening a connection to the server that stays open for a long time. Then the server can push data to the client as soon as it's available, and the client gets it almost instantly. Eventually the Comet connection times out, and another is created.
Not sure what language you're using but I've seen several of these for Java and Scala. Search for comet framework and your language name in Google, and you should find something.
In 'good old times' that would be easy, since at the first connection the server gets the IP number of the client, so it could call back. So easy, in fact, that it was how FTP does it for no good reason.... But now we can be almost certain that the client is behind some NAT, so you can't 'call back'.
Then you can just keep the TCP connection open, since it's bidirectional, just make the client wait for data to appear. The server would send whatever it wants whenever it can.... But now everybody wants every application to run on top of a web browser, and that means HTTP, which is a strictly 'request/response' initiated by the client.
So, the current answer is Comet. Simply put, a JavaScript client sends a request, but the server doesn't answer for a looooong time. if the connection times out, the client immediately reopens it, so there's always one open pipe waiting for the server's response. That response will contain whatever message the server want's to send to the client, and only when it's pertinent. The client receives it, and immediately sends a new query to keep the channel open.
The problem is that HTTP is a request response protocol. The server cannot send any data unless a requests is submitted by the client.
Trying to circumvent this by macking a request and then continously send back responses on the same, original, requests is flawed as the behavior does not conform with HTTP and it does not play well with all sort of intermediaries (proxies, routers etc) and with the browser behavior (Ajax completion). It also doesn't scale well, keeping a socket open on the server is very resource intensive and the sockets are very precious resources (ordinarly only few thousand available).
Trying to circumvent this by reversing the flow (ie. server connects to the client when it has somehting to push) is even more flawed because of the security/authentication problems that come with this (the response can easily be hijacked, repudiated or spoofed) and also because often times the client is unreachable (lies behind proxies or NAT devices).
AFAIK most RIA clients just poll on timer. Not ideal, but this how HTTP works.
GWT provides a framework for this kind of stuff & has integration with Comet (at least for Jetty). If you don't mind writing at least part of your JavaScript in Java, it might be the easier approach.