Passwords (low-entropy secrets) play a critical role in keeping information safe. For this reason, ensuring password security is a critical element in information security.

Disclaimer

This article is my interpretation of the law and personal opinion. GDPR does not contain any specifics about passwords. The UK Information Commissioner’s Office - ICO published a useful guide for the development of password protection systems after GDPR.

Password systems and the GDPR

GDPR not only introduces the principles of privacy by design and privacy by default, but in Article 32 it also defines the obligation for data security and data loss prevention.

Access to personal data is protected by passwords. In order to protect personal data, passwords have to be protected

Any password system developed or deployed has to be protected against brute force, dictionary, guessing and credential stuffing attacks. The password itself is treated as personal data and requires state of the art protection.

Shortly after the introduction of GDPR a German company reported a data breach in accordance with Article 33 GDRP to the authorities. During the investigation, it was discovered that the passwords have been stored in clear text. This was interpreted as a violation of Article 32 GDRP and the company was fined EUR 20.000.

“By storing the passwords in clear text, the company knowingly violated its duty to ensure data security in the processing of personal data.” the authority said.

The company wasn’t fined for the breach but because of the password storage strategy!

State of the art methods for password storage

Under GDPR a strong password storage strategy is critical in mitigating data breaches. Hashing passwords is no longer just an option and the hashing method should be state of the art.

Requirements for the hashing method:

  • The honest player needs to be able to compute a single instance of the algorithm on standard hardware for moderate costs.
  • The adversary should not be able to reduce costs by calculating multiple instances of the algorithm on customized hardware.
  • The time for calculating the hash should not depend on the length of the password.
  • Identical input has to produce a different output (nondeterministic).

One way function

This is better than clear text but attackers have found ways around this implementation. If a couple of users were to use the same password, their hash would be identical. Multiple accounts mapped to the same hash indicate a commonly used password. With this knowledge, hackers can considerably narrow down the number of passwords used in an attack. Attackers can also utilize databases of pre-computed hashes (rainbow table attacks).

The salt

Salting the input increases the complexity of the output without increasing user requirements. A salt is a fixed-length cryptographically strong value added to the input. But fixed salt strings can get exposed in a data breach and the attacker can neglect the advantage of using a salt. This implementation also produces deterministic outcomes.

BCrypt, PBKDF2 or SCrypt - key stretching

This is a great improvement over the mentioned above methods but I do not recommend the commonly implemented BCrypt, PBKDF2 or SCrypt methods for newly designed systems anymore.

BCrypt and PBKDF2 are key stretching or key derivation functions and do not offer memory hardness. This means those methods are CPU bound and prone to password cracking by Application Specific Integrated Circuits (ASICs). Whitepapers have emerged regarding Energy-Efficient Bcrypt Cracking with Low-CostParallel Hardware.

SCrypt adds memory-hard functions (MHFs). It is CPU and Memory intensive to calculate. But I see an issue with the usage in cryptocurrencies. Mining solutions for SCrypt are available and these could be repurposed for offline cracking. SCrypt also doesn’t give many options to configure parameters to balance parameters. In my opinion, this is an important feature to tailor the method to your use case.

Argon2 - appropriate hashing

My recommendation for a newly designed password storage system is argon2.

  • open source implementations in all commonly used languages
  • has been around for a while
  • withstood studies to accelerate the algorithm on dedicated hardware
  • parameters to control execution time, memory requirements and degree of parallelism
  • won the Password Hashing Competition

GDPR symbolic picture

Preventing a data breach

Hashing will protect passwords after a data breach. Other privacy information is usually stored in clear text. The risk for a data breach can be reduced by implementing processes, controls, and audits.

Consider the following:

  • User rights management - Access control
  • Privileged user monitoring
  • Immutable audit trail for machines and humans
  • Secure archiving for forensics
  • Data access auditing
  • Data discovery and classification
  • Change management
  • Rate limiting
  • Employee background checks
  • Encryption of private information

Evaluation process with GDPR

GDPR changes the requirements for engineers and we need to put more thought into designing a system. Evaluation processes and decision making has to be documented along the following criteria:

State of the Art

Use the most advanced approach and measure it against the ever-evolving cybersecurity threat landscape. Keep on learning, educate yourself, assess risks and anticipate attacks. Be aware of threats relevant for your use case. A successful security strategy is never “done”.

Risk Profile

Know your companies unique risk profile and customize your solutions accordingly. Risk profiles include core requirements for systems. This profile has to be re-evaluated according to company changes or changes to the threat level.

Processing Profile

Evaluate the nature, scope, context, and purposes of the processing of personal data. It is essential to understand what data is where and for which purpose. Data might be the oil of the 21st century but minimizing the amount of collected data is required. Collect only data you need for business and legal reasons.

Cost

Evaluate the costs of an implementation according to the risk profile.

Conclusion

In this post, I wanted to show how to satisfy GDRP requirements for password storage and what to take into consideration. It’s fine to run a legacy system with BCrypt but when designing a new system we need to use technology with a high probability to stand the test of time. Or at least the next decade. It’s on us engineers to stay informed about the continuous evolution of cybersecurity threats and adapt our approach.