4 ms·
How about any case where you're doing cram-md5 or hmac authentication? Because one of the basic requirements of those authentication schemes is that both sides
by Xylakant 15y ago
How about any case where you're doing cram-md5 or hmac authentication? Because one of the basic requirements of those authentication schemes is that both sides have access to the plaintext of the shared secret (a.k.a. password).
- jrockway 15y agoShared-key cryptography is the wrong choice for one-to-many communication. Public key cryptography solves this problem correctly. (You use public key cryptography to share a secret, which you then use as the key for whatever secret-key crypto you want to do.) Consider the case of VPNs. When you have two trusted routers to connect, you use a shared secret. That's because both routers are in the same secured datacenter environment; both are equally trusted. When you have users connecting to your VPN, though, you issue each user a unique certificate (which is a crypto-based identifier). This is because you can't trust individual users the way you can trust a server in your datacenter.
- Xylakant 15y agoI'm not talking about vpns and such but more about (rest-)api authentication. About what amazon uses to generate signed urls to S3-Stored files. It's an hmac used to create a signature using a pre-shared secret and some properties of the request (mainly the url) as input. The PSK must be available to both parties.
- deleted 15y ago[deleted]
- dekz 15y agoThat plaintext of the shared secret doesn't have to be the password, it can be some other authorisation token which acts as a first level of auth before a password hash scheme is used. As I said, there is _almost_ never a good reason for storing the passwords digested or encrypted.