Cryptography – good password and good practices

Today we want to share with you some good practices regarding passwords, specifically about their storage, handling, and the password policy you can implement in your company. If you’re interested, we invite you to read on!

Dangers at Every Step

Unfortunately, the computing environment is full of vulnerabilities, and hackers exploit programmer errors, procedures, or even try to manipulate humans to breach security. Remember that anyone can become a victim, sometimes not even due to their own fault. The tips provided won’t eliminate the danger you face, but they will help minimize the risks associated with password-related topics.

Good Practices

If we want our passwords to be stored and managed securely, we should adhere to a few principles:

1. Appropriate Password Policy: This means having proper requirements for password complexity that users select. Instead of allowing any password, you can, for example, require passwords to include both lowercase and uppercase letters or special characters. In the world of cybersecurity, there are debates about what constitutes a secure password. Some research suggests that if users are forced to include a number and a special character, they will likely append them to the end of their password. It’s better to have a password that is not obvious and has at least 8 to 14 characters. For 12 characters, there are 6.13 * 10^23 combinations assuming you use lowercase and uppercase letters, digits, and special characters.
   
   
2. Avoid Leet Speak: If your password policy requires special characters, avoid using leet speak (for example, writing “p@ssword” instead of “password”), as there are ready-made scripts that generate such combinations for dictionary attacks. It’s better to use special characters at the beginning without substituting them for letters, e.g., “#*thisiscaptainjackspeakingtoyoupassengers”.
   
   
3. Encourage Passphrases: Encourage users to choose passphrases instead of passwords—complete sentences with punctuation. They meet complexity requirements due to their length and punctuation. In environments with lower security requirements, suggesting selecting a quote from an obscure song or a favorite book might be a good idea. The final decision is left to administrators.
   
   
4. Password Rotation: The practice of enforcing periodic password changes has been debated among experts for years. The theoretical idea is that if someone’s password is compromised, the attacker will have limited time to use the obtained access before the password is changed. However, it’s less effective for several reasons. Attackers usually act quickly, and before passwords are rotated, they might have already caused damage or established a backdoor. Rotated passwords are often easy to guess. A study from the University of North Carolina showed that 41% of rotated passwords could be cracked within seconds if the attacker knows the previous password. Additionally, some experts suggest that password rotation encourages users to select weak, easy-to-remember passwords. Users might choose a strong password the first time they’re forced to, but with subsequent changes, the passwords could become weaker. In conclusion, many in the industry now lean towards the idea that password rotation isn’t the best idea for security unless there’s suspicion that a specific password has been compromised.
   
   
5. Uniqueness of Passwords: Ensure your password is unique. If you have a different password for each service, a breach in one IT company doesn’t compromise your account on another platform.
   
   
6. Password Managers: As a user, consider using a password manager—a program that generates and stores your login passwords for various online services. This helps maintain uniqueness and appropriate randomness in generated passwords, as most leading password managers have built-in password generators.
   
   
7. API Checks: During user registration, programmers can implement sending a query to an external service that checks for data leaks. This helps ensure the user’s chosen password isn’t found in any leaks or known dictionaries used for dictionary attacks. This allows programmers to eliminate threats at the start of user registration.
   
   
8. Hashing Algorithms: Choose database password hashing algorithms that are deliberately slow, like bcrypt. User registration is relatively infrequent, and even if this operation burdens the server’s CPU more or slows down the process, it won’t significantly affect your application. If users have to wait an extra half-second, it’s not a big deal for them. However, for attackers trying to crack hashes, the time cost is massive for each hash they need to generate.
   
   
9. Use of Salt: Implement salt in your application. In the context of storing passwords, a “salt” is a random value (different for each user) added to the password before it’s hashed and stored in the database. This step has two positive effects on security. Firstly, even if users choose the same password, in case of a leak, they’ll have different hashes, preventing any collision with another user. Each user has a unique hash. Additionally, this forces attackers to resort to brute force or dictionary attacks, and it prevents them from using rainbow tables, which significantly speed up and facilitate their actions. 
   
   Figure 1 – salt mechanism, source: geeksforgeeks
   
   
10. Use of Pepper: Implement pepper in your application. Unlike salt, a pepper is shared among all users in the database, but it’s stored in a different source, like the application’s code or a Hardware Security Module (HSM). This has two implications for security. Firstly, it makes generating rainbow tables (if salt is used) impossible. Even if an attacker downloads the salt for each user and generates all 8-character passwords or dictionary-based passwords for each of them, it won’t help them. They’re left with only brute force and generating each possibility sequentially, which becomes nearly impossible with a multi-character pepper. The second implication is that obtaining the pepper requires a different attack vector. There are attacks (like SQL injection) that could grant access to the database but not the application itself, making recovering the pepper extremely challenging if not impossible. Additionally, recovering the password from the application might not be trivial and would likely involve reverse engineering.
    
    

    

    Figure 2 – Pepper and Salt Mechanism, the pepper should be stored in a hardware-based HSM (Hardware Security Module) if one exists on the server. Source: codesigningstore.com
    
    

11. Avoid Public Repositories: Avoid placing any passwords or secrets in publicly accessible version control repositories like GitLab. Many attacks have been possible due to accidental uploads of private keys or tokens to public repositories. GitHub now scans public repositories for such secrets. You can read more about it here: GitHub Secret Scanning.
    
    
12. Login Attempts and Lockout: In applications, it’s useful to apply a limit on login attempts, triggering an account lockout or an IP address timeout. This way, you can easily thwart attacks on user accounts. If a false alarm occurs, the user should have a way to reinstate their access, which should also be taken care of.
    
    
13. Multi-Factor Authentication (MFA): A password alone is a weak way to secure an account. MFA, such as using an additional password from an SMS, an authentication app, or a confirmation on your phone, should be employed. You can read more about this in our previous article on authentication methods. Remember, the best type of MFA is a U2F key, a hardware key that provides extra protection against phishing the second component.

Haveibeenpwned

If you want to find out whether your password has been compromised and how, we recommend the website https://haveibeenpwned.com/. By providing your email address, the application will check if you’ve been part of any breaches. The database of breaches is continuously updated, so it’s worth checking the status of your email or those of your close ones from time to time. It might be worth warning them to change their password if they aren’t aware of being part of a breach.

Summary

We hope that you enjoyed the next article from our series. Next week, we’re staying on the topic of cryptography and we’ll tell you a bit more about ciphers. If you’re interested, feel invited!

Sources:

• https://codesigningstore.com/how-does-hashing-work
• Kyle Rankin – Hardening Linux in Hostile Networks
• https://www.geeksforgeeks.org/how-to-hash-passwords-in-python/