For communication between the client and the website
The usual practice is not executing password-based encryption, but rather performing Diffie-Hellman Key Exchange (DHKE ) preferably the EC version ( ECDH). After the ECDH, apply the hash function to derive a session key and encrypt it with AES-GCM or ChaCha20-poly1305 so that one can have confidentiality, integrity, and authentication. Actually, choose AES-GCM-SIV or xChaCha20-Poly1305. Don't implement on your own, there are already existing libraries ready to use like the libsodium.
KEY using AES-128, If P is less than 128 bits, padded with 0 and create 128 bits, any problem if average pw length is 6
Yes, there are always problems.
We know that the usual password choices from general users are not good. The pwned sites showed us many many examples over history.
We should talk about not the size of the passwords but rather the strength of the passwords (size of 6 of what? If you define then we can talk). A normal $p$-bit password can have much less than $p$-bit strength. We don't have a calculation method for arbitrary random passwords ( the more they know about you the fewer strong the usual passwords). On the other hand, the strength of passwords is calculatable if generated with dicewere or Bip39-like generation methods ( see the calculation method for Bip39 ).
Now assume that $P$ has exactly $p$-bit strength.
Directly using a password with padding 0s is really a very bad idea. Never do this and at least hash it and trim the result to get 128-bit, though this is not enough either.
Assume that the strength of your password is less than $2^{92}$ than the collective power of the Bitcoin miners can brute force it in a year even simply hashed. Or even your password exists on some rainbow tables for that hash function, which is easy to figure out (one needs to add salt to mitigate rainbow tables).
For cryptographic key derivation from password, we actually have special functions and they are mostly named Password based Key Derivation functions. PBKDF2, Scrypt, Bcrypt, Argon2, and Balloon Hash are examples, where Argon2 was the winner of the password hashing competition held in 2015. Why do we use special hash functions?
Iteration count: Remember that $p$-bit can be achieved. Now, add $s$ iteration to hash function, $H^s = H(\ldots (H(passwords)\ldots)$. So you increased the attack cost by $s$. I.e. The attacker will spend more time for each password candidate. Nowadays, the moderators choose $s$ around $s = 1M \approx 2^{20}$
Parallelization count: Normally, the attackers can not only use CPU but also use ASIC, FPGA, and GPU to increase their attack range. Memory is costly on ASIC, FPGA, and GPU, if you increase the memory usage of the password hash function then you reduce their parallel run capabilities, too. This is hard to quantize, at least from here ( lots of differnt platforms to talk about).
Thread count: This time, the password hash algorithm uses more than one thread to derive the key in a way that there is no way to reduce this thread count. This clearly kills the massive parallelization. We can simply say for $t$ parallelization the cost increased at least $t$-times.
So, what to do
- Always use a password-hashing algorithm with good parameters to derive cryptographic keys. One should choose at least from Scrypt, Argon2, or Balloon. See their documentation to decide the parameters.
- Use good passwords with calculatable strength. One can use dicewire or Bip39 or a similar system.
- Once you get the number, you can see how secure your password is. It is quite easy to pass 128-bit strength. Now, your 128-bit encryption can be your problem.
- Always use 256-bit encryption. 128-bit encryption is not secure against multi-target attacks. Also, due to the possibility of quantum computers that can run Grover's algorithm, 128-bit encryption is not considered secure. Use 256-bit cipher like AES-256 or ChaCha20 to be saved against all.
