Merchants implementing BankID should always have in mind that their system can be compromised both by internal and external persons. This chapter aims at recommending some basic security initiatives that should be brought out by merchants migrating to the BankID production environment. These measures are not meant as a guideline, merely general entities that the merchant should consider protecting.

Protection of BankID implementation entities

A BankID implementation consists of private key files, property files and other entities that are sensitive and must be protected on the computer/computers running the system. Listed below are entities that the merchant should consider protecting by executing additional security measures. In addition the list includes general security actions that should be implemented for the sensitive entities.

Merchant process running the BankID implementation:
- Create one specific user on the system that is responsible of running the BankID process. This user should have as restricted access as possible.
Merchant BankID keystore file:
- Make sure that the only process with read access to this file is the same process running BankID. Avoid both read and write access for processes running under other users than the "BankID" user.
Merchant BankID property files:
- Make sure that the only process with read access to this file is the same process running the BankID implementation. Avoid both read and write access for processes running under other users than the "BankID" user.
Merchant BankID keystore password:
- If possible, avoid storing this password in any files (even hard coded in the merchants' binary code). The best security measure is to enter the password at the moment the merchants BankID process is initiating. In a production environment this might be problematic, but be very careful not to store the password in a file that can be easily accessed by both internal and external persons.
- The merchant might consider using an HSM.

Replay attack

The merchant should consider functionality to prevent/detect and handle replay attacks targeting the initAuth and initSign messages seemingly coming from the BankID client to the merchant application. Using a generated sid or other dynamic identifier token to identify a replay attack, the merchant application should take action if more than one request of the same type is received for a single session.

DNS poisoning detection

The merchant should consider using the functionality offered by BankID COI to compare the IP of the client as seen by the merchant application to the client IP seen by the BankID COI. After client termination the client IP as seen by the COI is retrievable using getTransactionInfo() from the "Data to Merchant"-interface, see [ICSRV]/[IJSRV] and [BIDGS].

Browser not supported