Hot answers tagged

5

The problem with this approach is that the same identity is used by every destination, so sites can swap notes to see where you've been and draw correlations that you may not want to expose. There are several ways to solve this issue, such as the one used in the FIDO U2F security key. In this case, the device contains a symmetric key (not an asymmetric key ...


3

As @schroeder recommended, you should share the key between applications/servers using Public Key Infrastructure (PKI). It's not recommended that you implement this yourself. There is a great article called Choosing the Right Cryptography Library for Your PHP Project. This is worth taking a look at. It recommends the following libraries: Halite Libsodium ...


2

I think you're using non standard terminologies and that is making things confusing for you. I'll define the terms here: Private key: a string that need to be kept secret, used in cryptographic operations to authenticate or encrypt Public key: a string that are mathematically bound to the private key, not a secret. Used in certificate to decrypt and ...


2

The client or the server may request a renegotiation at any time. That renegotiation would include a new shared secret. The Server can send a Hello Request to trigger renegotiation (emphasis mine): The HelloRequest message MAY be sent by the server at any time. Meaning of this message: HelloRequest is a simple notification that the client ...


2

Using the same private key across separate domains is basically secure. If you authenticate to a system, you don't give away you private key, and that system cannot impersonate you. So you can use your key across work and personal systems, and a work system cannot then access your personal systems. However, there are often reasons to use different keys. For ...


2

There is a reason for encrypting the data where its stored - that being the storage may be compromised (directly or from a backup copy). If we agree that maintaining the data in an encrypted form is a good idea, then access to the decryption key must be restricted. You didn't specify if the encryption was symmetric or asymmetric. In the case of the former, ...


1

Since the communication between web and app servers are secured through SSL/TLS, the data's already being encrypted in transit by the session key - so I think your two options are very similar. There might be a slight advantage for encrypting for the application server's HSM key right off the bat so that the data's plaintext is never on the application ...


1

Fundamentally, to trust a computer, you need to verify that it knows something that only the computer you're expecting knows. This is how all certificates work: you assume that because they signed something with a key that only they could possibly know then it's actually the person you wanted to talk to. The same applies for computers: the computer has to ...



Only top voted, non community-wiki answers of a minimum length are eligible