Information Security

Do you suspect a security leak in Citavi? 

If so, please let us know by sending an email to support@citavi.com. We will then get in touch.

How we keep Citavi safe 

Internal security at Swiss Academic Software 

Our security begins in-house.

As part of our long-term strategy we've moved all of our in-house services to the cloud (GitHub, Office 365, Azure, etc.). We no longer have an in-house server. By using the cloud services we are able to benefit from the high security standards that our cloud providers offer. As such, we indirectly fulfill many security requirements that we otherwise could not offer being a small company.

We do not run any virtual machines in the cloud, for which we would have to guarantee security and updates ourselveds. Instead we rely on software as a service (SaaS) solutions.

We make sure that our client computers are always up-to-date. In case of physical theft, our hard drives are password-protected. We also have strong measures in place to prevent access to our network.

All cloud services that we use are secured with two-factor authentication. This means that even if a hacker could steal user names and passwords from us, he or she would not be able to log into our systems.

Development team 

We provide security training for our developers and ensure that security is always one of their concerns. We also make sure to stay up-to-date with new developments (especially on OWASP) and make sure to use all best practices. These include:

• For code critical for security (for example, our WebApi) the developers carry out code reviews with each other.
• We update third-party components (NuGet packages) regularly.
• All SQL queries are parameterized to ensure that SQL Injection cannot occur.
• Our source code only contains strongly encrypted passwords (in case of physical theft of developer computers).
• Access is doubly authorized in the code – on the "highest" level and on the "lowest" level. This helps prevent accidental developer errors from leading to authorization errors. In addition, we have various unit tests for testing the authorization.
• Our development and production environments are separated. This means that user data in the production environment cannot be affected by any development work that is being done.

External tests 

An external expert regularly tests our systems and services for weak areas in penetration tests.

Cloud 

For our web services we use Microsoft Azure Cloud. We run our server as WebApps (also known as platform-as-a-service). This means that Microsoft ensures the security of these servers at multiple levels.

Communication

All communication with our servers is always encrypted (https / TLS).

Accounts

We use the industry standard OAuth2 Citavi Account registration. For the implementation we use Identity Server, a widely used, well kept up, and established standard component.

Our users' passwords are processed by this component and, after many Hash processes, are saved in our database. We never save unencrypted passwords at any time. It's also not possible to determine the original password from the hashed password.

Project Database

Cloud projects are saved in an SQL Azure database. We use multiple measures in our code and at the database level to ensure that a user can never see anyone else's project information – even if one of our developers would accidentally write a false SQL query.

SQL Azure simultaneously mirrors all data on three instances, so that no data is lost if there is a hardware failure. SQL Azure creates automatic backups every minute and saves these for 7 days. If an entire data center has an outage, the data will be continuously copied to another data center.

SQL Azure data is encrypted on a physical level, which makes it inaccessible for external attackers to access the storage systems of the database. The data are not encrypted for Swiss Academic Software – this is not possible for technical reasons. This means that a developer with administration access in the production environment can access users' Citavi project data and attachments. For this reason, we've limited the number of people who have administration access to the production environment to a very small number. These developers are strictly prohibited from viewing user data.