{"id":386,"date":"2019-10-14T13:40:00","date_gmt":"2019-10-14T13:40:00","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?p=386"},"modified":"2020-05-25T14:03:58","modified_gmt":"2020-05-25T14:03:58","slug":"lets-talk-about-security-digital-identity","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/lets-talk-about-security-digital-identity\/","title":{"rendered":"Let’s Talk About Security \u2013 Digital Identity"},"content":{"rendered":"\n

Security is more important today than ever before. Virtually everything is digitized and either located in its own network or connected to the internet. It is therefore theoretically possible for a client to address every server connected to the internet. Transposed to the real world, you could say that every building is located somewhere in the world and could be entered by anyone unless there are security precautions in place. Such security precautions to prevent unauthorized access also exist on the internet.<\/p>\n\n\n\n

I was very naive when I first approached this issue, thinking a login screen would suffice when programming a website. That would lock out anyone except the users whom I had previously granted access to the website. But then I was confronted with man-in-the-middle and DoS attacks and certificates. Luckily, there are organizations like OWASP<\/a> (Open Web Application Security Project) that have made it their mission to improve security in the World Wide Web. For this purpose, they provide free information, tools and methods that anyone can use to learn the basics. The OWASP website contains a list of the top 10 security vulnerabilities that occur in many current applications. The website explains these vulnerabilities and measures that can be taken to eliminate them as far as possible. The list ranges from SQL injections and insecure authentication to file uploads.<\/p>\n\n\n\n

\"Mouse
Figure 1: Let’s Talk About Security<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

In order to illustrate the vulnerabilities and possible security precautions, I am going to follow the developer Sebastian Safe as he programs his website. Metalworkers who offer locksmith services can register their business on this website. Sebastian created the basic website and is now dealing with the authentication of the users, i.e the digital identity. The problem is proving that the person who wants to use the system really is the person authorized to do so. For this purpose, he uses a session manager that verifies the user session so that the user is not forced to log in again and again while they are working in the system. The NIST<\/a> (National Institute of Standards and Technology) also issued a standard (NIST 800-63b) that provides a guideline for the user as they set up a digital identity. Sebastian created a login screen for authentication that is to be used both to register and to log in to the system. To protect Sebastian\u2019s website from getting hacked, let me mention a few crucial points that should be observed when it comes to authentication and that are important from the point of view of QA.<\/p>\n\n\n\n

The simplest example of authentication that you can find is a simple password. Sebastian stores the simple password generated by the user in his system, and verifies it when the user wants to log in. It is common knowledge that passwords should preferably be complex to ensure that they cannot be easily determined with a brute-force approach. NIST offers several recommendations or guidelines that should be observed to ensure that passwords are secure. A password should, for example, consist of at least 8, preferably even 12 characters because the number of variations to be tried in a brute-force approach increases exponentially with every character. Furthermore, it is recommended not to use standard words, even if special characters are inserted. For example, if you write the word \u201cPassword\u201d as \u201cPa\u00a7\u00a7w0r1\u201d, most brute-force algorithms will quickly recognize such a construct. Special characters are no longer as efficient as they used to be because the methods to decrypt passwords include all the special characters. It is therefore recommended to use long, cryptic passphrases to create a secure password.<\/p>\n\n\n\n

More important at this point, however, is the storage of the passwords in Sebastian\u2019s system. With smaller applications, the passwords can be stored in JSON files, but our developer is planning to create a larger and more extensive application. Consequently, as the structures in this case are more complex, the passwords are stored in a database. Sebastian does not know all that much about security; therefore, he stores the passwords in his database without encryption. He believes that no one can access his system anyway unless they are officially registered. However, the OWASP Top 10 vulnerabilities show that database leaks are one of the most common security vulnerabilities. Therefore, he should expect attackers to be able to access the database. As the login information of all the users of his website is stored there without encryption, an attacker could easily acquire it. This is why it is very important to store all passwords with encryption. There are several hash functions such as SHA256, WHIRLPOOL or TIGER2 that can be used for this purpose. These algorithms deliver a string of characters that cannot be decrypted with the knowledge we have today.<\/p>\n\n\n\n

\"Part
Figure 2: Character string for encryption<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

This way, the passwords are safe even if they get stolen. Unfortunately, many of these algorithms are \u201ccracked\u201d more and more efficiently over time. Even if you cannot decrypt the hashes, it is possible to trace the passwords from the hashes by means of rainbow tables. Rainbow tables are lists of countless passwords that were encoded with the respective algorithm. Accordingly, it is possible to find the passwords based on the hash by means of such rainbow tables. This is an example of such a rainbow Table<\/a>.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Example of how to trace a password:<\/p>\n\n\n\n

NTLM hash: 2b5cec7f00f89013efd8d2b0b5f6ac23
Decrypted Password: NecoPasswort<\/p>\n\n\n\n

<\/div>\n\n\n\n

This is why choosing a secure algorithm for encryption is so important. With currently available methods, a password with 8 characters encrypted with the NTLM hash function can be cracked within minutes. To make tracing by means of rainbow tables more difficult, Sebastian has to take other precautions in addition to the encryption. In this case, he choses the SALT & PEPPER option. A SALT string is added to the user\u2019s login password before it is hashed. This way, the password becomes more complex and cannot be decrypted with simple rainbow tables. It is recommended to generate a new SALT string for every user to obtain a greater variance. The disadvantage of a SALT is that it is stored in the database like the password hashes. They can be stored in different tables, but as soon as an attacker gains access to the database, they are able to read out the SALTs and use them to decrypt the passwords. Therefore, a PEPPER is added as a second layer of encryption. The PEPPER string works the same way as the SALT. A string is added before hashing the password in order to further complicate tracing. However, the PEPPER is not stored in the database, but hard-coded in the source code. This way, an attacker who only has access to the database cannot read out the PEPPER from the source code together with the hashes.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"Example
Figure 3: Coding example of the SALT & PEPPER option<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Sebastian has now salted and peppered his password hashes. It is worth noting that this does not increase the security of the password itself. However, it hampers an attacker\u2019s attempt to decrypt the users\u2019 passwords by means of rainbow tables.<\/p>\n\n\n\n

Another way for Sebastian to protect the access to his website is using multi-factor authentication (MFA) for the login. MFA has already become very common nowadays: Microsoft Azure with its SMS code, banks and their chip TAN, or Google Authenticator. They all generate a code when a login is triggered. These codes are transmitted through a separate channel and therefore offer a very small target for someone trying to read out the codes. This way, Sebastian is doubly sure that only legitimate users are able to log in to his system. It may be possible to steal the passwords by means of SQL injections, but logging in would still be impossible as long as the attacker does not have the MFA code as well.<\/p>\n\n\n\n

From the QA point of view, it is important to determine how passwords are stored in a system, and to ask yourself the following questions:<\/p>\n\n\n\n