New attribute as ‘encrypted’ and ‘algorithm’ for password type input field

feature name

New attribute ‘encrypted’ for password type input field

feature description

I would like to propose a new attribute to the input field that is responsible for the password. So … An incredible proposal for a better web in terms of security and futuristic

case1 “more secure”

<input type="password" encrypted="rsa" required>

How does it work? scenario!

1. Any user accesses a website and enters the email, password and username. After the email validation process, he accesses the site normally when he needs to log in with username and password. So far so good, the problem is that the user’s password is a very easy password to be discovered.
2. He doesn’t have the computer skills to use a password manager. He, the user, has no knowledge of how to use a computer. This user I call a common user. A home user.
3. It would be nice if we had a new attribute for html - the password type entry with the attribute: ‘encrypted’ and ‘algorithm’ to make life easier for ordinary home users.
4. My ideal scenario is to use rsa for public and private key as follows, every login that the user makes he puts the normal password - which can be even easy.
5. With this password, the browser takes the password and converts it to rsa. Then it generates 2 keys, a public key and a private key.
6. The private key is unknown to the user. If he needs to know the decrypted password, he must provide his operating system login password in the browser of his choice.
7. I can give a very good example here, the brave browser has the following url to access the users password: “brave://settings/passwords?search=password”
8. Every password type input field is automatically managed as rsa.

example 1 “Every password type input field is automatically managed as rsa”

image1131×734 43.1 KB

Notes

1. This is only decrypted when the user enters a password in the browser to decrypt a password.
2. Many of these passwords are easily decrypted as they are text only. There may be systems or viruses that work with the copy of text that the user types. My idea is to prevent passwords from being decrypted when the user copies and pastes.
3. When the user is in the copying process, the password is the public key
4. There is a library that is responsible for encryption here tweetnacl or argon2-browser
5. The general idea is that browsers take care of the password process, given that there are still sites that do not use good security measures.
6. In addition, most users have easy passwords that are not secure at all.
7. As systems can be complex to take care of passwords, semantically they could use browser resources.
8. References/there are several proposals here: proposal-add-curve-25519-and-cruve-448-to-the-web-cryptography-api, draft-spec-secure-curves-in-web-crypto
9. The responsibility for more data security should lie with the web engines (html, js), browsers, companies and people.
10. The images are illustrative and were taken from Google images.

Solution

1. Web or browsers must provide means of clipboard encrypted passwords

References

• https://www.makeuseof.com/reasons-shouldnt-use-browsers-password-manager/
• https://www.addictivetips.com/windows-tips/is-it-safe-to-copy-paste-passwords-from-your-clipboard/
• RSA | What is RSA? | Encryption Consulting

The password in the end still has to be some text value. Which is transmitted over the wire, hopefully on an HTTPs site. Regardless though, if an attacker has local code executing, all bets are off on securing that. As they could just as easily snoop network traffic combined with clipboard spying.

This seems to purely be targeting the local password storage aspect as well, which is strange for an HTML attribute (or anything web-related) to care about. The local storage happens in the OS Keychains. If they are compromised, the user is in much bigger trouble. The OS Login password is what protects that keychain, so using it again to be the password to the key pair is futile.

Do I believe browsers and OSes need to provide better APIs for credential managers? Yes. This proposal however I don’t see solving any problem but instead creating even more.

1. thank you very much for the comment, you are right

Do I believe browsers and OSes need to provide better APIs for credential managers? Yes. This proposal however I don’t see solving any problem but instead creating even more.

• My idea would be to do this, although I didn’t think of anything good initially

@Garbee I found a proposal that might save this feature or idea if accepted: [Proposal] Built-in E2E encryption into web browsers - concept: Privacy by design with Offline-only Storage

• I think and I may be wrong, but if there is a privacy by design with Offline-only Storage - we can specify in the html which encryption algorithm we want to use and with that the browser itself manages all this information in local offline storage