Usually to check password validity we used to create over given password it hash value and compare it with stored one. So password protection relies on strength of hashing function.

Could it be used another approach?

1. Let's say we have encryption algorithm (doesn't matter which one).
2. Let assume we have some array of predefined chars (for instance just digits)
3. Then generate random sequence of chars consisting predefined array (for instance just random sequence of digits)
4. Encrypt sequence with our algorithm with given password and store it somewhere in safe place (let's call it as saved value)
5. EDIT Also presumed that channel between client and server provides confidentiality and integrity

Now time to check password validity

1. Trying to decrypt saved value with probe password
2. If decryption successfull (meaning mathematically correct) check decrypted value to presence of predefined chars array. For instance if value consists only digits - we assume that password is correct. If decrypted value contains extra chars (except digits) - we would assume that password is incorrect.

Now question: what do you think about crypto-strength of this method?

• I am no expert in cryptography, but I guess all passwords are essentially known if your predefined array is leaked (and the encryption method is known). Hashing does not have that problem. Even if the hashed values are leaked (and the hashing alg is known), there is little but brute-force you can do to figure out the original password (afaik). Feb 17, 2011 at 9:58
• And in my case the same is right. Say if stored value leaked, attacker even knowing encryption algorithm should somehow restore unknown array (which he knows only consist some digits). So the only option again is brute-force - or I'm not right? Feb 17, 2011 at 13:07
• @barmaley: Some people think you don't need to be a cryptographer to do cryptography. They are very, very wrong. If you don't know what you're doing, you'll make mistakes. Unfortunately, some engineers are not aware of that, and as a result some funny things happen, for example WEP uses a stream cipher together with CRC. Feb 17, 2011 at 16:12
• ps: I am not sure if we want to allow discussions on crypto protocols proposed by non-experts on the site. IMHO, if this is a research-level question in theoretical computer science, then it falls in the domain of unpublished work which is not peer-reviewed policy, so I am voting to close the question as "not a real question". Feb 17, 2011 at 19:23
• barmaley, I think crypto protocols are complicated constructions and people who lack the basic knowledge on the topic should not design them. If you seriously want to design crypto protocols you should at least have the basic knowledge in crypto, in which case you should start by reading the crypto textbooks. IMHO, trying to reinvent the wheel and asking researchers to verify it is a bad idea. I don't like the idea of non-experts lacking basic knowledge submitting the ideas they come up with here and ask experts check their correctness. The previous and this comment are personal opinions. Feb 18, 2011 at 22:42

The first problem you face is that a password cannot be used as an encryption key. For instance, let the password be $%^gHk23. How do you interpret this as an AES-256 key? The second problem is that the client has to send the password in clear, and then the server tries to make a key from it, and decrypt saved values. Thirdly, the scheme is fixed. No salting whatsoever is incorporated in it, and thus it is vulnerable to a variety of attack, most notably the dictionary attack. The hashing scheme you described at the beginning of your post is very old. Today, an extremely secure password-based identification scheme, named SRP, is gaining momentum. (See also the demo.) • 1) I meant based on password calculate hash value which use as say AES key... Or I'm not right? Feb 17, 2011 at 12:43 • About salting and SRP - let me review those methods. I'm sorry - I'm not professional cryptographer... Feb 17, 2011 at 12:43 • @barmaley: Please review this part of your question: "So password protection relies on strength of hashing function." To me, this says that you are going to use a method which is not based on hashing. Then in a comment above, you said: "I meant based on password calculate hash value which use as say AES key." This seems contradictory, right? Feb 17, 2011 at 13:24 • @barmaley: If the channel is secure, you must mention this as part of your model, since this is very important. Please clarify what you mean by "secure": Is is just confidential, or provides both confidentiality and integrity? Moreover, please decide if you want to use hash functions or not. (If I were you, I'd allow the use of salted hash mechanisms.) Feb 17, 2011 at 13:27 • The mention of salting and dictionary attack is timely, because Anonymous just used rainbow tables to hack HBGary. HBGary could have defended against that by salting their passwords, which they did not do, despite being a professional security company. Ars Technica has produced some fascinating articles about this. The one that discusses salting and rainbow tables is here. Feb 17, 2011 at 14:29 As much as you're being downvoted and attacked, your idea is absolutely right, correct, and valid. You've nearly reinvented bcrypt. Let's say we have encryption algorithm (doesn't matter which one): I'll choose blowfish. Then generate random sequence of chars consisting predefined array (for instance just random sequence of digits) I'll pick a sequence of 24 characters. And even better if it's an even multiple of the blowfish 8-byte blocksize:  OrpheanBeholderScryDoubt \______/\______/\______/ | | | 8-bytes 8-bytes 8-bytes  Encrypt sequence with our algorithm with given password and store it somewhere in safe place (let's call it as saved value) The password needs to be transformed into a 72-byte encryption key - the key size of blowfish. Bcrypt does this with a function called ExpensiveKeySetup: String password = "correct horse battery staple"; Int32 costFactor = 12; Byte[16] salt = CryptGenRandom(16); Byte[72] key = ExpensiveKeySetup(password, salt, costFactor);  And then we'll encrypt our random sequence of chars. And just to be extra secure: we'll encrypt it 64 times: Byte[24] ciphertext = BytesOf("OrpheanBeholderScryDoubt"); for int i = 1 to 64 do ciphertext = BlowfishEncrypt(cipherText, ref key);  (Why use 3-DES when you can use 64-DES!) And now you have your stuff to store: • costFactor • salt • ciphertext Bcrypt coverts the salt and ciphertext to base64, and gives you a string: $$2b$$[costFactor]$[salt][ciphertext]


Such as:

$$2a$$12\$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Now time to check password validity

Try to decrypt saved value with probe password

Rather than decrypt, just repeat the encryption of "OrpheanBeholderScryDoubt", with the password, and the same salt. And compare the result to what you stored.

It would be nice if the community was nice, helpful, or knowledgeable - rather than just attacking or using clichés.