Do RSA softtokens meet IRS1075 Multifactor authentications requirement?
Multi-factor Authentication Implementation | Internal Revenue Service (irs.gov)
- Private keys must be non-exportable – Soft token software that utilizes encryption keys stored in a local key repository must mark the keys non-exportable. This helps prevent exportation of the key to be installed on an unauthorized system. Files of long-term private keys shall be protected by access controls that limit access to administrators and only to those applications that require access.
- Never store keys in plain text (unencrypted) form – If the soft token is using shared secret keys, the keys should not be stored in a format that can be read and copied outside of the application. Text files would have to be at least read only to the users of a system for the Soft Token software to function. This greatly increases the chance the keys can be copied to another system.
- Distributing the seed record and initial passphrases requires a confidential channel to ensure that it is not duplicated in transit – Installation of soft token software typically has two pieces of information (seed record, passphrase) to install and initialize the token generation engine. These two pieces of information, if captured by an unauthorized user would allow unauthorized installations of the software, and could be used by parties other than the authorized user.
- Activation of the token must occur every time user authenticates using the soft token software – Each authentication shall require entry of the password or other activation data. Input of the other factor (password) must be strictly limited to manual user input when challenged by the relying party (system). Storing of the PIN or password allowing the software to generate a token without manual user input should not be implemented.
- Token time limit must be 2 minutes or less – The token generated by the software must have a time limit for use. This small time window should be sufficient to initiate remote access, and prevents the sharing of a token for other systems, or theft of the token.
- Soft token software password must follow Pub. 1075 password requirements – Password management requirements for soft token software should follow the complexity, size, change interval and reuse guidelines stated in Pub. 1075. This will ensure that passwords used to generate tokens are not easily guessed and unique per user.
- Audit all access to software tokens – Audit logs must be captured for access to the soft token software when successful and unsuccessful remote access attempts have occurred. The audit trail should log attempts made to guess PIN numbers and passwords, and correlating software access with successful and unsuccessful remote access connections can show attempts to tamper or copy the soft token software.
- Always install the latest version of malware prevention software before using software tokens – Malware prevention software must be installed to identify and prevent installation of key logging software or other malware that could capture the PIN or password used to access the soft token software.
- Always use FIPS 140-2 validated cryptographic modules – The cryptographic module performing the encryption function must be validated to meet FIPS 140-2 Level 1.
