Is it possible not to transfer the password to the server, but to encrypt the connection with it (for example, via sockets)?

Question

JavaScript

Why are there no web applications that use something like this security scheme:
p is a password, F (p) is a higher order function that takes a password as input and returns a function that encrypts (synchronous encryption) text using a password, like

function getEncoder(password){
return function(message){ return encode(message, hash(password)); }
}

A message of the format {login, F(p)(login)} is sent to the server, the password hash is also stored on the server, with the help of which it is decrypted.
If you need to increase the complexity, you can use something like (uniq_salt is transmitted from the server, a new one for each connection) blowfish(blowfish(uniq_salt) XOR blowfish(password)) as a key , for example. A sufficiently long salt will make the selection almost unrealistic.
All further communication between the server and the client is already encrypted, the password is not transmitted, everything seems to be safe, no?
I'm not a cryptographer, explain to me what I'm wrong about, or why they don't, please.

Answer 1

TLS works like this .
The problem is, the truth is that the key must somehow be transmitted to the server for the first time, and this requires asymmetric encryption.

• the client connects to a server that supports TLS and requests a secure connection;
• the client provides a list of supported encryption algorithms and hash functions;
• the server selects from the list provided by the client the most reliable algorithms among those supported by the server, and reports its choice to the client;
• the server sends a digital certificate to the client for its own authentication. Typically, a digital certificate contains the server name, the name of the CA, and the server's public key;
• the client can contact the server of the trusted certificate authority and confirm the authenticity of the transmitted certificate before the data transfer begins;
• To generate a session key for a secure connection, the client encrypts a randomly generated digital sequence with the server's public key and sends the result to the server. Given the specifics of the asymmetric encryption algorithm used to establish the connection, only the server can decrypt the received sequence using its private key.

Answer 2

In your scheme, it is provided that both parties already own one common key to communicate with each other. In this case, your scheme will work, since it will be a normal encryption with any block cipher.
The difficulty is precisely in distributing the keys between the two parties, so that no one can intercept and / or forge them.
In general, public ssh keys installed on web servers just solve this problem only from the reverse side. They give the client a password to send messages to the server, which cannot be quietly forged.

Answer 3

I believe that a person is looking for the ability to securely exchange data with a trusted source through untrusted (Internet) transports