Why can passwords be used to encrypt data, but are less strong for authentication?

Question

Encryption software is often password based. Even if the adversary gets your computer they can't get the data without knowing the password, and bruteforcing is infeasible.

Websites use passwords to authenticate users. They in particular store a hash of the user's password. If an attacker gets access to the server, it is difficult but still feasible for the attacker to get the passwords. That's why the hashes are kept secret.

Why is this? Is there a reason that encryption is harder to break than hashes?

Answer 1

The simple answer is that it's not less strong. Encryption that's solely password-based is just as (in)secure as a equivalently-architected password-based authentication system.

Answer 2

Encryption software is often password based. Even if the adversary gets your computer they can't get the data without knowing the password, and bruteforcing is infeasible.

Why is brute forcing infeasible? This mainly depends on the design of the system and of course the strength of the password. Encrypted plaintext that was encrypted with "password" is easy to "brute force". Well, if you include "dictionary attack" when you ask about brute forcing anyway.

Once you have calculated the key you should assume that the ciphertext is broken. Almost all plaintext contains enough structure to validate that the guess was right. Usually the protocol mandates that the user is correct when typing in the password.

Websites use passwords to authenticate users. They in particular store a hash of the user's password. If an attacker gets access to the server, it is difficult but still feasible for the attacker to get the passwords. That's why the hashes are kept secret.

The hashes generally aren't kept secret. They are not treated as passwords or keys. You don't want to leak them because off-line guessing is possible. But if you could keep them entirely secret you might as well store the passwords themselves and perform direct password comparison (with protection against side channel attacks of course).

Let's say that they are not assumed to be directly available as another layer of security.

Why is this? Is there a reason that encryption is harder to break than hashes?

It isn't. For encryption the ciphertext is usually directly available to an attacker. You don't need access to a specific server to start attacking the ciphertext. For password hashes this is the case.

In other words, you're missing the protection that a hardened and correctly configured/programmed server can provide.

Answer 3

I think you actually have two questions here:

Why can passwords be used to encrypt data, but are less strong for authentication?

There is not really a difference in security if you encrypt all data for a single user with the same encryption key or if you have some kind of secure storage and have some secure facility to authenticate this single user by the same password you would have used for encryption. But this is usually not the setup you have in reality, i.e. encryption and authentication are used in different scenarios.

Is there a reason that encryption is harder to break than hashes?

It is not that encryption is stronger than hashing or the other way. But encrypting a message and validating a password have different requirements. In fact simply using encryption for passwords storage would make it less secure and using hashes for data encryption would make it unable to recover the original data:

• Encryption
  Make it possible to decrypt the message. Since hashes are one-way only you cannot use hashes for encryption but have to use symmetric algorithms like AES or asymmetric like RSA. Since the major point of encryption is that only selected users can decrypt the message the big problem is to protect the key needed for decryption.
• Password validation
  Just validate if the user entered the correct password. Best make it secure enough so that even a server compromise will not reveal the stronger passwords. Encryption would work but then you have the problem of protecting the decryption key again - i.e. single point of compromise for all passwords. Just look at Adobe's desaster why encrypting passwords is bad. A hash does not have this problem. But to make brute forcing harder better add salt and make it slow enough, see About Secure Password Hashing.

Answer 4

Cryptographic Hash Functions

Before discussing the differences between hashing and encryption, it's important to lay down a few rules for so-called cryptographic hash functions. There are two requirements for a hash function H to be a cryptographic hash function:

1. Collision Resistant: Given a value x, there is no algorithm better than brute force random guessing to find a y such that H(x) = H(y)
2. Pre-Image Hiding: Given a large message space (think the set of all strings of length 1-30), given H(m) there should be no algorithm better than random guessing for deriving m. I.e. hashing is one-way.

Hashing

Let us imagine a scenario where there is a website bob.com, and a user Alice who wishes to setup an account and login. The flow would be something like this:

• User Alice visits bob.com, and creates an account. Alice sends a form to the site that includes her desired username and password.
• bob.com receives the form, and stores in their database a new row for new user alice. As you mentioned, the site will not store Alice's password in the database directly, to prevent information from leaking due to breaches, so bob.com stores a salted password hash. This just means that it stores a random number––the "salt"––and the hash of Alice's password concatenated with the random number, using some cryptographic hash function H.

Now, a login flow:

• Alice attempts to log onto the site. She types her password P into the login form, and clicks submit.
• bob.com receives P, looks up alice's salt S and hashed password h, and performs a check using the hash function H to confirm that H(P + S) = h. If it does, then Alice's submitted password was correct, and login proceeds. Otherwise, we reject the login attempt.

Notice that while we do not lose the information of Alice's password, it is not in a form that is directly usable. We can use the hashed information as a verifier, but cannot reproduce the password P on a whim unless Alice types it. Specifically, if we were to try and guess the password P from the given hash h and salt S, then we don't have a better algorithm than random guessing, as guaranteed by the cryptographic hash function.

Encryption

Encryption has the added difficulty over hashing of requiring that there be an inverse operation to find the original data, called decryption. When decrypting, the user must provide some form of decryption key, drawn (pseudo-)randomly from some large key space (think all 1024-bit strings). Now, one of the requirements of the encryption scheme is that you should not be able to guess the key given the ciphertext (i.e. the encrypted message) in time sublinear in the size of the keyspace. This analysis is similar to the hashing analysis above, and in fact you'll note that in both hashing and encryption, the difficulty in decryption derives completely from the length of the key you use (or in the case of hashing, the size of the message space your message comes from).

This is of course assuming a sound encryption algorithm, such as AES or the like, and does not take into account protocol issues. Flawed protocols are much easier to break, largely because they give you a "shortcut" around trying the whole keyspace, for example have a look at this response about 3DES on SO.

Answer 5

TL;DR: Encryption can be harder to crack because you may not know the plaintext to verify that you found the right encryption key and because encryption may require you to convert the key with similarly expensive algorithms as used for authentication plus the actual encryption itself.

Whether encrypted data or passwords are harder to derive depends on what was encrypted with which algorithm and how passwords are stored for authentication.

Passwords are usually not stored as readable plaintext for authentication but rather converted to hashes or digests with one-way cryptographic hash functions so that you cannot infer the password from it.

Ideally, the only way to get the original password is to brute-force it by hashing all possible or likely (maybe dictionary- or rule-based) passwords and comparing them against the given hash.

Also, it is good if it also requires lots of resources (computing time and/or memory) to get the password hash from the plaintext so that guessing becomes infeasible.

That said, encryption itself consists of a key derivation step and a reversible encryption step.

The key derivation transforms a user-defined key into a key that is used for encryption. The key may be denoted as a password.

In encryption context however, passwords are often termed passphrases because it is more likely that you use not just a single word but some longer text to encrypt while authentication passwords tend to be shorter for historical and practical reasons -- you use them much more frequently in most cases, and older UNIX or Linux systems and even Amazon, for example, restricted passwords to 8 characters some years ago.

Alternatively, you will very often find that key is a more frequently-used term for the secret used to encrypt data because it is more agnostic about the secret's structure.

In the simplest case, the key is used as-is to encrypt data (think of Vigenère encryption). For better security however, passwords are often converted to hashes just like for authentication. This is called key derivation. Key derivation functions can also be used to generate password hashes for authentication.

Another reason for not using passwords directly for encryption is that many modern encryption algorithms require keys of fixed length, usually because they are block-based (the key does not necessarily have to match the block size, though, e.g. AES-256 which uses 128-bit blocks with 256-bit keys).

Many encryption algorithms do not use the user-specified key or anything derived from it for encryption: They derive a "key encryption key" from the user secret which is used to encrypt a data key which is actually used to encrypt data.

The data key should ideally be a random data sequence not relatable to the user, system, plain-text data, or anything, which means you cannot infer the user secret at this point. The data key may be encrypted with slow asymmetric crypto-algorithms such as RSA.

Combining asymmetric encryption with symmetric algorithms is called hybrid encryption or a hybrid cryptosystem and may allow anyone to encrypt data while restricting decryption to a small set of users.

Another benefit of using this indirect approach is that you can encrypt the data key with multiple user keys so that the encrypted data can be made accessible to all those users, and you can just change a user key without needing to re-encrypt the actual data.

In the end, encryption produces ciphertext that is ideally looking like fully random data with maximal entropy and does not give any hints about either the original user-defined key or the plaintext.

This implies that there are as many plausible plaintexts that could be encrypted to produce the same ciphertext, so unless you know what was encrypted, you cannot verify that you found the correct key & plaintext combination when you try to crack the encryption.

This may however be thwarted by checksums, digests and signatures of the plaintext that allow you to check if your guess was correct.

So, unless the encryption algorithm is bad or the key derivation is significantly inferior to the one used for the password authentication you compare against, or you know something about the encryption key or the plaintext, encryption is much much harder to crack as there are more steps involved and a bazillion plausible inputs.