It's certainly possible. You've probably seen the chips on credit cards? They have a very similar problem. The bank must be able to ensure that the chip in the reader has not been copied or tampered with.
They start with physical security. You notice that it's difficult to insert the card into the reader? That is intentional. By making the reader a tight fit, you can't slip some kind of intercept device between the card and the reader.
But it's not too difficult to make a fake card with wires coming out of it which go to a real card and intercept the communication to the card. But this security is not for the bank: it's for you. If a merchant asks you to insert your card into a funky-looking card reader with wires coming out of it, you would probably say "no."
So if you make your dongle "tight" then it would be obvious when you visit your client's site for a meeting if they've got odd wires coming out of their dongles.
I would suggest you use any of the Arduinos that have a native USB port. A Micro or Teensy, for example. Then there's no Serial lines to be sniffed with a simple Serial logger. Yes, USB loggers do exist but they generate a whole lot more data that must be sifted to find the secret password. Just that simple step will slow down the pirates by a measurable amount.
Then there's things you can do to restrict the communication between the dongle and the PC. The dongle should not release the secret password to anyone who asks. The process of asking needs to be complexified. Instead of a simple "send ID" command, the command should be 100 characters long and impossible to memorize. Use ASCII characters that can't be typed on the keyboard or displayed on the screen. Like 0x07 is 'bell' and has no written representation.
Then you can add some challenge-response to the communication. When the PC says "send ID" the dongle can ask "are you sure?" and the PC must reply to that within 10 milliseconds, but not before 5 milliseconds. So if the hacker doesn't get the response just right at the right time, you can ignore that request.
So far, none of this is using encryption. The technical name for the type of attack you are trying to to defeat is called the "man in the middle attack." This is well-known from the days when governments would tap the phone lines of foreign embassies on their soil by simply digging a tunnel under the street to get to the phone line. It is a gigantic business now, with every single website worth more than $5 using SSL encryption.
You probably don't need the full private-key encryption that the SSL key-exchange process uses. Basically there's a matched pair of keys - a public one and a private one. Anything encrypted with your private key can be decrypted by your public key and vice-versa. But having the public key doesn't give you any information about the private one. So we play the "think of a number" game. I think of a number and encrypt it using your public key. I send that to you and you can decrypt it with your private key. Then you think of another number and encrypt it with my public key. I can decrypt that. Now we have a private conversation that nobody can eavesdrop on. SSL is actually more complex because you need signed certificates to verify that the server you are talking to is who it says it is. You don't need that part of it.
But the principles of encrypting secret information can be used to make your dongle more secure. Make the PC request something different every time. The Arduino does some process on that data and returns the result. The PC checks that this matches the expected result. So there's no single 'password' that can be detected on the USB wires. The attacker would have to reverse-engineer the software inside the Arduino to find out what it does to the incoming data. That data could be very simple, like the current time on the PC. So even if somebody records a password exchange, they can't play it back to the PC at a different time.
At that point, the weakest point is inside the PC software. It is relatively easy to edit the binary machine code so that the location it jumps to when the dongle-check fails is the same as the successful location. To guard against that, you need to put some of your critical code into the dongle, so that the software literally can't operate without it.
