5

The basic problem, as far as I can tell, is that hashing's flaw is that the password is in the hash. Asymmetric encryption's flaw is that the password is encrypted and can be reversed.

The posts that I have seen say don't use asymmetric encryption and use a better hash algorithm (bcrypt/scrypt/etc) to be "secure".

What if instead you used asymmetric encryption (such as Rijndael/AES) and encrypt a known plaintext value unique to each user with the users supplied password (could be hashed for better value) and store the result.

Would this not then provide an encrypted string that could be stored that protected the user's password from recovery? Or is there some inherent flaw that I am missing/overlooking?

Improve this question
3
  • The first rule of encryption is... – Iszi Jun 13 '12 at 14:53
  • 6
    AES is symmetric. – Peanut Jun 13 '12 at 15:12
  • 3
    "the password is in the hash." your question makes no sense what-so-ever. – curiousguy Jun 13 '12 at 21:46
7

I don't see what problem you're solving. Imagine what will happen if your database gets compromised. The attacker will have this encrypted string, salt, and (likely) the encryption key.

What keeps them from decrypting any user's salt or password, and having the password?

It's pretty hard to invent something that will be more secure than algorithms developed by professionals and have been "battle-tested" for many years (namely, bcrypt).

Improve this answer
5
  • Well, the point with this is that if I used Encrypt(plaintext:=salt, salt:=plaintext) instead, even if they got the private key for the encryption scheme and could decrypt every "password" in the database, the result of the decryption is the salt and not the password since the salt was used for the plain text and the password was used as salt. – Earl G Elliott III Jun 13 '12 at 15:29
  • @EarlGElliottIII So you basically swapped the normal storage procedure of the password and the salt? Then you're just relying on attackers not realizing you made this swap, which isn't very secure... – Oleksi Jun 13 '12 at 15:33
  • @EarlGElliottIII - So you want to encrypt the salt+password instead of the password. This solves no problem. – Ramhound Jun 13 '12 at 17:18
  • Ah, I think I found where my comm breakdown is. So, no, it is not a simple salt+password being encrypted. The encryption implementation of AES (in C#) is using Rfc2898DeriveBytes to generate keys based on a private key and salt. So this encrypt method takes plaintext and salt where the salt is used to derive the Key and IV for AES. – Earl G Elliott III Jun 13 '12 at 18:15
  • "It's pretty hard to invent something that will be more secure than algorithms developed by professionals and have been "battle-tested" for many years (namely, bcrypt)." scrypt? Actually, being "developed by professionals" and "battle-tested" is not the proof of anything. – curiousguy Jun 13 '12 at 21:45
2

One of the best solution for now is to add a salt+pepper to an hashing algorithm (not md5 neither sha1 since they have been reported has broken. For more information about their status, click here for md5, and here for sha1. Moreover, this answer on StackOverflow complete my words).

Moreover, if you use BCrypt as your hashing algorithm, you add a level of complication for a possible attacker since the time to crack is lower over time :

"bcrypt is an adaptive hash: over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt."

Improve this answer
5
  • SHA1 is secure provided you use a salt. MD5 is no longer sure even with a salt. If you combine MD5 and SHA1 and a Salt then you hit the golden ticket. – Ramhound Jun 13 '12 at 16:04
  • "not md5 neither sha1 since they have been reported are not so secure now)" how are they not secure? – curiousguy Jun 13 '12 at 21:44
  • I updated my answer. – Cyril N. Jun 14 '12 at 5:27
  • 5
    @Ramhound, At 2,000,000,000 SHA1 hashes per second, a 6 character password with salt is brute forced within 10 minutes. We really do need the Hash-Crypt-Algorithms (e. g. Sha256Crypt, Sha512Crypt, BCryt, SCrypt). They use multiple rounds with input variations based on the round number. – Hendrik Brummermann Jun 14 '12 at 9:21
  • 1
    I prefer BCrypt for it's "slowerness", but yeah, we definitely need Hash-Crypt-Algorithms, not just hashing algorithms. – Cyril N. Jun 14 '12 at 9:44
1

The solution you describe is, actually, hashing.

Consider the hash function MD5. It works by starting with a conventional fixed value (the "IV") of length 128 bits. Then, for each 512-bit block of input data, a compression function is computed, which takes as input the current 128-bit state and the 512-bit message block, and outputs the next 128-bit state. If you look at how the MD5 compression function works, you will see that it is similar to a block cipher (a generalized Feistel scheme with four sub-words) where the 512-bit message block is used as the key. So MD5 really operates as you describe it: encrypt a fixed value, with the password as key. If the fixed value is user-specific, then it is a kind of "salt" (and that's good for password hashing).

So your question is: can't we build a hash function out of a block cipher ? And the answer is: yes, but it requires some care. A typical block cipher such as the AES is designed for encryption and its security has been analyzed in that context. When you turn a block cipher into a hash function as described above, you are relying on the block cipher being robust in ways which have not been thoroughly explored -- you need the cipher to be resistant to related-key attacks, which are a non-issue as far as encryption is concerned, but can be deadly to a hash function. For instance, the AES is known to be somewhat weak with regards to related keys, so using it "as is" in a hash function is not necessarily a good idea.

Whirlpool and Skein are two hash functions which reuse a block cipher -- in both case, a specialized block cipher, optimized for resistance in that specific situation.

Regardless of the details of hash function design, any password storage system has a big, glaring weakness, which is that it stores the password or, at least, a password verification token (something which can be used to decide whether a given password is correct or not). Passwords come from the brains of human beings; they cannot be strong. It is highly possible to enumerate most potential passwords.

It is unavoidable that a server which verifies passwords contains enough information to, say, verify passwords. Therefore, if an attacker can get a dump of the server's disk, then he also gain that power, and can try passwords "at home". This is an offline dictionary attack. The only known defence (arguably, the only possible defence) is to make each password verification inherently slow, preferably in a configurable way. THAT is the point of bcrypt: the password hashing uses millions of elementary operations, without any known shortcut, so that the attacker will have to pay a high price for each try.

A homemade hash function, built from a block cipher, will fail at that -- unless you define it to use not one encryption, but one million successive encryptions. It would still be homemade (that's very bad in cryptography; don't trust homemade designs), but at least it would not be as awfully weak with regards to dictionary attacks.

Improve this answer
-4

Hashing is used to secure the Databases of Web Applications, mainly. They are used because they are fast! Encryptions, in general, are NOT fast.

So, if you write Web Applications, you need Hashes and NOT encryptions! If you are creating something like Password Managers, you can use Strong Symmetric Encryption Algorimths like AES!

If you need more explanation or any other Help, don't hesitate to comment!!!

Improve this answer
2
  • 4
    What? You want to use something really slow when storing a password to deter brute-force attacks. This is one of the selling features of things like bcrypt. – Oleksi Jun 14 '12 at 15:07
  • 5
    akatzbreaker you seem to be misinformed about what cryptographic hashing is and what its purpose is. I recommend reading en.wikipedia.org/wiki/Cryptographic_hash_function – chao-mu Jun 14 '12 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.