This article is not specifically about security in NeuroomNet, but, since NeuroomNet is a web-based tool, about the security of web-based tools in general. In other words, what you should consider operating a system like NeuroomNet securely. We are happy to help you with any questions you may have, but you can get some ideas below about what to consider.
Security is a double-edged sword: If the security is too high, the authorized user is so massively hindered in the tasks that acceptance suffers significantly. But if it is too low, this can lead to very serious consequences.
In this respect, the internet is once again both a curse and a blessing.
The dissemination of knowledge is a great strength, but with it, the knowledge of how to undermine a system’s security is also quickly spread. Just as the connection to the internet itself creates the possibility of being able to conveniently attack a system. On the other hand, certain subsystems can be automatically kept up to date via the internet and protected from harmful influences.
So if you want to be on the safe side, you have to move with the times and adapt your system to the constantly increasing requirements. There are areas where you can take a breather because the concept already provides a great deal of security. Other areas adapt automatically (if there is access to the internet) and finally, there are areas where you have to regularly check whether everything is working as intended or react appropriately.
Public application (CA-signed certificates)
The duration of such a certificate is currently limited to 2 years and is even to be shortened to 13 months.
Internal application (self-signed certificates)
Costs and benefits
To ensure that everything functions as smoothly as possible, a so-called PKI (private key infrastructure) must be established. This helps with administration and control and can automate individual aspects. There are differences due to the manufacturers used in each case. It also requires appropriately trained staff to set it all up and renew it every few years or months, as described above. The regular installation of renewed certificates must be ensured, as they cannot replace themselves.
The more complex a system becomes, the greater the need to set up a separate certification authority and PKI. The days of “we just plug everything into the network switch” are over, because otherwise anyone can connect to the connection, read everything along with the login data, and even manipulate it during use (see also man-in-the-middle attack).
Why is a secured data connection useful?
By using certificates, it can be ensured that no manipulation of the content by third parties is possible during transmission and, for example, that no false information about your company is injected into your company website.
The most important protocols for securing data connections for operators of websites and web applications
TLS stands for Transport Layer Security and is the successor protocol to SSL 3.0. The first version 1.0 of TLS is a slightly modified variant of the third version of SSL and was standardized by the IETF.
The Internet Engineering Task Force (IETF) is an organization that deals with the technical development of the Internet to improve its functioning. Currently, TLS is in version 1.3 and is now also in widespread use.
TLS consists of two main components: TLS Handshake and TLS Record. In TLS Handshake, secure key exchange and authentication take place. TLS Record then uses the symmetric key negotiated in TLS Handshake for secure data transmission — the data is encrypted and transmitted with a MAC protected against changes.
Note: SSL is the more common term nowadays and often TLS is meant when talking about SSL.
A secure connection is often equated with encryption of the connection. However, SSL/TLS offers additional security features.
According to the original interpretation, the client browser should first display the certificate to the user after selecting the HTTPS address. The user then decides whether he trusts the certificate for this session, possibly saving it permanently, if necessary after checking it via the specified links. Otherwise, the HTTPS connection is not established (“Leave this page” with Firefox or “Click here to leave this page.” with Internet Explorer).
The three main purposes when using SSL/TLS are:
- Confidentiality (through encryption)
- Data integrity
These three purposes are explained below.
Authentication is used so that both sides of the connection can check the identity of the connection partner when establishing the communication.
Secured connections in practice
An SSL/TLS certificate is required to establish a secure connection. Among other things, the issuer of the certificate, the certificate holder, and the public key of the certificate holder are stored in a certificate. Certificates are stored on the server with which a secure connection is to be established later. To ensure the integrity of a certificate, it is signed.
A security certificate can be generated and signed by anyone. However, self-signed certificates are not authentic to third parties because no independent institution has verified the identity of the issuer. Most browsers, therefore, display a warning message for websites with self-signed certificates. To verify the authenticity of a website or web application, a chain of trust is formed between the end user’s browser and the server of the visited website. The browser and operating system manufacturers verify and trust selected organizations whose certificates are then stored in the browser or operating system. These organizations are also called certificate authorities. The certification authorities can verify the identity of third parties and sign their certificates after verification. To ensure that a minimum standard is maintained during verification, the organizations classified as trustworthy go through a certification process beforehand. Visitors to a website or users of a web application are then asked to verify that the chain of trust is intact.
There are various levels for verifying identity, which differ in the extent of the verification. At the lowest level (class 1), only it is checked whether the applicant has the domain noted in the certificate. For class 2 certificates, the identity of the applicant (individual or company) is verified in more detail, for example with copies of identification documents and company documents. For class 3 certificates, the verification is even more intensive and additional documents are required. Class 3 certificates are also referred to as extended validation certificates and are characterized, among other things, by the fact that their use in modern browsers is clearly highlighted.
Recommendations for the use of HTTPS
Notes on authenticity
A security certificate can be generated and signed by anyone. However, self-signed certificates are not authentic for third parties because no independent institution has verified the identity of the issuer. Most browsers, therefore, display a warning message for websites with self-signed certificates. To verify the authenticity of a website or web application, a chain of trust is formed between the end user’s browser and the server of the visited website. The browser and operating system manufacturers verify and trust selected organizations whose certificates are then stored in the browser or operating system. These organizations are also called certification authorities. The certification authorities can verify the identity of third parties and sign their certificates after verification. To ensure that a minimum standard is maintained during the verification, the organizations classified as trustworthy first undergo a certification process. The visitor of a website or user of a web application is finally checked whether the chain of trust is intact.
There are different levels for the verification of identity, which differ in the extent of the verification. At the lowest level (class 1), it is only checked whether the applicant has the domain noted in the certificate. For class 2 certificates, the identity of the applicant (individual or company) is checked in more detail, for example with copies of identification documents and company documents. For class 3 certificates, the verification is even more intensive, and further documents are required. Class 3 certificates are also referred to as extended validation certificates and are characterized, among other things, by the fact that their use in modern browsers is clearly highlighted.
Certification Authority (CA)
Today’s security in companies relies on multi-level systems so that the highest certification authority and its private key cannot be compromised (i.e. read out and misused by crooks or malicious people).
In modern, computer-based symmetric and also asymmetric procedures, the key is a bit sequence.
The key is the central component for decrypting a ciphertext and thus obtaining the plaintext.
Key for symmetrical methods
The security of a procedure depends not only on the algorithm itself but also on the key length. If an attack is found against a procedure that is more efficient than the brute force method, i.e. trying out all possible keys, the procedure is considered broken. The key length therefore directly indicates the security level of a secure procedure.
The key to asymmetrical methods
Asymmetric methods, such as the RSA cryptosystem, use key pairs consisting of a public key and a private key.
The public key is not secret, it is supposed to be known to other users, for example by distribution via key servers or certification authorities. It can be used to perform public operations, i.e., to encrypt messages or verify digital signatures. It is important that a public key can be clearly assigned to a user or company. If this is not the case, for example, if a message is encrypted with the public key of another user, that user can read the message even though it was not intended for him. To be able to name keys easily, one uses a fingerprint, a short hash value that uniquely identifies a key.
To decrypt a ciphertext or to sign a message, the private key is needed. In contrast to symmetric procedures, in which several users share a secret key, in the asymmetric procedure only one user/company has the private (secret) key. This circumstance is what makes it possible in the first place to assign a signature uniquely to a user/company. It is therefore fundamental that the private key cannot be derived from the public key.
For more examples and explanations, take a look at our documentation.