Hi, I have researched about this in security.stackexchange but I still have a doubt. The application that I'm building to a client talks to several third party sources and I'm not sure how to store the passwords used by them. Hashing wont work, so I could encrypt so at least its not in plain text. If the attacker has access to the filesystem all third party passwords are indeed compromised. Any other better way to achieve this?

@NEO Look at how password managers like Keepass do it. Encrypt the passwords at rest and ask for a password on application startup to decrypt it.

You are still vulnerable to anything running on the system that can read the passwords from memory but at that point you are fucked regardless.

@NEO As @TerryChia mentioned in his message, if this is for on-line use only (when the user is logged in to your app, then encrypting with a derived key that you don't store is going to be a superior option to storing an encryption key in your system. If you need the creds to perform operations on the user's behalf when they're not logged on, however, you're not going to be able to get around storing a key.

@Xander In which case the correct but expensive answer is probably get a HSM.

@NEO In either case, architecture is critically important. It would be a mistake to build this as a monolithic application that can do everything you need, all on one box. The credential management (and ideally, the entire piece of the app that deals with the 3rd party services) should be isolated as a service that can be separately managed and firewalled, an d the app should only have a very limited API for talking to it.

@TerryChia And yes, if you need to store keys that protect the credentials, they should be stored in an HSM, not on a server filesystem.

I'm coding up some ASP5 (vNext) sites and thinking about including some IDS/Security in them.

I'm selling some software to colleges that will likely have terrible security practices.

So I'd like to include some default security that makes sense. Have any recommendations?

In TLS security, a server needs to identify himself using a certificate and a private key. The certificate makes sense cause that could be spoofed (if no CA included), but the private key can't be spoofed because the attacker can't know that one. If an attacker can't know the key, and thus, can't decrypt the connection. Why is it so necessary that the client knows the server for 100% sure to make TLS usable?

Ain't the certificate to be sure you're connecting to the right server. And the key to make your packets useless for the attacker not having the key?

But the one has no security influence on the other?

Or is it necessary that the client is 100% sure about the server because the two private keys are 'negotiated just-in-time'?