Development requirements & guidelines
Date Last Revised: July 4, 2019
1. Secure communication
All inter-service communications must be done using SSL (Secure Sockets Layer). SSL provides secure communication between clients and servers. Below you can find the must-follow list:
Protocols TLS 1.0 or higher versions
Certificates signed with SHA 256
Forward secrecy using DH protocol with 2048 bit keys and higher
Firewall on all servers in restrictive mode
On the other hand, you should exclude using insecure ciphers such as RC4, MD5, various EDH, KPRB5.
SSL version 3.0 and prior are also forbidden due to their vulnerabilities.
Alongside with don’ts, there are several recommendations you might want to follow. It would be highly preferable if you used:
RSA private key size of 2048 bits and higher
HTTP Public Key Pinning
A general guideline is not to trust open communication channels including provider LAN even with dedicated hardware.
As a rule, use VPN with proper ciphers and authentication when accessing sensitive environment.
You can find more HTTPS recommendations by visiting this link: https://wiki.mozilla.org/Security/Server_Side_TLS
2. Data protection
Data protection is one of the most important security aspects, and it starts with the right password policy. Here are the basic password storage rules:
Never store a password as plain text
Only the password holder should have access to the password
Do not send passwords via open channels such as Skype, messenger, email clients, etc.
Use password managers to generate and store secure passwords, e.g. KeePass, 1password, etc.
Change passwords at least once in 3 months
Furthermore, different user roles is a point to pay attention to. When registering with Salt Edge, a new client automatically gets account administrator permissions and access to multiple actions. That is why it is highly recommended to follow the above-stated password storage rules. Later on, when you add new users, you can manage their roles and distribute the permissions accordingly. By following this link you will find all the roles you can assign and their descriptions.
Service security is provided on several levels:
You need to store your public key in Spectre API in order to secure your communication. The public key is added here: https://www.saltedge.com/clients/security/edit/
Service_secret is used for authentication to Spectre API and therefore it has to be properly stored as well. Please note that service_secret should only be used for projects, which are fully controlled by you and are running on your hardware. In case of mobile applications, you should use app_secret which is described below. Service_secret can be regenerated as many times as you wish. https://www.saltedge.com/clients/security/edit/
Finally, if you are using Spectre API as a service, absolutely all your requests should be signed. Please visit our official documentation for detailed information on signature. https://docs.saltedge.com/guides/signature/
Application security is ensured by using app_secret authentication. It makes sure that if a user gets the access to the application source code, they will only acquire their own data.
3. Test/Live Environments
On our end, we offer you the test accounts, which you can use for different purposes, such as getting to know all the functionality and the way it works, or trying out a new feature before adding it live. You can have several accounts, however, the main requirement is to have only one live account per project. More information on account statuses can be found here: https://docs.saltedge.com/guides/your_account/
We strongly encourage you to test everything before going live or when upgrading to next API version. The following article lists the steps you need to take before going live: https://docs.saltedge.com/account_information/v5/#before_going_live
4. Data storage
The rule of thumb is not to store any end user credentials. This is highly sensitive data and you should take the responsibility of providing absolute security to your users. Such data as holder info, accounts, transactions and other, should be kept encrypted in case it is stored on end user device. For data protection you can use PCI DSS certification or similar.
The access to such data should be limited as well. For instance, if you are using admin panel of your own, assign roles and grant different access levels. It is also an option to give the access upon request; this kind of access can be granted to employees with specific roles and will depend on the purpose of their request.
It is also critical to have strong database passwords which need to be stored securely. Likewise, keep your backups encrypted.
5. Incident reporting
In case you think there was an unauthorized access attempt, you should reset your passwords, tokens and public key. Please always report these kind of incidents to us. You should feel free to contact us via this contact form or support email email@example.com