Never send a password again. The idea is to only send password hashes. The simple solution is to send a hash of password plus username. Wow so simple; never again do websites need your actual password.
The modern password field or safe box simply tells the user or computer that certain protective standards are present. If one tries to log into a website from a computer or browser without this feature, their password will be subject to a typical lack of safety.
When safe, a green box could surround the field, or a roundish square could appears on the right side. More important though is for the browser to demonstrate externally that the safety feature is on, like domain name verification shields.
Instead of saving all our passwords somehow, which is dangerous, we can use 3 to 5 passwords for everything. (Just using our computer, others can often easily access our private data, and writing on paper or in text is also unsafe.)
This change in mindset protects your passwords from everyone, while keeping a few in your memory. Even if you choose to save them, they are never send across the air.
A Slightly Better Solution
To summarize, the safe password field allows websites and browsers to agree on using a modified password. The browser, OS or hardware takes over and handles the safe-keeping of the password. (Normally, reputable websites never save your actual password; they create a hash of it plus a random seed. Then to verify, they check if your incoming password creates the same hash.) But why ever send it to begin with, if you can do this hashing on your side?
But instead of using the username for the seed, the website can send one or the computer can create one, or both. By differentiating seeds by domain name, the safe box field automatically changes what is sent based on domain. Thus the client-side computer will never log into a fake or mistaken site. Otherwise, phishing attacks can be difficult to prevent among an untrained user.
Technicalities
Lets walk through the process. The very first time password is created/requested, a website sends the seed and its matching seed signature. The safe box takes the seed, adds its own, hashes the password and sends the password hash, the local seed and the seed signature. (The seed signature just lets the website know which server-side seed to use with your username.) The website remembers the double seed and password hash. (The server/website only keeps this full seed to send it to you when needed.) The computer remembers the double seed to hash the password every login.
Normally, no extra costly pings or sends are required. It is not too much to ask a browser or OS to remember seeds for each domain. If a new or public computer is used, the website will immediately know, because the browser safe box will request the seed. The website then may refuse cooperation until further verification happens, such as two factor authentication.
The computer using safe box, keeps about 3000 random seeds with its own particular index, with the website’s domain name being the lookup key. But if lost, the client side can request the seed upon login.
Conclusion
This seems intuitive. I'm surprised i’s not being done already, but I know it is not normal because I've created websites myself. Why make websites secure passwords, when you can handle it server side? We need only to agree on a protocol and hashing algorithm. Thus a password is never sent anywhere and cannot be found, misapplied, or copied to try elsewhere.
