Password checking process for common websites

Question

This will seem like a very basic question, but I wanted to make sure I don't miss something.

When you enter your password in a login page and you press enter, what exactly happens right after until you're "approved"? I mean in common/regular websites.

I know some websites like Password managers, secure email providers etc. will generate the hash directly from your computer and send the hash to the server, never send your password.

However, for common/regular website my understanding is that the password in clear will be sent to the server. Whether the connection is encrypted in TLS(/HTTPS) or not is not an issue here, my concerns are about the server only.

When the password in clear arrives at the server, the server will compute its hash and compare it to its hash database. At this point it doesn't matter what hash algorithm is being used (bcrypt, sha-256, with salt or no salt, this is not the debate here).

1) Can you confirm this is the regular process in 2020?

2) What "mechanism" can make sure for us on the client side that the server will erase the password in clear from all types of memory right after it's computed its hash? Is this mechanism called "trust" or is there something to answer that concern?

Answer 1

1. Can you confirm this is the regular process in 2020?

It depends on what you mean with "regular" process. It is considered state-of-the-art for most use cases and recommended by established security standards and guidelines.

This doesn't mean that everyone is following best practices and you can see different protocols in the wild. Based on my experience, most established website use a similar scheme to what you have described.

2. What "mechanism" can make sure for us on the client side that the server will erase the password in clear from all types of memory right after it's computed its hash? Is this mechanism called "trust" or is there something to answer that concern?

"Trust" is a good answer for that. There is no reasonable technical way to prove that the server erased something. If the server component is open source, you can look at the implementation and trust, that the server is running the same code without modification. A company can also show evidence of a independent security audit that was passed. But again, this is an review that was performed at one point in time and does not allow you to deduce what has changed since.

Long story short, it comes down to trust. But why should the owner of the web server intentionally weaken its level of security? There is nothing to gain from an insecure implementation, so it is mostly trust in the requirements engineers and the developers that they know what they are doing.

Answer 2

Short answers: 1) No. In 2020 there are still many legacy systems that manage web password in an insecure way. The password management strategy depends on the quality of engineers that have developed the software and the age of software. 2) There are no such mechanism using standard HTTP/s protocol. Server components acts independently from clients, so there isn't any possibility to control the behavior of the server from client side, just the hope that backend engineers do their work correctly

Answer 3

To expand a bit on the existing answers:

At some point, the server needs to receive something that it can use to authenticate you. Whether it's a password, a hash or a client side certificate doesn't matter. That "something" will always end up somewhere in the servers memory. It might disappear from the active memory instantly, e.g. if the process exits after processing your request, but it might stay on the hardware for an indefinite amount of time, if no new process accesses that part of the physical memory, unless the server application explicitly writes the password memory after using it, which, while not unheard of, is quite uncommon.

If an attacker can access the memory of the target server, he most likely also has the ability to modify either the running program or the source code to intercept and potentially store your authentication token on reception. If he doesn't have access to the memory, the whole problem becomes moot, unless you also don't trust the regular programmers of the server application, in which case you are screwed either way.

A site could theoretically implement mechanisms where the aforementioned something constantly changes, e.g. by integrating a time element into a client side hashing mechanism, but at some point the effort becomes much bigger than the risk.

On the client side, you have no way to verify that any authentication tokens you provide will be erased immediately. Even if the source code is publicly available, you can't guarantee that the source code that is running is the one that is public. It could have been modified at any point, potentially even after starting the program on the server.

If you don't trust a page to secure their servers and maintain the privacy of your authentication information, your only option is to either not login (nor register) in the first place or simply use a (randomly generated) one-time email+password combination.

Note that all of this is still quite a bit simplified.
Security is a vast and complex topic.