Securing thrift based Communication

Question

So, i have made a thrift based program with a client and a server and client can communicate well with server. Now, since the data transfer will be quite crucial, I wanted some kind of security in it.

So, I thought of login system, but the problem is I am not storing any kind of session data on server side(I don't even know, what should i store, after all the client request come and go and there is no way to differentiate them). So after much thinking, this is what i came up with

1. Using random numbers, i would generate some kind of random string when the server starts
2. Client side will enter the username and password which will be verified at the server end using PAM authentiation(just read something about it).
3. If verified, server will just send that random generated string to the client side
4. Client will send that string to server every time it tries to execute a RPC
5. If verified, server will do the work, else return some error code

Possible problem that i can think of

Currently, when server goes down, and client was in midst of some RPC, it would give some error message and when server restarts, we can do the task without any problem

Now, if the server goes down, then the string generated will be different. So i will again have to do the authentication part

So, what do you think of this entire schema for authentication? Are there any better or simpler way?

PS : I am not using any kind of database. I am using C++ on both sides. My Client side uses QT

Answer 1

Disclaimer - I do not have much idea as to how PAM works, so I only have some high-level questions about this approach. I apologize in advance if I misunderstood any part of your approach.

When you say you want to secure the data transfer, I feel like you want to have authentication and secrecy, you only have an approach for authentication now.

For instance, if client C1 is authenticating to server(assuming credentials are not sent in cleartext), the server sends the random string in step 3. What happens when someone else is sniffing on the network? Can a rogue client not send the random string and perform RPC calls to the server, posing as C1? If username and password are sent to server in cleartext, can someone on the network get access to the credentials also? Also, what about data that is subsequently sent? It is just encoded in thrift format and can be decoded by anyone on the network, correct? Is the data sensitive?

If so, I want to suggest the use of PKI/certificates. Using a self-signed certificate must be fine. If you only want the client to authenticate to the server and prove it is legitimate, you can make all the clients present their certificate. Certificate is basically a public key for that client signed by an authority that vouches for that client.The client has the private key stored locally, that will never leave the client. Now, when client presents the certificate to server, server looks at who signed the certificate(CA). If it is a CA the server trusts, it can send the random string or just the thrift data directly, encrypted using the client's public key. The client will be able to decrypt with its private key and it looks like random bytes to anyone else who is sniffing. The server will do this for every single client and only needs to store the name of the certifying authority it trusts. This could be your name and address. You can generate the self-signed certificate on every client using openssl. But this means you have additional setup work on each client. Generate a key-pair and certificate. You can explore this approach if this constraint works for you.