During a Diffie Hellman keyExchange, if a man in the middle is able to get the values of the prime "p" and the generator "g". Can he now decipher the private keys or the shared secret secret generated ?
No, these are the public components of the key exchange protocol, and can be observed by an eavesdropper without compromising the security of the agreed key (assuming they have been chosen properly), as it requires the eavesdropper to solve the Diffie Hellman problem, which is considered difficult. This is described in more detail in the Wikipedia entry on Diffie Hellman.
It's worth noting however that the protocol as described there, whilst safe from eavesdropping does not in itself authenticate the parties involved, and so it is vulnerable to a man-in-the-middle attack if implemented without additional authentication.
Related
I wanted to use encrypted local PASETO tokens for the Request Object in the OIDC, but it turns out that I need to store the key somewhere to decrypt this request object, and it must be available unencrypted/unhashed as it will need the Request Object to decrypt. So I will have to store it as plain text in a database? Pretty dangerous. So I started to wonder how JWE works, but the documentation from https://datatracker.ietf.org/doc/html/rfc7516#section-5.1 about JWE encryption is quite confusing for me. Does JWE solve this problem of storing a symmetric key in a database as plain text or does it have other ways?
There are a few different solutions here, which solve different problems:
ENCRYPTED JWTs
These can be used when the app wants to prevent information disclosure. They are issued by the Authorization Server, which uses a public key to encrypt them. There is then a burden on the app to maintain a private key to decrypt them. See the Encrypted ID Tokens for some example usage.
REQUEST OBJECTS
These are often used to protect against man in the browser tampering. The app only needs to deal with public keys, which it already has access to, so the solution is easier to manage. Newer standards such as PAR and JARM are used, as in this summary.
JWT INFORMATION DISCLOSURE
If you want to avoid revealing sensitive data in access token JWTs, then the usual technique is to return only opaque access tokens to internet clients. This is easier to manage than encryption. See the Phantom Token Pattern for how this works.
SUMMARY
I would usually avoid introducing key management into apps. Aim to manage this in the Authorization Server instead.
I have asked many people about this question but they said, integrity must be conserved for the privacy of any communication system. Is it correct that integrity violation violate the privacy too?
Integrity is generally accepted as a basic security property, and maintaining security properties is important for protecting privacy, even if integrity itself is not typically considered a privacy property.
Integrity is a pre-requisite for being able to trust the communications that a user receives. If an attacker can modify the messages that I believe are coming from a trusted correspondent, then I might reveal information based on that message (the attacker could redirect me to a fake URL, or impersonate my friend and convince me to inadvertently reveal something confidential to the attacker). That is, integrity is a necessary building block for authentication, on which we have built many privacy assurances.
I would say integrity is also privacy-relevant in other ways. Privacy involves communicating choices in my communications, and if I don't have integrity of communications, I can't be sure that my preferences are expressed to the other party. And privacy can also include protection from intrusion -- without integrity, an attacker can modify the messages a user receives to include abuse.
We are currently implementing our authorization to a restricted resource by encrypting specific information and the password given to create a token using AES/CBC/PKCS5Padding encryption with a 128bit private key known only to the server.
Inside this token we place
hash of password(sha-512 and a random salt of 64 bytes)
expiry date
valid flag (boolean)
creation date timestamp
The server then encrypts this information using its private key and passes it to the client.
The client requests the restricted resource and presents this token to the server which decrypts it and validates the contents to provide access to a restricted resource.
We wish to do it this way to avoid keeping information regarding issued tokens on our server to avoid potential resource limitations.
Since I am not a security expert any help showing possible vulnerabilities or why this is a bad idea would be much appreciated.
Just send the hashed version for comparison.
Just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use functions such as PBKDF2 (aka Rfc2898DeriveBytes), password_hash/password_verify, Bcrypt and similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force. Protecting your users is important, please use secure password methods.
See Toward Better Password Requirements by Jim Fenton.
[DRAFT NIST Special Publication 800-63B Digital Authentication Guideline](
https://pages.nist.gov/800-63-3/sp800-63b.html)
NIST’s new password rules – what you need to know:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ by Sophos
I recently stumbled across this article on securing Web API endpoints.
If I'm using SSL, is there any advantage to encrypting the user string in the header? What are the risks if I include the user key (Id) as plaintext instead of ciphertext?
TLS is transport-level security. I.e. the data is not secured by TLS before the data reaches the transport and after that. If your data is long-term and/or you keep them elsewhere besides using during the transport session, then it might make some sense to keep them encrypted (and then transfer them encrypted if possible). If your data lifetime is short and the data makes sense only during the transport session, then there's no much sense in encrypting the data besides TLS.
The author of the article is basically combining the concepts of a user identifier and a user secret into a single cryptographic token. If you choose to send a user identifier in plaintext instead, then that user identifier must be kept secret (just as the token must be kept secret). As long as that secrecy is maintained there is no advantage to using the token.
Note that this system doesn't seem very secure as presented. If an attacker can guess a valid user identifier then they can generate a valid token. The author is basically using RSA as a glorified hash function. I'd recommend you look for another reference.
I'm encrypting some data that needs to stay on the client, and so will the Salt, Key and IV. Is there a standard way of handling this data on the client to prevent people from discovering it and encryption your data?
I can think of plenty of things to obscure them, but there must be an industry standard way of dealing with this issue.
There's no additional security risk if the IV and salt are known. IV's are safe to store in the clear, and salts are to help prevent precomputation and rainbow tables.
So you're really just talking about the key. There's a couple solutions, each with it's own tradeoffs. In your question, you only mention you need to encrypt data on the client. Does the client not need to decrypt?
If this is a Windows client, you can use the Data Protection API to protect the key under the users credentials.
Protect the key with a passphrase. If you don't mind entering a passphrase each time the client needs the key, this can offer reasonable protection, and it's supported in most cryptosystems like OpenPGP.
If the client only needs to encrypt, you can use a hybrid approach with public keys (like OpenPGP). In this case, you only store the public key on the client, and the private key somewhere safe. When you encrypt data, you'll generate a random symmetric key, and encrypt that under the client's public key. Now if someone compromises the machine, they won't be able to decrypt any of the session keys.
Use specialized hardware like a hardware security module or smart card. This is the most expensive route, but depending on your threat model might be viable.