Accidental “certificate spill” is a common problem in file transfer security. It occurs when an untrained or careless individual accidentally sends the private key associated with a public/private certificate pair to someone who only needs the public component.
Certificate spill is a dangerous problem because it exposes credentials that allow unauthorized individuals to act with the identity and permission of trusted individuals and systems.
Today, it is common for a file transfer server administrator to ask an end user for “his or her certificate” so the administrator can add the end user’s public certificate credential to the user’s file transfer profile. This will allow future connections to a file transfer server to be negotiated with strong authentication in place. However, end users frequently send both their private and public keys to a request like this. This kind of certificate spill often occurs in cleartext email and is often accompanied with an infuriating note like “I don’t know exactly what you’re looking for, but here’s all the files in my certificate folder”.
A worse case occurs when an untrained administrator broadcasts both the public and private components of a server key or server certificate to every actual or potential end user “to help them connect”. (This happens more frequently than you might believe.)
To prevent certificate spills, proper training and proper deployment of technology that make it easy for end users and administrators to perform certificate exchange are both critical.
BEST PRACTICE: If you use keys or certificates to authenticate, secure and/or vouch for information, you must ensure that all personnel who handle these credentials know the difference between public and private keys and know when to use each type of credential (leaning on features available in software and systems whenever possible). Administrators of these systems should also have a short “certificate spill containment” procedure in place in case a private key is accidentally transmitted. This procedure should include assessment, communication, remediation (e.g., generate/distribute a new certificate and cancel/revoke the old one) and verification.
A “clear text password” is a common problem in file transfer security. It is a dangerous problem because it exposes credentials that allow unauthorized individuals to act with the identity and permission of trusted individuals and systems.
The problem happens in at least five different areas:
Clear text password during input: This problem occurs when end users type passwords and those passwords remain visible on the screen after being typed. This exposes passwords to “shoulder surfing” and others who may share a desktop or device. Most applications today show asterisks while a password is being typed. Modern implementations (such as the standard iPhone password interface) show the last character typed for a few seconds, then replace it with an asterisk.
Clear text password during management: This problem occurs when an operator pulls up a connection profile and can read the password off the profile when he/she really only should be using an existing profile. To avoid this problem application developers need to code a permissions structure into the management that permits use without exposing passwords. Application developers also need to be careful that passwords are not accidentally exposed in the interface, even under a “masked” display. (Perform a Google search on “behind asterisks” for more information on this.)
Clear text password during storage: This problem happens when configuration files, customer profiles or FTP scripts are written to disk and no encryption is used to protect the stored data. Application developers can protect configuration files and customer profiles, but when FTP scripts are used, alternate authentication such as client keys are often used instead of passwords.
Clear text password in trace logs: This problem occurs when passwords are written into trace logs. To avoid this problem application developers often need to special-case code that would normally dump clear text passwords to write descriptive labels like “*****” or “7-character password, starting with X” instead.
Clear text password on the wire: This problem occurs when passwords are sent across a network. To avoid this problem secure transport protocols such as SSL/TLS or SSH are often used. The most frequent cause of this problem is not application defects but operator error: when an administrator accidentally configures a client to connect without using a secure protocol, credentials are often sent in the clear.
BEST PRACTICE: All modern file transfer clients and file transfer servers should steer clear of these problems; these are entry-level security concerns and several application security design guidelines (e.g., “Microsoft’s Design Guidelines for Secure Web Applications” and the SANS Institute’s “Security Checklist for Web Application Design”) have covered this for years.
A “double post” is the act of sending a file in for processing twice on a production system.
Most operators consider a “double post” to be far worse than a missing file or missing transmission, because files sent in for internal processing often cannot be cleanly backed out. Double post violations involving hundreds or thousands of duplicate payment, payroll and provisioning transactions are relatively common experiences and are feared by all levels of management because they take considerable time, expense and loss of face to clean up.
There are many technologies and technologies used today to guard against double-posts. These include:
Remembering the cryptographic hashes of recently transmitted files. This allows file transfer software to catch double-posts of identical files and to quarantine and send alerts appropriately.
Enforcing naming and key-record schemes on incoming files. This often prevents external systems from blindly sending the same file or batch of records again and again.
Synchronizing internal knowledge of records processed with external file transfer systems. This advanced technique is EDI-ish in nature, as it requires file transfer technology to crack, read and interpret incoming files. However, it allows more sophisticated handling of exceptions (such as possible “ignore and go on” cases) better than simpler “accept/reject file” workflows.