What Does a Secure Password Even Mean? Password Security and Encryption – What You Need to Know

It’s an old joke: “What is Tom Hanks' wireless password?”
Answer: 1forrest1!

But what makes a password secure?

Who hasn't tried to log into his sibling's or best friend's Facebook account or cellphone to send or post something embarrassing as a joke? So if your face just stretched into a cheeky smile – don't worry; it happened to the best of us.

But, the truth is – the only possible way to do that was actually to guess the password, which is no easy task. But how saving the passwords without getting 'stolen' actually worked – was always a mystery.

Today, we know that as much as data security specialists and users carry a big part in securing an account, developers at all levels must play a role. For example, it's well known that we must be very particular when choosing a password for a newly created account. We've all felt the frustration of trying to pick a password that isn't too short, too simple, too predictable, too common, and simply too easy to guess by someone with malicious intents.

What you thought was a great password – actually isn't.

One of the most common misconceptions about passwords is that making them as complicated as possible - by using signs such as ˆ,&,#,!, and creating passwords like JoHn1997%$, will make the passwords more secure and our account or data more protected. However, that kind of password leads to a slow and inefficient log-in process, and more importantly – people can easily forget them due to their complicated structure.

That's why a good practice in password creation is to use a technique suggested in the picture below. Another helpful recommendation is to use that password as a master for a password manager, such as LastPass, NordPass, RoboForm, Dashlane, etc. Those tools can help you by generating an infinite number of passwords, storing them, and using them for logging into any existing account you have. Then, all you need to do is remember one single strong password that unlocks your password manager wallet.

Source: https://xkcd.com/936/

How to create a safe password?

The perfect, 100% secure password doesn't exist, but the universal recommendation is that the password is safe enough if a calculated time to crack it is approximately 100 years. As a rule, passwords should be at least 12-14 characters long.

On the other hand, privileged accounts, such as administrators and service accounts, should practice using even longer passwords. For privileged accounts, it is wise to consider implementing a Privileged Account Management (PAM) solution to further reduce the risk of privileged account compromise. We should also point out that, for example, people whose job is to test the security of passwords spend less than 8 hours to crack an 8-character password hash, but if it's only 2 characters longer, it takes them years.

An additional layer of security to your password

Even the most thought-out password requires an additional layer of security – such as encryption, hashing, and salting, processes regularly used to store data securely and securely.

It's crucial to store passwords in an encrypted format that is robust enough so that even in the case of a database getting stolen, the passwords are still secure, and a hacker cannot obtain them and therefore cannot use them. In addition, it's vital for users who use the same password for multiple websites, allowing hackers to reach different accounts.

We ensure password security by combining several methods and protocols to meet our security requirements.

How do we create safe passwords at Devōt?

At Devōt, we use Ruby on Rails to develop our backend, and we are familiar with using bcrypt-ruby gem and has_secure_password method - which allows us to make those attacks on the app harder.

Bcrypt-ruby gem is a secure hash algorithm designed for safely storing passwords by using blowfish algorithm (yeah, you heard it right) - a symmetric encryption algorithm that uses the same secret key to both encrypt and decrypt messages. Blowfish is a symmetric encryption algorithm, meaning that it divides a message up into fixed-length blocks during encryption and decryption.

So, what is hashing?

To clarify things, the use of a hash function generates a new string using a mathematical algorithm, and the result of that function is called the hash value. This process helps protect the integrity of information, so its main goal is to serve as a "one-way algorithm" that cannot be returned to the initial string after transformation.

Some well-known hashing algorithms are MD5, SHA-256, SHA-512, NTLM, and LANMAN, but the vital thing to know is – with hashing, it doesn't matter if you have a one-sentence message or an entire book: the result will still be a fixed-length chunk of bits (1s and 0s).

For example, we differentiate SHA-256 from SHA-512 methods by the length of their results. If we run a string through the SHA-256 algorithm, we will get a unique hexadecimal output of a fixed length. For example, SHA-512 converts the string "Lord of the Rings" to a much more complicated one.

That's because the example string is 256 bits, which display on our screen as 64 hexadecimal characters per string - for any given input, there are 2ˆ256 possible outputs. That means the chances of guessing the input of an SHA-256 hash is 1 in over 115 quattuorvigintillion - since that number is bigger than the number of all atoms in the universe, it is safe to say that the chance of guessing it is next to nothing.

Hash algorithms are deterministic, so they will always return an output of the same size regardless of the length. On the other hand, if we use SHA-512, our digest would look like a 512-bit hexadecimal string. It's not hard to conclude from this that SHA-256 is a much faster algorithm.

You can try doing this for yourself using SHA-512 or SHA-256, and see what your name looks like in those two. What can we conclude about a hash function? The essential factors that make it good are its determinism, lack of collisions, and hash speed.

How is hashing different from encrypting?

Suppose the concept of hashing still isn't quite clear, especially in comparison with encrypting. In that case, we need to emphasize the main difference: encryption is a two-way function, and hashing isn't. Encrypted data can be decrypted with the proper key, while a properly designed hashing algorithm doesn't allow the hashed data to reverse and reveal the original password.

The encryption process turns plain text into a ciphertext that the invaders cannot understand if they succeed in intercepting your data – because the scrambled information can only be read by the user who has access to the security key or password to decrypt the data. Some modern encrypting algorithms are Triple-DES Encryption, RSA Encryption, Advanced Encryption Standards, etc.

Considering everything, we can conclude that using hashing is much better because, with a properly designed algorithm, there is no way to reverse the hashing process to reveal the original password. Thus, stealing hashed files doesn't bring the hacker much use because the attacker cannot reverse the hashing process and access the original data anyway.

Salt, pepper, and optimizing safety

This topic brings us to salt. No, we haven't gone entirely off-topic, and we are not talking about a mineral composed primarily of sodium chloride (NaCl) or a slang term for being irritated, angry, or resentful - we are talking about cryptographic salt. A cryptographic salt comprises random bits added to each password instance before its hashing. So basically - it is adding random characters at the end of your password before hashing to force its uniqueness and increase complexity without increasing user requirements.

The other technique of making the hacker’s job harder is peppering (look at this guy with spices, huh?). It's similar to salting: a random bit of data is added to the password before it's hashed through an algorithm – but, unlike salt - it's not kept in the database along with the hash value. Instead, it is already added when a user enters a password, so the server doesn't store or need to see plain-text passwords.

Still, there are ways for hackers to guess our password – because people usually don't use completely random passwords, hackers can get a collection of a million commonly used passwords and run it through a hashing algorithm. By doing that, they get a list of associated message digests for these passwords - called a rainbow table. Now, it is very easy for a fast computer to compare a file of stolen password hashes against it, and for every match - the table will show the password for that hash.

So, what do we do?

Besides salt, another excellent protection method is called slow hashing – these hashes are designed to be inefficient and slow, hence more difficult to calculate. The purpose of slow-hashing is to make brute-force attacks much, much slower, thus infeasible – and keep your password safe. At Devōt, we prefer to use this method, and some examples of slow hashes we use are PBKDF2 and bcrypt.

Let's be honest - it’s very difficult to find a perfect balance between safety and usability. More complex mechanisms demand more resources on the server and shouldn't be overdone, because the process can easily become too slow and inefficient. We know nobody likes rules - nevertheless, there are some general rules on making a good password that is simple enough to remember and complex enough to be considered safe.

Authentication & authorization – what is the difference and, what type to use?

Although the encryption protects data by scrambling it with a randomly generated passcode (an encryption key), attacks on a database are still often – so we use encryption authentication to help us protect our data from hackers. So, what exactly is authentication? Simply put, it's a process that determines if someone's claim is true by using a secret or a piece of evidence called a ”factor,” and that claim is usually about their identity.

This process happens every time we sign into our e-mail account by providing our username and proving our identity with a password. Although Password-Based Authentication is the main method, there are other possibilities, such as:

• Multi-factor Authentication (MFA)

• Certificate-based authentication

• Biometric authentication

• Token-based authentication

The authentication process is followed by authorization. To make it harder for someone to gain access, we can use two-factor authentications that require users to input a password and a one-time code texted to their phone before logging in.

Similarly, a company might require employees to present both an ID card and fingerprint scan to access sensitive data or restricted areas. Simply put, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

Let's put it all to practice – how does it work?

After all this explaining, there may be more questions than answers in your head. To make it easier for you, let's put all of the processes mentioned above and methods in one example:

• You type in a plain password.

• It comes to our backend application which generates and appends salt on it and then computes the hashed password.

• It stores your username, salt, and the hashed password into the database (it never stores plain passwords or unhashed passwords).

• When the plain password comes to the backend application from the client, the backend application gets user-specific salt from the database and appends it to the plain password.

• Then, it computes the hashed password using the same hashing algorithm and compares it with the stored one – so it can be sure you are the one accessing your account.

We get that the process of data protection and security may not be an easy read, but it is well worth the effort.