What is required to ensure users' information being sent over my website is secure with the use of account log ins

Question

I have inherited the responsibility of managing my company's website. There are some customers who are required to submit highly confidential information via the website using online forms. I have been asked to develop user accounts so that we can add "another" level of security. Basically what I'm looking for is:

1. Users should be able to log into a secure account on the website (similar to those used in online banking)
2. Users' confidential information must be secure while being sent over the website.

I need clarity on what exactly is required to achieve these mentioned above - any help will be appreciated.

Answer 1

Only provide the pages over HTTPS (most servers have a requires HTTPS option). HTTPS will make an SSL connection that will protect the information in transit. On the server side, what you need to do to store the information depends greatly on the type and sensitivity of the information, as well as how it will need to be used.

For example, is it information that the client will need to be able to later retrieve, is it financial information or PCI (payment card information)? Do employees of your organization need to be able to access it? Does the information need to be able to be shared with other (select) clients?

Answer 2

The nature of the question leads me to believe that this may be the sort of thing where it's appropriate to get outside help.

If for some reason you can't:

1. Most online banking sites use security that is not appropriate for other sites. The banks have a long history of relying on policy, insurance and activity heuristics to secure your account - that is to say, your online banking is secured not by your login, but by the fact that the bank won't hold you responsible for the results of a hack, they rely on their insurance. Don't use them as your high water mark for secure logins.

   Consider buying something, or using a product like http://www.formtools.org/ or http://www.formstack.com/. If you can't do that, have a look at simply using HTTP auth so your web server and OS take care of the authentication issue, though that leads on to the next point...

2. Use https. Buy a certificate from a CA and force https (this should be an option in your webserver config). This will keep your HTTP auth logins secure if that's what you end up using, but also ensure the data is safe in transit.

Since you don't currently have user accounts, leveraging your operating system's builtin tools, making sure directory security is correct on the server and exposing that via your web server is going to give you the most secure, complete, time tested and patched (with your regular OS/Web Server patches) solution in the shortest amount of time.

Answer 3

SSL is absolutely the correct first suggestion here, but SSL alone doesn't protect you from:

1. Direct attacks such as XSS, SQL injection, remote file inclusion

   If your app is vulnerable to an XSS attack, javascript code can be delivered over your SSL connection to the client where it can push the sensitive data off to another attacker-controlled server while still allowing the normal requests to happen over the SSL link, or it could steal the client's credentials and log in as them. SQL injection could allow the attacker to retrieve the data straight from the database or bypass authentication and log in as the user in question. RFI could give the attacker a shell account on your system which would allow any or all of the above.

2. Out-of-band attacks such as key loggers and viruses, both on the client systems and the server.

   If you happen to be running an unrelated vulnerable service on your system, such as an out-of-date mail server, an attacker could target that and gain a shell account on your system. A virus on your work desktop could steal your credentials the next time you log in to your server. A keylogger on the client's system could steal their credentials, and while this one is technically not your fault, the client will certainly blame you anyway and you may have a hard time proving that it wasn't stolen from you.

3. Newly developed attacks against SSL such as BEAST, CRIME and Lucky Thirteen.

   It is inevitable that there will be a period of time where you are vulnerable to these sorts of attacks. Your job when securing your client's data is to:

   • Keep on top of known new attacks that affect any product you use.
   • Assess each one as soon as possible and make a decision whether to continue running the affected service or to shut it down until a patch is available. (You may be able to delegate this decision to your clients.)
   • Update and/or patch as soon as possible.

---

It sounds like you are a lone sysadmin who cares about security, rather than an employee dedicated solely to security, which means all the above is probably quite daunting. A good way to approach this would be to rank each of the suggestions you receive in terms of value and try to implement one each month or so. Set a realistic time frame and try to stick to it.

• Code audit/penetration testing of the code your organisation wrote.
• Intrusion detection.
• Abnormal client behaviour detection (Unknown IP address, unknown User-Agent, etc).
• Regular and prompt OS and product updates.
• Minimise attack surface (remove unneeded services from your server).
• Encryption of the data when it's stored in your database and in any backups.
• Logging of any type of access to the data. Good database software and appropriate OS controls can enforce this. This can help absolve the blame if a breach wasn't your fault and track down who the culprit is and how they got in if it was your fault.
• Pervasive security throughout your organisation.

The PCI-DSS contains a good list of things that can improve your overall resistance to attacks.

Which of these you actually implement will depend on cost/benefit and risk analysis:

• How much is the data (or the client) worth?
• What is the likelihood of a breach?
• How much does the security measure cost?
• How much does it reduce the likelihood of a breach?