First of all, let me explain u what i imagin to do:
Lets Imagin Bob want to get Authorizat by Alice (Classic Example), in my Example Alice is a Server.
Lets Imagin too that Bob and Alice already got each RSA Key (4096).
So Bobs Steps to do that would be:
Sign credits (Plaintext) with SHA512 and his private Key
Encrypt Signed Data and Credits with AES CBC 256
Encrypt AES Key with RSA
Sending Datas to Alice
So Alice would do the steps abouve from the opposite to decrypt it and verify its from Bob.
After Alice verify that its Bob, she generate a JWT Token and Sign this with her Private Key and Return it in the Response Header Authorization.
The JWT got a TTL from 3600.
So far so good but my Question is now how do we Protect the JWT from getting Stoled ?
Sure its Signed so its cannot be Modified (Except Attacker got Private Key from Server but my god then its anyways over).
Lets Imagin he would be Able to Break the HTTPS and stealing the token, put it in his Header and so he can Trick Alice to believe him untill its Expire and he need to send the Credits again.
I was thinking about two Options:
Option 1:
Always sending Credits and Decrypted to verify Bob.
But this would be costing Huge Perfomance each time of request and the benefits from JWT gets lost.
Option 2:
Sending a Unique ID and confirm its from Bobs Device (Encrypted, so same Problem like Option 1)
What could we do to protect that?
Maybe im Overthink to much, like always, but i would really like to know what in that case would be a "Best Practise".
Thank u already for ur Answers
So far so good but my Question is now how do we Protect the JWT from getting Stoled ?
As you already found out, it's https
Lets Imagin he would be Able to Break the HTTPS and stealing the token
If someone is able to break HTTPS then we have a much bigger issue then a stolen header. By default you could trust https (except special cases in some countries)
Let's assume the channel is not secure, you may for example sign every message separately (with an unsecure channel it's not enough to secure just a header).
Well, If Alice is not sure of who is sending the request then so is Bob, So its a two-way problem, No one is certain of the other's identity, You can fix that with a singed certificate from a certificate authority.Where you send with the signature a certificate, And this certificate is singed with the private key of the certificate authority (a third party), Which insures that the connection between the client server is secure and prevents any modification.
Related
This may sound a bit naive but I am missing something and I want someone to enlighten me.
To prevent man in the middle attacks where your password in plain text could be easily read, client Side Encryption is done where the password is encrypted so a man in the middle can only find data which is gibberish for him. However, for the encryption, the server needs to send a key over the network.
So, my question is, if a man in the middle attack occurs, then he would be able to see the key as well which was sent for the encryption on the client side. With the key in his possession, the encrypted password can be very easily decrypted. Hence, the whole purpose of the encryption is defeated.
What am I missing here?
First, a precision: the attack you are talking about is not a MITM but passive eavesdropping. In a MITM, the attacker relays back and forth messages from the two parties.
Sending a symmetric key along with the encrypted data would of course be silly as an eavesdropper would sniff it as well as the data. This is why asymmetric encryption (aka public key encryption) is used.
In asymmetric cryptography, ciphers do not operate with a single key but with a key pair, composed of a public key and a private key. Public and private key are created together at the same time using a special algorithm and they are strictly connected to each other. The client encrypts the data with the server's public key, which is the only key that is shared publicly; this data can only be decrypted by the server with the server's private key. The communication from the server to the client is done in the same way.
You might want to read about PKC here:
https://enigmail.wiki/Introduction_to_Cryptography,_PGP,_and_Enigmail
https://en.wikipedia.org/wiki/Public-key_cryptography
It is worth noting that a MITM attack can actually happen at the moment one of the parties shares his public key with the other:
First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory's public key.Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice. [Wikipedia]
This is actually the weak point of PKC; the solution is either to use a centralized Certificate Authority (this is how it is done for the SSL certificates used in HTTPS), or use a shared Web of Trust. Both solutions have their advantages and drawbacks.
I've read and watched a lot of articles and videos about SSL AES and RSA, but one thing is ALWAYS missing in every explanation( or I just don't get it ) is how the client decrypts sensitive data that comes from the server!(e.g. how much money you have)
I get it that your public key can encrypt anything and send it to the server and anyone can have it, but what do you do when you want to retrieve something from the server?
Does it comes just as plain text?
Any of the articles and videos point that out, they all just say that you have a private key that you shouldn't share and a public key that you can encrypt your messages and share it in the internet, but they don't say how the client makes a GET request with a encrypted message and decrypt it so it can be human readable.
As it says in this link about AES:
Asymmetric cryptography works by having two different keys, one for
encryption and one for decryption. It's also often called 'public key
cryptography' because it's possible to make one key public (allowing
someone to encrypt a message) while keeping the other private (only
the holder of the private key can decrypt the message encrypted with
its related public key).
Any help is welcome!
I will leave some links about web security that I found useful to learn:
https://www.coursera.org/learn/internet-history/lecture/L7HzI/security-integrity-and-certificate-authorities
If you want all the details grab a copy of SSL and TLS: Designing and Building Secure Systems. For a more arid lecture, read RFC2246 The Transport Layer Security (TLS) Protocol.
The short story is this: during the TLS/SSL handshake the client and the server exchange a secret (the PMS, pre-master-secret). This secret is used to derive session keys, initialization vectors and HMAC keys for use by client and server. Each one uses this keys to encrypt and sign everything send from it's side, and each one use the other's key to decrypt and validate the data sent by the other.
Nothing ever goes in clear text, in any direction.
Authorization and authentication based on the certificate used is a completely orthognal issue.
I am considering building an API system that uses HMAC. The server and client will have a shared secret, the client will sign the requests, the server will validate, and proceed if all is well. The trouble with this sort of system is that the secret has to be stored in a way where it can be retrieved, such as a database. If someone were to steal the secret, they have the key needed to do basically anything that user is authorized to do.
I was thinking that there must be a more secure alternative. Are there any flaws with using RSA?
Client has the "public" key instead of a shared secret. (The public key must still be kept secret for my use case.)
Client will hash the message with SHA-1 or whatever as normal.
Instead of adding the hash to the message directly, the hash will be encrypted via it's public key, and then sent with the message.
Server has the "private" key (to decrypt messages) but has no knowledge of the "public" key. (This is the part that makes this more secure than the normal approach. If the database is stolen, no keys are stolen that can impersonate a user.)
Server will decrypt the hash and validate the message as normal.
Is there anything wrong with this approach? Are there known implementations of this or something similar?
It depends on the asymmetric cryptosystem you chose:
(EC)Diffie-Hellman: It does not work. Publickey is directly derived from the privatekey via the generator, e.g. [d]G = Q
RSA: Usually people chose fixed publickeys like 0x010001. This is done for efficiency reasons. If you take a large enough, fully random e and derive d from it there is no possibility to calculate p and q given d and N OR e and N. Actually they are pretty equally then and the label private and public don't make much sense anymore. All that relies on a smmyetrical property of RSA. Be sure not to walk into textbook RSA issues. And be sure to ask enough clever people about it, this is just my thoughts on it.
If you base your crypto system on a proof of possession of a secret you need to, well - keep it secret :)
But yes, if you dont need the speed of a symmetric authentication then you can use a assymetric signature. Typically it is done with a signed hash, but you can also use a signed hmac.
The terminology is normally, that you sign with a secret key and validate with the public key (even when the signing operation looks like an encryption).
How does challenge-response authentication prevent man-in-the-middle attacks? I read the wiki article but still I cannot understand.
In general, challenge-response systems do not necessarily prevent man-in-the-middle-attacks: If Alice is trying to tell Bob her bank account number, this protocol, which does implement some challenge and response, won't provide integrity or privacy:
Alice: Bob, is that you? // first challenge
Bob: Yes, Alice, it is me, is that you? // first response, second challenge
Alice: Yes! Great. My account number is 314159. // second response, and result
Mallory could answer "yes" in place of either Alice or Bob, could fake the third 'result' message, or could listen in on the third message.
Even if the challenges are improved, to something like: "Please hash 0x31415926 prepended to our shared password", data transmitted in the clear (or under weak/poor ciphers or with poor key selection) would be subject to loss of privacy, and data transmitted without any message authentication checks could be subject to modification by a third party.
Where challenge/response protocols really shine is in preventing replay attacks: if Alice just sends Bob a message along the lines of "Please debit my account $5 and credit your account $5", Mallory could record the message and replay the message to deplete Alice's account.
A good challenge/response system will generate a new challenge for every transaction or session (and make sure that previous challenges are not reused!), so that session transcripts cannot be spliced together to create new fraudulent systems.
I hope this helps, but I'm afraid without more detailed idea of where your doubts are coming from, it'll just be noise.
User sarnold already provides a good answer, I'd like to drag attention to the following.
Challenge-response solves two problems - makes sending the secret in plaintext unnecessary (hash-like product is sent) and prevents replay attacks (since challenges change every time). It doesn't do anything beyond that - it doesn't authenticate anyone to anyone on its own, it is only an improvement of a plaintext protocol where the client sends his username and password (the secret) and the server decides whether those are correct.
So if there's some party in the middle it won't help detect it or prevent it from impersonating as the client for that specific session, yet that party will not gain access the the secret, since the secret is never sent in plaintext, and that party will be unable to impersonate again by doing a replay - it can only work impersonated during that very session.
Question for all the SSL experts out there:
We have an embedded device with a little web server on it, and we can install our own SSL self-signed certificates on it. The client is written in .NET (but that doesn't matter so much).
How can I authenticate the device in .NET? Is it enough to compare the fingerprint of the certificate against a known entry in the database?
My understanding is that the fingerprint is a hash of the whole certificate, including the public key. A device faking to be my device could of course send the same public certificate, but it couldn't know the private key, right?
Or do I have to build up my own chain of trust, create my own CA root certificate, sign the web server certificate and install that on the client?
What you propose is in principle ok. It is for example used during key signing parties. Here the participants usually just exchange their name and fingerprints of their public keys and make sure that the person at the party really is who he/she claims. Just verifying fingerprints is much easier than to verify a long public key.
Another example is the so called self certifying file system. Here again only hashes of public keys get exchanged over a secure channel. (I.e. these hashes are embedded in URLs.) In this scheme the public keys don't have to be sent securely. The receiver only has to check that the hash of the public keys matche the hashes embedded in the URLs. Of course the receiver also has to make sure that these URLs come from a trusted source.
This scheme and what you propose are simpler than using a CA. But there is a disadvantage. You have to make sure that your database with hashes is authentic. If your database is large then this will likeley be difficult. If you use CAs then you only have to ensure that the root keys are authentic. This usually simplifies the key management significantly and is of course one reason, why CA based schemes are more popular than e.g. the self certifying file system mentioned above.
In the same way you wouldn't and shouldn't consider two objects to be equal just because their hash codes matched, you shouldn't consider a certificate to be authentic just because its fingerprint appears in a list of "known certificate fingerprints".
Collisions are a fact of life with hash algorithms, even good ones, and you should guard against the possibility that a motivated attacker could craft a rogue certificate with a matching fingerprint hash. The only way to guard against that is to check the validity of the certificate itself, i.e. check the chain of trust as you're implying in your last statement.
Short:
Well in theory you then do exactly what a Certificate Authority does for you. So it should be fine.
Longer:
When a Certificate Authority signs your public-key/certificate/certificate request it doesn't sign the whole certificate data. But just the calculated hash value of the whole certificate data.
This keeps the signature small.
When you don't want to establish your own CA or use a commercial/free one -
by comparing the fingerprint with the one you trust you'll gain the second most trustworthy configuration. The most trustworthy solution would be by comparing the whole certificate, because also protects you from hash collision attacks.
As the other guys here stated you should make sure to use a secure/safe hashing algorithm. SHA-1 is no longer secure.
more detailed informations to this topic:
https://security.stackexchange.com/questions/6737
https://security.stackexchange.com/questions/14330