I would like to seek for another way to save the credentials, which is used to verify the user trying to login, into my database.
I came up with this idea. Since I believe that even knowing a plaintext, and a corresponding ciphertext derived with the AES-256 cipher should not lead to the revealing of the key, when the key is properly long and random enough, may I take the password as the encryption key here?
Consider an example, suppose user 'test' should use 'apple' as his password. In the registration, the program works like this:
- Choose a random string of 32 bytes. Denoted by
- Construct the plaintext
P = Whirlpool(R:'test':'apple'); Here
Whirlpoolis the hash algorithm under same name.
- I would like to make the key more longer, so derive
Kas the key used for AES-256:
Pby AES-256, thus get the ciphertext
- So join
Etogether, we get the credential
AUTHthat should be saved to database:
And when we have later got one who enters the username, and password, we may verify that by doing:
- Look up for username, and fetch
- Separate this
AUTHand we got
- Use the given username and password, we could calculate
P', which is based on
Rfrom database, the username and the password from input.
- And we'll able to derive
K', a hash in Whirlpool algorithm with this password as input.
- So we use
K'to try to decrypt
E, and when successfully decrypted, compare the decrypted with
In short: may I use my password as the key in AES-256, and by comparing a known plaintext and the decryption result of stored ciphertext, to verify users, and to avoid leaking users' passwords after the database is somehow leaked?
In my view only knowing the username(with does little here) and the
AUTH should only leak the hints of how to construct a possible decrypt key. The attacker is able to know both a quite randomized plaintext(and he have no choice of customize) and a fixed ciphertext. And if here is AES-256, there should be no possibility to reveal the key(which is not the real password) basing on only this two factors.
And the randomness of this plaintext(derived from a conjunction of
R, username, password) is here also not important. But seems the randomness of the key may tell.
The last aspect of consideration may be the speed. To me, the speed is not a really problem, at least now. And although above process have used(either in registration or in verification) 2 times of hashing and one time of AES, we may however reduce the Whirlpool to only once. When I compare this to HMAC with whirlpool(two times of Whirlpool is used here), I see here is only one time of Whirlpool and one time of AES. Should AES faster than a hash algorithm like Whirlpool, I think there may be an advantage. But I'd appreciate anyone who would refer to this aspect.