Password Security in Managed File Transfer
Last week was “World Password Day”, a day designed to get people thinking about password security and hopefully change their passwords. I was surprised to see an article from Sophos that the average person has 19 passwords to remember and almost a third struggle with strong passwords. With the raft of work systems, private emails, social media, online shopping and banking passwords I thought it would be many more. I did a quick tally of my online passwords and worked out I have in excess of 30 passwords, although most of the private account passwords are variations on 4 main passwords. I worked for one very large organisation who insisted passwords were changed every month but suggested that you simply add the month digit to the end of your password, negating the password security almost entirely.
The full article from Sophos can be found here.
Having strong passwords and authentication methods for file transfer accounts is very important. There are several approaches for user authentication that are supported by most Managed File Transfer (MFT) solutions.
- Application Controlled
- External source (AD / LDAP / Other source)
- Advanced Authentication using RADIUS or a One Time Password system
- Private key authentication
With application controlled authentication, the MFT solution will control the length, complexity, password history and password expiry using internal systems. Usually users will be prompted to change their passwords either by getting an email, or when they login.
This works well but, for users inside the organisation, passwords can drift out of sync and this can lead to increased issues as users are asked to remember more and more passwords to access different systems. In this case, we usually recommend that the MFT solution uses the internal Active Directory or LDAP source. This allows the user to use the same credentials that they login to their computers with. Responsibility for changing the password then resides with the AD/LDAP system and the MFT solution will not normally track the passwords. When a user presents their credentials to login to the MFT solution, the system will pass the username and password to the AD/LDAP source for verification. If the AD/LDAP system confirms the credentials are correct the MFT solution lets the user in. As there is usually no caching of credentials, if a user changes their password on the AD/LDAP system then that password is reflected instantly in the MFT system.
Increasing the security of using AD/LDAP to authenticate user credentials, RADIUS solutions using time limited one-time password tokens or even SMS messages can be integrated to provide an extra level of security.
In RADIUS authentication, the user or device sends a request to the MFT system to gain access to a particular network resource, then the system passes a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol. RADIUS servers vary, but most can look up client information in text files, LDAP servers, or databases. The RADIUS server can respond with an Access Reject, Access Challenge, or Access Accept. If the RADIUS server responds with an Access Challenge, additional information is requested from the user or device, such as a secondary password. Access Accept and Access Reject allow or reject the user access respectively.
Using AD/LDAP authentication or RADIUS authentication works well for users who are logging into the system interactively using either a web interface or file transfer client such as FileZilla, but do not work well for accounts which are used as a part of file transfer scripts.
The most popular method of securing these is to use “private key” or “key pair” authentication. With this the account does not use a defined password, but rather the MFT solution encrypts a token and sends that as a challenge to the client. This token is decrypted using the private half of the key at the client end and sent back unencrypted. If the tokens match the MFT solution accepts the user as verified and allows the account access. In this way any scripts which need to access the MFT solution do not need to have passwords encoded into them in raw text. Key pair authentication works with SSH keys for SFTP and SSL Certificates for FTPS and HTTPS connections.
With many more password breaches coming not from brute force attacks but from compromised authentication databases, experts are now advocating not making passwords longer or more complex but to implement Two Factor Authentication (2FA). This can be achieved using a combination of password and Private Key authentication or RADIUS in your MFT solution and works well for users and scripts.
Now maybe a good time to review your MFT password policies and maybe time I change some of my passwords too!!!