I am developing a steganography app where user encrypt any file into an audio file. The user can enter a password to protect the hidden data. The same password is converted as a 256 bit key and the hidden data is encrypted using AES. I was wondering, how secure is using password as the AES key?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Passwords are commonly used for both authentication and encryption. Sometimes this is done securely. "Commonly" is an interesting word here, because passwords are commonly turned into encryption keys in ways that do not follow good security practices, and also passwords commonly do not have enough entropy to be suitable for generating encryption keys.
Generally the term "x is only as good as y" would apply to encryption keys and passwords, such as "key is only as good as password", but the method used to convert the password into the key is more important for the majority of password choices. If you were using a long string of random characters, even MD5 could be acceptable... but you probably are using a shorter password built from real words and phrases. Let me be clear that MD5 is not acceptable to convert passwords into keys.
A 'Password Based Key Derivation Function' (PBKDF) is what is needed to convert your password into a suitable encryption key. There is debate over the specific features and properties a PBKDF should have, but its purpose is to compensate for the poor entropy of commonly chosen passwords, among other things, such as properties of the cryptographic primitives that PBKDFs are built from.
Cryptographic hash functions and block ciphers are commonly used to build PBKDFs, and they do an excellent job, but they are extremely fast and use minimal resources such as memory and cpu cores, which can be a profound advantage to an attacker. Thus a PBKDF is mainly used to slow it down, usually by iterating the primitive thousands or even millions of times. More modern PBKDFs also consume larger amounts of memory, and some may only operate quickly (for verification) by using multiple cores. A 'salt' is used as an input to the PBKDF to prevent the same password from generating the same key unintentionally when used in different situations or by different users. The salt is stored where the password would be processed in order to get the correct key.
Best practice is to use a PBKDF to generate a 'key encryption key' (KEK), then a full entropy random key is used to encrypt the data, and the KEK is used to encrypt that key. That way a password change does not require reencryption of all the data, just the key. The KEK is never stored, only used to encrypt and decrypt the data key. The encrypted data key and PBKDF salt are stored with the encrypted data.
You may not have control over the password a user enters, but you do have control over how it is processed into a key, and you may be able to make recommendations to your users as to good password choices. Attacks only get better, passwords should be as long as possible while still being memorable. Estimating password entropy is difficult, so the PBKDF is extremely important to preventing it from being cracked. If you can accurately estimate entropy you may be able to warn a user that their password may be insufficient.
You should be very open with your users about how you convert their password into a key, it is "common" for secrecy of the method to be associated with extremely bad security practices, and more and more people are starting to realize it (due to an ongoing string of hacks and stolen password databases with lots of press coverage). Additionally, if an individual that understands cryptography can be confident in the security it provides, they may be inclined to recommend the product. I certainly would be.
Note that security is only as strong as the weakest link. If you are using an excellent PBKDF but have poor programming leaking key material into virtual memory, the product is not secure. Do not rely on good cryptographic components to do the work of security for you, it is more complex and difficult than that. It is an entire system. Sorry for the long answer.
I hope you hash your password with something secure like sha-256 the way recommended by sp800-132 section 5.3 http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf. in that case, brute-force attacks on hash collisions are unlikely to succeed.
Your design has the security of the password ..... "", "abc123". "azerty". "123456789" are the most common passwords and the first guess of the tools based on dictionary attacks. Rainbow dictionary attacks are well explained in http://en.wikipedia.org/wiki/Dictionary_attack#Pre-computed_dictionary_attack.2FRainbow_table_attack are based on precomputed databases of password hashes as the key.
"Pre-computed dictionary attacks, or "rainbow table attacks", can be thwarted by the use of salt, a technique that forces the hash dictionary to be recomputed for each password sought, making precomputation infeasible provided the number of possible salt values is large enough"
Then you can increase the security of your app by enforcing stronger longer passwords, like the mandatory use of all of lowercase, uppercase and digits, avoid repeated letters and allow non alphanumeric characters, and forbid passwords less than xx bytes. See section 3.2 of http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf about strength.