I understand why the password should be salted and hashed before being saved into the database, but my question is if it needs to be hashed on the browser side or just sending plain-text password over HTTPS is considered to be secure.
If it is ok, is there any document which I can use to prove to my client that the system is secure? If it's not, what are the best practices?
It is standard practice to send "plaintext" passwords over HTTPS. The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.
Encrypting the password before sending it in HTTPS doesn't accomplish much: if the attacker got their hands on the encrypted password they could simply use it as if it were the actual password, the server wouldn't know the difference. The only advantage it would provide is protecting users that use the same password for multiple sites, but it wouldn't make your site any safer.
type="password" ortype="text" is only about obfuscation.. Right? No matter HTTP or HTTPS, having type "password" vs "text" only means that you get obfuscation, the inability to copy paste from the field and that's it FTMP. Over HTTPS, every pice of anything is encrypted as a whole, so to use JavaScript to hash or encrypt that field will be overkill in most scenarios. otherwise, on it's own, the type="password" of an input field only provides dots (a visual representation of each character) for obfuscation and some basic interaction restrictions.
Commented
Dec 27, 2018 at 18:14
Sending passwords from the browser to the web server over HTTPS is standard practice. The password is encrypted by virtue of HTTPS as it is sent. See https://stackoverflow.com/questions/962187/plain-text-password-over-https
When a user types a password in an HTML <input type=password ...> field it will normally be sent to the server as-is, i.e. without any hashing or salting. This is why this should never be done without HTTPS.
But if your HTTPS is solid this should be OK. It is what most web applications do.
