If you engineered a bridge you wouldn’t leave the guardrails off and hope nobody goes near the edges; engineering security for software is the same. But while valuable and important, security is a difficult thing for many clients (or potential clients) to analyze, and a fairly thankless task for an interactive company to do well.
Good security is difficult and costly to implement, can create painful workflows that have the usability team glaring hatefully in your direction, and can be almost impossible for marketing and sales to sell. Security isn’t a single feature that’s developed for a website; it needs to be at the heart of any interactive firm, part of the culture and tools of the team building the application.
Security is most often noticed when it fails. Taking care of security upfront may mean some extra work, time and thought, but the payoff is worthwhile. It’s far better to endure the pain of engineering a secure site than it is to deal with the pain (and PR headache) of compromised or stolen data.
Here are three important security factors to look for:
- Login credentials and personal information should always be transferred over a secure connection.
- Passwords should never be stored in plain text or in any manner that allows them to be recovered and read.
- Companies should have proper credentials and background in building secure web applications. (ex. PCI-DSS, SAS70 )
So, how to test for these things?
These are generally easy to check for; if you are on a website and the URL reads https:// instead of http:// and you have a graphic of a padlock somewhere on your browser (exact placement varies but is often in the lower right corner of the browser window) you know that your connection is secure.
Secure Password Storage
Passwords being stored in plain text can be more difficult to check for, but here is one way:
- Find a site the company has built which allows member registration and sign up. (This can be a great usability and workflow test as well.)
- Locate and test the “Forgot my Password” tools.
- If they have an option to recover your password it should e-mail you a password recovery message.
- Check your recovery e-mail and examine it for your original password. If your original password is included in the email, this often indicates that they aren’t following proper password security rules. A secure alternative might involve sending a unique one-time-use random password, or a link that allows you to log in temporarily and update your profile.
Finally, there are the security requirements and credentials for any company managing an e-commerce solution. In this case it is best to work with PCI-DSS certified companies. While PCI-DSS certification is not required by law, if you are doing anything that its standards say not to do, it is likely illegal. These standards help prevent companies from making mistakes. Here are some of the common mistakes that can lead to legal problems:
- Printing more than the first 6 and last 4 digits of a credit card onto a receipt.
- Collecting and storing a credit card’s CVV code (the three-digit code on the back of a Visa or Mastercard, or four-digit code on the front of an AmEx).
- Storing card data unencrypted in a spreadsheet or e-mailing card data out when a purchase is submitted.
There are hundreds of rules and regulations that are covered by these certifications that protect you from making mistakes and the legal fallout of failing to protect personal information (ex: TJ Maxx, Heartland Payment Systems). The PCI-DSS specification itself requires that you have all web services scanned quarterly for vulnerabilities that may compromise your applications.
In many cases, customers are required to obtain PCI-DSS certification themselves, but would fail to obtain this certification if they are working with a non-compliant interactive company. Another excellent reference is the Open Web Application Security Project (OWASP), which covers the ten most common web application exploits in extensive detail. Any website developers working on applications that collect card data or personal information should be very familiar with the OWASP material and the content that they publish.
We strongly recommend taking the time to examine sites that your potential interactive agency has built. You should also discuss security with a technical lead and verify that they have an excellent foundation in secure coding practices and a staff that is well-informed on security best practices.
Next up: the final article in the series on Long-term Maintenance.