I'm working with an API that requires the user's password to be encrypted with the server's public key before sending to the server. If the whole request, including username/password/etc. is being sent through HTTPS, isn't the password encryption redundant?
Depending on the server architecture, this kind of encryption can be helpful. For example, the TLS (HTTPS) connection may be terminated (decrypted) at the perimeter of the network in order to simplify load balancing or to scan the stream for malicious packets. Separately encrypting the password protects the password even from the edge servers, so an attacker who is able to compromise one of those still cannot gain access to the password.
Personally I stretch (i.e. PBDKF2) passwords before sending them. This ensures that the raw password is never seen by the server at all. But even in that configuration, an extra layer of encryption for the hash could be useful when the TLS stream is decrypted early.
Related
After much googling I'm still just as lost as I was when I started. I'm trying to make a secure request from one server to another in Node.js, and I'm unsure if sending the request through https (ex: https://someapi.com) is sufficient. Both servers are owned by me. One server needs to ping the other for verification/authentication by sending an API key + secret to it. Would my request from the requesting server to the authentication server be encrypted? Or would it be vulnerable to man-in-the-middle attacks?
I'm making the request from the main/requesting server like so:
const rpn = require('request-promise-native');
const options = {
method: 'POST',
uri: 'https://authenticationserver.com/api/verification',
json: {
api_key: API_KEY_HERE,
secret: SECRET_HERE
}
}
rpn(options)
.then((responseData) => console.log('successful'))
.catch((err) => console.log('error'));
Yes, using HTTPS is sufficient for this task.
The primary purpose of a secure transport protocol (like HTTPS, SSH, WSS, etc.) is to make man-in-the-middle attacks very hard. Because of the nature of the internet you cannot control the machines that your data travels through, so it's nearly impossible to prevent a man-in-the-middle attack, unless of course you control the entire network of computers like an intranet. Knowing this some very smart people invented Public-key cryptography to combat man-in-the-middle attacks.
Public-key cryptography exploits a feature of advanced number theory where the basic idea is that is very computationally expensive to factor very large prime numbers. Using this feature it is possible to generate two very large prime numbers, then using some complex mathematics you can encrypt data with one of the prime numbers in such a way that the only way to decrypt the data is to do the mathematic operation in reverse using the other prime number. These two prime numbers are referred to as public and private keys.
When two computers establish an HTTPS connection they share their public keys and negotiate an encryption cypher. Once a cipher is determined (like AES) an additional key must be generated by one of the computers and shared with the other, this is the key that will be used to encrypt and decrypt the actual traffic. This key, however, is first encrypted using the public key of the computer that will be receiving the key. The receiving computer then decrypts the key using it's private key and the process known as "handshake" is complete.
During this handshake you'll notice that the private keys are not shared over the network, this is the key to avoiding the man-in-the-middle attack. Because the private key is not shared the man-in-the-middle does not have the ability to decrypt the cipher key and therefor are unable to decrypt the remaining traffic sent over the connection.
If you want to be as secure as possible you should generate sufficiently large public/private keys, update the keys regularly, and disallow the negotiation of insecure cipher suites. You cannot prevent a man-in-the-middle attack, you can only make it more difficult for them.
In theory, in your case, HTTPS should be enough secure.
If you want to increase security, you can play with RSA, AES to encrypt and decrypt your payload before sending it.
If these are cloud servers, and the communication is directly from server1 to server2, arrange the servers in the same VPN and block access from outside the VPN to the authentication server.
In AWS, you can use API Gateway to target specific routes on the authentication server allowing you to selectively expose routes for public (outside the VPN) consumption if you need that still.
AFAIK, SSL will encrypt the message under secure. But I still have the concern whether or not a man in the middle can catch the packet and duplicate it e.g. 1000 times
Application data is broken into small segments (implementation dependent size, usually <=16kb). Then that segment is
Compressed
Given a sequence number
Added a MAC (sequence number included in MAC calculation)
Encrypted
Given an SSL record header that contains the sequence number
Note the role of sequence number in this process. If the man-in-the-middle duplicates one such segment, the received can detect it using the sequence number. And the attacker cannot forge sequence number since it is included in MAC as well as the record header.
Sequence number gives SSL protection against duplication, deletion, reordering and replay attacks.
SSL is secure from interception, replay, MITM, and truncation attacks. At least.
Sure, a passive man-in-the-middle attacker can catch the encrypted packet - that's why you do encryption. But because each SSL connection uses a unique encryption key the attacker cannot use this sniffed encrypted packet later to inject it into another connection. And as long as the encryption key is not compromised (which means for RSA key exchange that the private key of the certificate is not compromised) the attacker can not decode the sniffed packet.
Apart from that an active man-in-the-middle attacker might put itself in-between the parties, e.g. instead of Alice talking to Bob Alice will talk to Mallory and Mallory to Bob. To make this impossible you need the identification part of SSL, e.g. certificate checking and verification of the host name (one alone is not enough). Only this makes true end-to-end encryption possible.
I am no expert in network security, so pardon if this question is not very smart :).
I am automating logins to some machines using ssh. I am currently avoiding host-key warnings using StrictHostKeyChecking no.
I naively understand that someone can impersonate as the server and I risk losing my password to him if that were the case. However, if I am using only public/private Key based authentication ( using PasswordAuthentication no ), can the intruder still cause harm?
So basically, with ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" :
1) Can the intruder decipher my private key?
2) Are there any other security threats?
regards,
JP
Actually, public-key authentication method prevents MITM attack. As far as I can tell, it is a coincidence, not by design. While full-blown MITM attack is not possible, the attacker still can impersonate the server: receive commands and data sent by the client and return arbitrary responses to the client. So it might be not a good idea to disable server host key checking after all.
Below is the explanation why full-blown MITM attack cannot be executed when public-key authentication is used. My blog post http://www.gremwell.com/ssh-mitm-public-key-authentication contains some more details.
During MITM attack, the attacker inserts themselves in between the client and the server and establishes two separate SSH connections. Each connection will have its own set of encryption keys and session id.
To authenticate using public-key method, the client uses the private key to sign a bunch of data (including the session id) and sends the signature to the server. The server is expected to validate the signature and to reject the authentication attempt if the signature is invalid. As explained above, the server and the client will have completely different idea about what session id is supposed to be. It means there is no way for the server to accept the signature generated by the client under MITM attack.
As mentioned above, the session ids are guaranteed to be different for client-MITM and MITM-server connections. They are calculated from on the shared secret negotiated with Diffie-Hellman, separately or each connection. It means the attacker cannot arrange two sessions to have the same session ids.
No. Or atleast... not directly. Since you never send your private key, the key will be safe. That doesn't mean that the person that is executing the MITM attack can't execute commands and/or read the output you're getting.
Yes, there are other risks. If the person executing the MITM attack forwards the data to the correct server than it might be possible to use your private key to execute commands on the machine you were trying to access.
I have a couple questions about SSL certificates.
I never used them before but my current project requires me to do so.
Question 1.
Where should you use SSL? Like I know places like logging in, resetting passwords are definite places to put it. How about once they are logged in? Should all requests go through SSL even if the data in there account is not considered sensitive data? Would that slow down SSL for the important parts? Or does it make no difference?(sort of well you got SSL might as well make everything go through it no matter what).
Question 2.
I know in smtp you can enable SSL as well. I am guessing this would be pretty good to use if your sending say a rest password to them.
If I enable this setting how can I tell if SSL if it is working? Like how do I know if it really enabled it? What happens if the mail server does not have SSL enabled and your have that boolean value enabled. Will it just send it as non SSL then?
With an SSL connection, one of the most expensive portions (relatively speaking) is the establishment of the connection. Depending on how it is set up, for example, it might create an ephemeral (created on the fly) RSA key for establishing a session key. That can be somewhat expensive if many of them have to be created constantly. If, though, the creation of new connections is less common (and they are used for longer periods of time), then the cost may not be relevant.
Once the connection has been established, the added cost of SSL is not that great although it does depend on the encryption type. For example, using 256-bit AES for encryption will take more time than using 128-bit RC4 for the encryption. I recently did some testing with communications all on the same PC where both client and server were echoing data back and forth. In other words, the communications made up almost the entire cost of the test. Using 128-bit RC4 added about 30% to the cost (measured in time), and using 256-bit AES added nearly 50% to the cost. But remember, this was on one single PC on the loopback adapter. If the data were transmitted across a LAN or WAN, then the relative costs is significantly less. So if you already have an SSL connection established, I would continue to use it.
As far as verifying that SSL is actually being used? There are probably "official" ways of verifying it, using a network sniffer is a poor man's version. I ran Wireshark and sniffed network traffic and compared a non-SSL connection and an SSL connection and looked at the raw data. I could easily see raw text data in the non-SSL version while the SSL "looked" encrypted. That, of course, means absolutely nothing. But it does show that "something" is happening to the data. In other words, if you think you are using SSL but can recognize the raw text in a network sniff, then something is not working as you expected. The converse is not true, though. Just because you can't read it, it does not mean it is encrypted.
Use SSL for any sensitive data, not just passwords, but credit card numbers, financial info, etc. There's no reason to use it for other pages.
Some environments, such as ASP.NET, allow SSL to be used for encryption of cookies. It's good to do this for any authentication or session-ID related cookies, as these can be used to spoof logins or replay sessions. You can turn these on in web.config; they're off by default.
ASP.NET also has an option that will require all authenticated pages to use SSL. Non-SSL requests get tossed. Be careful with this one, as it can cause sessions to appear hung. I'd recommend not turning on options like this, unless you really need them.
Sorry, can't help with the smtp questions.
First off, SSL is used to encrypt communications between client and server. It does this by using a public key that is used for encryption. In my opinion it is a good practice to use it for as anything that has personally identifiable information or sensitive information.
Also, it is worth pointing out that there are two types of SSL authentication:
One Way - in which there is a single, server certificate - this is the most common
Two Way - in which there is a server certificate and a client certificate - the client first verifies the server's identity and then the server ids the client's id - example is DOD CAC
With both, it is important to have up to date, signed, certificates by a reputable CA. This verifies your site's identity.
As for question 2, yes, you should use SSL over SMTP if you can. If your emails are routed through an untrusted router, they can be eavesdropped if sent without encryption. I am not sure about the 'boolean value enabled' question. I don't believe setting up SSL is simply as easy as checking a box though.
A couple people have already answered your Question 1.
For question 2 though, I wouldn't characterize SMTP over SSL as protecting the message. There could be plenty of points at which the message is exposed. If you want to protect the message itself, you need S/MIME, or something similar. I'd say SMTP over SSL is more useful for protecting your SMTP credentials, so that someone cannot grab your password.
We have a (multi-os) application which communicates with a https server using libcurl and uses SSL client certification. When the client certification is password protected, the application must ask the user to input password. The application sends hundreds of different https request to the server, so we can not ask the user to input password each time a new connection is going to be created. Now we simply prompt the user to input password once when the application starts then set the password to curllib through "CURLOPT_KEYPASSWD" option. But I'm worrying about malicious user could easily hack into the running process and read the client certification password. Is there anyway I can cache the client certification password and also prevent it from being easily read from memory?
You should not worry that much about it, in real life. If you worry about such attacks, maybe look into hardware based keys and certificates in smart cards.
Some suggestions to fight swap and coldboot attacks:
Lock the memory that holds the password, don't allow it to be swapped out (mlock+mprotect and on posix, Windows also has similar functions)
possibly encrypt the memory that holds the password and only decrypt it while using the password.
In real life, if your machine is owned so that somebody can intrude into processes he/she should not have access to - you're already compromised, no idea trying to make it obscure.
If you think that you control the cache - think again - you can never know if curl for example copies and leaks the memory with the password, under some circumstances.
If you're serious about SSL and security, use hardware tokens or smart cards. Otherwise expect that once the host is compromised, your software and any access codes running through that host have been compromised.