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.

DBServer 

Connection

Citavi uses the .NET default libraries (System.Data.SqlClient) to connect to the SQL server. The entire communication between Citavi and the database server occurs on this basis and according to the widely used SQL server protocols established by Microsoft.

DBServer Manager

DBServer Manager is not a server software program and does not communicate with Citavi. DBServer Manager is front end and is used to send SQL statements to a selected SQL Server. You can think of DBServer Manager as a "Management Studio light specifically for Citavi". Since DBServer Manager is not a server program, it is not critical from a security standpoint.

Project and data security

Standard SQL Server processes are used for security at the database and project level.

At the SQL Server level, each project is a schema. Each schema has three roles: Project leaders, Authors, and Readers. Authors have the schema rights Insert/Update/Delete. Readers only have Select rights. (In addition to Author rights, Project leaders also have the right to change roles.)

If a user is given author rights in DBServer Manager the user will be added to the corresponding project schema with the "Author" role via SQL. This architecture means that even if a user accesses the SQL Server database with a client other than Citavi, he or she can only see the data that he or she would be able to see with Citavi.

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.

Client (desktop software) 

The Citavi desktop software does not provide any server services. As such, it cannot be externally attacked. For this reason, the desktop version is not a security concern.

Wherever Citavi saves information relevant to security (for example, in the case of an access tokens), we use a strong public/private key cryptography.