Products > Networking & Wireless

You may lose access to some of your third-party apps...

<< < (7/8) > >>

magic:
OAuth solves a real problem of having to store a copy of your password in every mail program on every machine, which can subsequently be used to completely pwn the account by anyone who manages to compromise one of the clients.

Problem is that OAuth is a byzantine solution from the land of "web applications" and ill-suited for the job. Much simpler, a separate password could be generated for just downloading mail, without access to the rest of the account. I suppose that was deemed too complex for the sheeple to manage.

Nominal Animal:
Even better would be if instead of passwords, one could use a public-key instead.

To simplify, public key cryptography is based on symmetric key pairs where anything encrypted with one half is decryptable by only the other half –– even knowing the encryption key won't help in the decryption! ––, and knowing one half does not reveal anything about the other half.

To verify that someone is in possession of one half of a public-key pair, you need the other half.  The keys are never transmitted even in encrypted form: instead, both ends just encrypt a prearranged message, and decrypt it to verify the other end knows the other half of the key.  The message does not need to be anything fixed: even a random message with a checksum (hash) will work just fine.  A symmetric cipher key used to encrypt the rest of the communication is what most forms of TLS uses.

The one service that supports these well is SSH.  "Identity" is the file containing each public key the user can use (per account on a remote machine), and ssh-keygen the tool used to generate the key pairs.  It adds the private (secret) half to ones identity file, and shows what to tell the server to accept; the server part containing the public half of the key pair.

Just think what it would be like when attackers subverting the servers only means they can control that service, and pretend to be that server to its clients, but not otherwise compromise the security of the clients at all.

magic:
I see no advantage.

The only potential problem is password reuse, but that is easy enough to prevent: make the server itself generate the password, and make it ugly enough that the user won't feel tempted. No usability issue here because the PW is only meant to be pasted into configuration of a mail client.

Google has such functionality, called "app passwords", but they only enable it on accounts with 2FA and even then it seems they prefer you to use OAuth instead |O

Nominal Animal:

--- Quote from: magic on July 21, 2022, 01:14:20 pm ---I see no advantage.
--- End quote ---
Well, the difference is that if someone manages to steal the user password by observing the server software, they can later pretend to be the user as long as the user does not change the password.  (Typically, the client sends the password over a TLS-encrypted connection.  The server prepends/appends the salt it has stored to the password, and hashes the resulting plaintext, and compares the resulting hash to the hash stored along with the salt.)

No matter how thoroughly you observe what the server software does, you can't pretend to be the user, when public key pairs are used.

Most companies detect and react to intrusions into their machines rather quickly.  It is the informing their users part that they fumble, because it is Bad For Business.  With public key pairs, as soon as the server is re-secured, future user information is safe.  Nothing an attacker could find out on the server lets them pretend to be the user afterwards, unlike when passwords are used.  With passwords, attackers might continue to have access to user information afterwards by pretending to be users, using passwords they observed being used while having access to the server, until users change their passwords.

But in most other ways, both passwords and halves of public keys can be considered as authenticating tokens: authentication is just verification of possession of the token.

magic:
The passwords could be revoked following a server compromise. But I guess it's more hassle for the users in such case.

Navigation

[0] Message Index

[#] Next page

[*] Previous page