For example, what if someone created malware to get in between the two programs (wallet and daemon), pretending to be the daemon and logging all the info before sending it along to the real daemon?
I recently downloaded Bitcoin QT and it didn't have a separate daemon. I just double clicked the program and it synced the blockchain and allowed me to send and receive funds via a GUI. I assume this is much more secure since the two functions are within the same program.
The disconnected architecture that Monero employs allows you to host the daemon and wallet separately. My own opinion is that this is an improvement over the bundled design of Bitcoin-QT.
If you run the daemon locally, there's a chance that a local process is intercepting the packets. However, if you have that level of malware on your machine, you're probably no better off with the unified architecture since your transaction will be picked up and logged when you send it out to the network anyway.
As others have stated, having a separate blockchain daemon and wallet application is a strategic design decision. Here's a comment from Wladimir J. van der Laan, Bitcoin Core Maintainer:
To name an example of it done right, IMO: Monero's 'simplewallet'. It is a command-line utility wallet that communicates with the node software, and remembers where it was in the chain, and processes changes to the chain state since its last invocation when it 'refreshes'.
What is nice is that one can run an arbitary number of simplewallets against one node daemon, and unlike bitcoind's wallet it doesn't need to run as always-on daemon itself. It can be invoked when the user wants to do something with the wallet, or see if there are new transactions.
http://bitcoin-development.narkive.com/mH0GrHuE/libconsensus-and-bitcoin-development-process#post7
If your system is compromised and you have malware on it, your funds can always be stolen. No matter if you have one application or several, your private keys are always stored on your hard drive and a malware can have access to it and all your keyboard inputs.
So if you want to hold significant amounts of Monero, move them to a cold wallet and hold only that many coins on hot wallets, that you need to have available "on demand", since every system has some remaining risk of being compromised.
Having a node/wallet system adds some small measure of risk, while removing a high measure of risk. On balance, the separated system is more secure than a monolithic system.
If you consider the separated approach, there are three points that can be attacked: the node, the wallet, and the link between the two.
If the node is compromised, then it doesn't have access to the keys, since those are in the wallet. Any malware must still compromise the wallet first before getting access to the keys. Access to the node allows you to degrade the wallet's privacy to some extent, though most of that venue was removed with Monero 0.10. See What privacy or security trade offs are associated with not running your own full node? for details. If you had a monolithic architecture, your keys would be compromised already.
If the wallet is compromised, then both architectures have your keys. There is still a chance with Monero though, though a slight one. If the VM running the wallet only connects to the daemon VM using a very strict firewall (obviously not one running on the wallet VM, but something enforced like Qubes OS firewallVM), then the wallet might have to break out of this jail in order to exfiltrate the keys. However, the wallet can probably send normal transactions anyway, so it's a 90% break instead of a 100% break. Close enough. Note that I don't consider the case where the wallet is air gapped. In both monolithic and separate cases, you're still good.
The last case, which is the one you're refering to, is when the link is MITM'd, which can be broken down into passive MITM and active MITM.
Passive MITM can't do anything else that a daemon compromise can't do, since the daemon can trivially MITM itself. You can gather information, which is not much since Monero 0.10. Active MITM can additionally DoS you, and feed you wrong blocks, so you think you're up to date, but aren't. This still can't get to your keys or coins, though it can make you think someone sent you money. Depending on the nature of that active MITM malware, this can probably be done to the monolithic appproach as well: if the malware can intercept and rewrite/withhold/add packets on the network, the monolithic node will also get fooled. The only way I see where risk could be added is if only the node/wallet link can be compromised, without the rest of networking being compromised, but that sounds pretty unlikely.
So, in short: Crypotonote/Monero's node/wallet architecture increases security, rather than the opposite, for all the reasons stated above.
Disclaimer: I am not a security or coding expert.
Basically, you're asking whether a client-server application is intrinsically less secure than a monolithic application? If that were the case, I guess the client-server paradigm would be as widespread (with 3-tier applications being a variant of that). I think it is even so that, a clear separation between client and server logic actually enforces a good design, and avoids spaghetti code, where ugly hacks jump from daemon code to client code an so forth. In short, my opinion: no.
