You are talking about two different parts of your Web application and each needs to be secured differently. Since you're running Linux, chances are the Web server you're using is Apache. Apache can provide logins for Web sites it hosts, but that's not recommended because it uses basic authentication, which has two weaknesses. First, it uses only base-64 encryption, which is so easy to cross-site scripting, if the application is coded with its specialized tags, these vulnerabilities can be managed.
The first rule of Web logins, in general, is to craft your own Web page, where you enter a user ID and password. This allows you to control how login credentials are entered, handled and passed along to your application server. Always use POST method in your HTML code to hide credentials in the Web browser. Never use the GET method, because it attaches the credentials to the end of a URL, exposing them to hackers who may cut and paste them to gain access to your Web site.
Remember, whether it's login credentials or form information, Web application data should never be trusted. Always check, validate and, if necessary, scrub all input data. Fortunately, ColdFusion has a series of built-in CFML tags and functions that check input and remove malicious characters. To learn more about how to use them, visit the Macromedia Web site ( http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_17502).
The second key issue with Web logins is session management and safely maintaining a session's state without it being hijacked or replayed. Here again, ColdFusion doesn't differ from any other Web application platform. A session ID should be generated for each login. It should be unique, random and encrypted, and always sent over SSL. It should also be stored as a session cookie and deleted at the end of the user's session or, better yet, whenever the user leaves the site. To learn more about this, read this tip I wrote for SearchSecurity.com.
If you handle these two issues, your Web logins with ColdFusion will be reasonably secure.
This was first published in February 2006