I am looking forward to have the less information as possible on my application resulting in pulling most of the data from a website or server and I would like to hear by advices and recommendations from everyone with experience in the field to help me improve my application.

Currently my authentication consists of:

• To start the application the user have to input their username and password (without a valid user and pass the app does not work) and click login.
• The credentials will be sent to my login page using HTTPS, the script only accept SSL connection and a personalized User-Agent name.
• The login page will verify the credentials and send back a session and some initial data.
• The session is reused to gather more data over time or as needed.

Side note: the SSL is 256 bits, the session auto expire after a few minutes

For the above basic authetication and data pulling would you recommend me anything else to implement ?

Should I change anything ?

2nd Layer of protection

Now I would like to implement more security by encrypting all the data sent from/to my application, my question:

• What should I use to encrypt and decrypt the data, a pair of private and public keys held on both sides or RIJNDAEL's method ?

• What is the proper way or what parts of information should I leave on the client and server or how should I form the knowledge of the common passwords or keys ?

  For example if I was using a pair of RSA keys, I would need to leave 1 private key at the client and 1 public key since you cannot decrypt any data with the public key on c# while you can do it on the server and for Rijndael would need to have the IV and the key on both side.

  What is the proper way to handle these ?

I will be very glad with practical reading material, comments, examples, suggestions, a开发者_如何学Godvices :)

UPDATE:

No one else wants to say anything ? I was hoping to get more input on this question and also tough that this was a fairly used method around ...

Sounds like you've considered the security of the app side of the equation at length. I'd suggest you turn your thinking to the website part of the equation.

When I look at security, I always look at two things:

• Transport security--is your data protected while in transit? Sounds like it is, assuming you are using sufficient key length for the SSL cert on the server. Also, you can force the website do client cert validation as part of the SSL handshake. That ensures that no one can spoof the client app and convince your website to share information.
• Payload security--should you encrypt the data payload? Is there a chance someone may be able to break into your web server, or better yet, via the DNS poisoning or some other method, convince your app to connect to a malicious server with a valid (for that cn), but different HTTPs certificate? Should you choose to encrypt the payload, you can piggy back the whole thing onto the same certificates you already use. Just make sure that the certs have data encryption bits turned on, and you can use private/public keys from the certs to encrypt the payload. So, if the malicious user replaced the cert, not only do they need to spoof the cn and the chain of trust, but also have the right public key from the app to decrypt the data you are encrypting with your private key and signing with server's public key.

Some other questions to ponder:

1. You are saying that the session is reused? Does it not expire? If not, you'd want to make it expire.
2. Can you leverage network security? Can you use a VPN tunnel or IP ACL to limit who can even gain access to the web server?
3. What about keyloggers? Passwords can be intercepted. The second authentication factor can be something a user has, like a key card or a fingerprint, or an RSA SecurId. If you don't want to go that far, you can present a user with a "site seal"-- an image that they have to recognize as associated with their account. Maybe even present several images and let them choose one that they've chosen during the signup process. You can also make them solve a small puzzle--something that will distinguish a human from a machine (CAPTCHA-type).

All these points minimize info stored on the client side--just a cert or two and a key to go with that cert.

The topic of security is vast, and we can start a whole discussion here on different implementation details. The above is just some points to think about.

Remember, that everything has cost. Security costs usability and CPU cycles. Proper balance is key, but that of course is up to you. Before you build Fort Knox, make sure someone is going to want to live there :)