Yes, this is normal - data security in WEB forms, as a rule is provided exactly by SSL, present in the HTTPS connection - and in fact, if the page is using HTTP and not HTTPS, all data transits in open - why HTTPS is so important, and has become the standard way of viewing any large site.
In particular, in WEB development, you can easily notice that for both the javascript of the page, and for the code that receives and treats the data of any form, the data of the password field are in plain text, treated in the same way as any text field.
It is possible to use an extra layer of encryption, using javascript, so that the data is encoded even before it is sent - but this is not a widespread practice because it has few gains on the HTTPS itself - and is very difficult to do well to the point of, in fact, improve safety (and not only have an illusory sense of security).
In particular, if the source browser is compromised by a malware that allows you to intercept Post data prior to the encoding used in the HTTPS connection, the same malware could also intercept the data before coding in some javascript (and also the javascript code used for the extra encryption and the keys you are using): ie the case of a well targeted attack, the vulnerability would still be there.
A technique like this, which tried to encrypt by obscurity combined with other techniques, inserting fake keyboard events in the typing of the password, separating the characters of the password in separate data packets, and using another layer of encryption, however, could rather avoid or slow down generic or automatic attacks (but as described above, even with all this care, you would be vulnerable to a refined attack whose target was specifically your application/site). However, I in particular consider that the feeling of being safe when you’re not is worse than knowing that you’re vulnerable.
Excellent answer, quite complete, I wish I could give +1 more than once! As a complement, it is good to point out that any transformation that the password undergoes before it is sent does not bring much additional security, since what you present to the server is what counts as access pass. That is, even if an attacker does not discover his original password, if he discovers what is being sent in the HTTP POST (the result of the transformation) he can use that to log in on your behalf.
– mgibsonbr
I haven’t even finished reading your answer, but from where I started to where I left off, I can tell that this is the most appropriate response.
– Edilson