Closed kaustavdm closed 9 years ago
HMAC-SHA1 -> AES-256-CBC on the client side makes it safer I think. Even if you decrypt the AES, you get the non-decryptable SHA1.
I think that works smoothly. We transfer dynamic strings each time. This still remains as a breaking change for user passwords, but would be a nice thing to have.
Instead, I'll look into the possibility of not sending the key
and iv
for the AES.
Well, SSL/TLS already takes care of what we we're trying to do with AES-256-CBC encryption, on the same line, but in a much sophisticated way (it actually uses client's MAC ID - which we can not do from the application layer even).
If the concern is not having to remove that part of the code, then that's okay. But it's not really adding anything extra on the feature side, but on the code & processing.
That's what I wanted to know. And yes, I was trying to sell the thing about not removing code. But then, I am lazy :stuck_out_tongue_winking_eye:
The idea is not to have the cleartext password decrypted at any stage in the app. #40 works, but is still potentially vulnerable.