Password security is not just an IT issue; it’s a business issue that can have far-reaching impacts. In today’s digital age, poor password security can have disastrous consequences for any organization. Here’s why:
Data Breaches: The primary risk of poor password security is a data breach. Cybercriminals can exploit weak password practices to gain unauthorized access to your system, leading to the theft, corruption, or ransom of sensitive data. According to a study by [IBM, the average data breach cost in 2022](https://www.ibm.com/downloads/cas/3R8N1DZJ#:~:text=Average total cost of a,million in the 2020 report.) was $4.35 million, the highest in 18 years. These costs include, among others, the cost to identify and remediate the breach, legal expenses, lost business, and efforts to restore the company’s reputation.
Loss of Customer Trust: In the event of a data breach, customer trust can be severely damaged, leading to loss of business. Customers entrust companies with their personal and financial information and expect their data to be handled with the utmost security. A breach can shatter this trust, and rebuilding it can be long and costly.
Regulatory Fines: Many industries and regions have strict regulations regarding the handling and storage of data, including password management. For example, the General Data Protection Regulation (GDPR) in the EU and the California Consumer Privacy Act (CCPA) in the U.S. impose hefty fines on companies that fail to protect customer data adequately. In severe cases, fines can reach up to 4% of a company’s annual global turnover under GDPR or $7,500 per violation under CCPA.
Given these potential consequences, it’s clear that password security is a crucial aspect of any organization’s overall data security strategy. Implementing robust password security practices can help protect your company from financial loss, maintain customer trust, and ensure compliance with data protection laws and regulations.
Common Methods for Storing Passwords and Their Implications.
Any gated system requires some sort of user authentication and, consequently, password storage for validation. There is no standardized method for storing passwords, but we can categorize them to fall within the following categories: plain text, password encryption, hashing, and hashing & salting.
Storing passwords as plaintext is the simplest method, requiring minimal development effort. Despite the simplicity, it is the least secure approach. Attackers gain immediate access to all user passwords if a data breach occurs. A stark example of this practice is Facebook, which stored hundreds of millions of account passwords in plaintext for years. They justified this by saying that the passwords were invisible to anyone outside of Facebook and only accessible to a select group of engineers and developers1. Despite these precautions, it’s generally considered an unacceptable practice in modern web development due to the high risk it presents.
Encrypting passwords is a more secure approach than storing them in plaintext. This method transforms passwords into a different form that can be reversed (decrypted) using a specific key. This offers more security as an attacker would need the decryption key to access the original passwords. However, it still presents risks. If the decryption key is compromised, all passwords can be revealed. Furthermore, encryption algorithms can be susceptible to various attacks, especially outdated ones.
A more secure method for password storage is hashing. Hashing involves transforming the passwords into a fixed-size string of characters using a one-way function. Unlike encryption, retrieving the original password from the hashed version is impossible. This provides a higher level of security because even if an attacker obtains the hashed passwords, they cannot derive the original passwords. However, hashing can still be vulnerable to attacks like rainbow table attacks, where pre-computed hash values are used to crack the passwords.
Adding an extra layer of security to hashing, we have hashing with salt. This method involves appending or prepending a unique, random string (a salt) to the password before hashing. Each user’s password should have a unique salt. Salting makes it much harder for an attacker to crack the passwords using rainbow table attacks, as they would need to compute a rainbow table for each salt. It requires additional storage for the salts and a more complex implementation than plain hashing, but the increased security is generally considered worth the trade-off.
Arbitrary Password Restrictions: A Legacy of Outdated Practices.
Password restrictions, such as limiting the number of characters or not allowing certain special characters, are common across many systems. However, these restrictions, often a relic of older development practices, can actually hinder security rather than enhance it.
Why Do Restrictions Exist?
Legacy Software or Database Issues: Some systems were built years ago when hardware and software capabilities were more limited. For example, older databases set character limits for fields. Similarly, some legacy systems may have issues with certain special characters that can interfere with their operations, leading to restrictions on their use.
Security Misconceptions: Some restrictions stem from misguided attempts to prevent security issues. For instance, a system may disallow characters that could be used in SQL injection attacks to manipulate database queries. But in a well-designed system, user input would be properly sanitized to prevent such attacks, making such restrictions unnecessary.
Simplistic Design Choices: In some cases, restrictions may result from a simplistic design decision, where the developers did not anticipate the need for long or complex passwords.
Why Are Restrictions a Bad Practice?
Restricting the length and complexity of passwords reduces the potential space of passwords, making them easier to guess or crack. Modern password-cracking tools can attempt billions of guesses per second, and every additional character or allowed symbol in a password dramatically increases the time it would take to crack.
Moreover, these restrictions can give a false sense of security. They may lead users to believe that the system is more secure than it actually is, or that their shorter, less complex password is sufficient.
Finally, such restrictions can be a sign of outdated or suboptimal security practices in the system as a whole. If a system is restricting passwords in this way, it raises questions about how it is handling other aspects of security.
Basics of Hashing and Salting.
In the world of cybersecurity, the terms ‘hashing’ and ‘salting’ are frequently used. But what exactly do they mean, and why are they crucial for securing passwords?
Hashing: A One-Way Street.
At its most basic, a hash function takes an input (in this case, a password) and produces a fixed-size string of characters, which is typically a digest unique to each unique input. It’s a ‘one-way’ function, meaning the operation can’t be reversed to reveal the original password from the hashed output. This is the primary advantage of hashing in password security – even if a hacker managed to access the hashed passwords, they couldn’t convert them back into the original plaintext passwords.
Hash functions are designed to handle inputs of arbitrary length, and the hash output is of a fixed length. This means that the hash will be the same length whether your password is one character long or a hundred.
Salting: Adding a Pinch of Randomness.
While hashing is good, it’s not infallible. Attackers can pre-compute the hash values of known words or passwords (like those from dictionaries or lists of commonly used passwords) in what is known as a rainbow table. They can then use this table to look up the hashes they’ve obtained and find the corresponding password.
This is where ‘salting’ comes in. A ‘salt’ is a random string that is generated for each password when it is created. This salt is combined with the plaintext password, and the resulting string is hashed. The salt is stored alongside the hash in the system. When the user logs in, the system combine the entered password with the stored salt, hashes this combination, and compares it to the stored hash.
Adding a unique salt means that even if two users have the same password, their hashed passwords will differ because their salts differ. This makes using pre-computed tables like rainbow tables infeasible, as the attacker would have to compute a table for each possible salt, a computationally unfeasible task given a sufficiently large salt.
Besides the added resiliency to attacks, hashing and salting passwords allow you to remove arbitrary restrictions like length or special characters. This enables the user to create more complex and secure passwords, which in turn enhances the overall security of your system.
It’s Not Just Hashing and Salting; It’s the Algorithm That Matters
Using hashing and salting is not enough to secure your system; how you implement the hashing matters a lot—for example, using fast hashing algorithms, such as MD5 or SHA-1. While designed for speed, these algorithms are unsuitable for password hashing due to their susceptibility to brute-force attacks.
The solution is to employ slow hashing algorithms specifically designed for passwords. Algorithms like bcrypt, scrypt, or Argon2 are computationally expensive and slow, which makes brute-force attacks practically impossible.
Don’t Make Your Users Type Their Passwords: Working Seamlessly with Password Managers.
Enabling long and completely random passwords does not necessarily mean that end users will create long and random passwords, nor will enforcing strong password policies.
A good password is not a memorable password. In fact, it is quite the opposite. Good passwords are a combination of random characters, numbers, and symbols. Humans are not good at generating or remembering a string of random characters, numbers, and symbols. Password managers help alleviate this problem by generating, storing, and auto-filling unique passwords for each website or application. They are digital vaults that are locked with a single master password. However, for these tools to work effectively and provide users with a seamless experience, developers must ensure that their applications or websites are compatible.
Common Issues with Password Manager Compatibility.
Unfortunately, users often encounter problems using password managers with certain websites or applications. Some common issues include
- Restricting pasting information into password fields and forcing users to type their passwords.
- Improper HTM input type usage, making it impossible for password managers to identify username and password fields.
- Not properly identifying mobile apps with their corresponding website, causing password managers to be unable to match the app with stored credentials.
Addressing these common issues and testing your application or website’s compatibility with popular password managers improves the end user convenience and enhances security, reducing the risk of account breaches and the common support call for lost passwords.
The Passwordless Future: A Distant Promise.
We are well entered into the 21st century and still use an authentication technology invented in the early 60s. It will remain the most widely used methodology for quite some time.
This does not stop technology companies from developing technologies that help us transition from the traditional user and password combination into a passwordless system. Yet the implementation of such a system carries its unique set of challenges, particularly for software developers.
From a software development perspective, implementing passwordless authentication systems can be complex. One of the key challenges lies in the diversity of user roles and use cases within any organization. A solution that works perfectly for an office worker using biometric authentication might not be suitable for a factory worker who can’t bring a device into their work environment. Developers must, therefore, be mindful of creating flexible and adaptable systems that can cater to various user situations2.
Another significant hurdle for developers is the handling and storage of biometric data. Biometric information, unlike passwords, is permanently tied to users. If compromised, it can’t be changed like a password can. This makes the handling of such data particularly sensitive. Developers must ensure that these systems are designed with robust security measures and comply with data protection regulations. Privacy concerns extend beyond device management to how captured biometric data is stored and used. Developers must consider these issues from the outset to avoid intrusive or non-compliant practices.
From a user experience perspective, the transition to passwordless should not be a step back. The process should not create excessive friction or complexity in the login process. Users should be able to enroll and learn new authentication methods without it being a significant effort. Moreover, plans should be in place when a device is lost or broken. Users could quickly become frustrated and resistant to the change if the new method isn’t a better experience than remembering a password.
Despite the appeal of passwordless systems, we must accept that, in its current state, the passwordless dream is yet to be fully realized. Most passwordless systems revert to traditional passwords when all else fails. This is primarily due to the abovementioned challenges and the need for a reliable backup authentication method. Until these hurdles are cleared, passwords, for all their flaws, will continue to be a significant player in our digital lives. This fallback to traditional passwords underscores the importance of ongoing efforts to improve password management practices, even as we strive towards a passwordless future.
No Password is Ever Final: A Journey Towards Better Authentication Practices
The journey towards secure password practices is ongoing. While we look forward to a potential passwordless future, keeping our current password management practices robust and secure is crucial.
Implementing best practices in password storage, such as using secure hashing and salting techniques, won’t eliminate all security risks. However, it does make your application more resilient to attacks. A single compromised account won’t automatically bring down the rest of the accounts, preventing a single point of failure from becoming a system-wide catastrophe.
Moreover, we should strive for an inclusive authentication process that accommodates password managers’ use. Ensuring that your website or app is compatible with these tools enhances user experience and encourages using stronger, more secure passwords.
In the face of evolving security threats, it’s clear that our approach to passwords and authentication must also evolve. Whether refining our existing password practices or transitioning to new, more secure authentication methods, the aim remains to protect our digital identities and data.
The password may not be final, but it’s a significant part of our digital lives for the foreseeable future. As we navigate this landscape, let’s make the journey as secure as possible for us and all users.
