Those answers apply only to protocol based Ripple implementations.
The main security feature is that you're dealing with friends and not institutions reliant on adversarial processes. However, an unauthorized payment made to a stranger still has to be resolved somehow. Neighbouring nodes can verify that all transactions originating at a given node have been personally (digitally) signed by the owner of that node. This breaks down if some neighbours are on the same server, and that server gets compromised.
Ideally nodes would be run on a secure OS with execution privileges that prevent code modifications, and with separate web and database servers. A good Ripple host would offer to take the hit for customer losses due to a hacked server, just as a bank would. Despite the great potential rewards for hacking into a bank server, it doesn't seem to happen very often. And hacking Ripple requires gaining access to at least two neighbouring nodes, not just a single bank account. The truly paranoid could run their own single-node server to make this more difficult.
Sellers who are worried about becoming a victim of cascading debt repudiation along the payment chain resulting from claims of a compromised server could use parallel techniques for authenticating buyers and require the same key to be used for signing Ripple messages. See the next question.
Each node stores a digital certificate that uniquely identifies it during automated interactions with other nodes (accepting payments, processing through payments). Furthermore, each participant is assigned their own personal certificate that must sign any transactions originating at their node. This signature can be verified by any neighbours. The Ripple specification allows for these certificates to be stored on separate machines.
You have to trust that whoever is running your server is keeping good backups and has good security practices. If you're truly paranoid and know what you're doing, run your own server.
First of all, participation in Ripple does not require you to enter your name, address, or give out any personal details at all. When you sign up at a Ripple server it assigns you an address for your "node" on the network. Then you can give out your address only to those who need to have it: the people you will have accounts with, and those make payments to you. Ripple allows node addresses to remain anonymous to all but neighbouring nodes during transactions that involve chains of intermediary nodes.
For greater security, and to enable certain types of transactions, some servers may require identification before allowing you to sign up. Since anyone can operate a Ripple server, you should, as usual, know and trust the people operating the server before you divulge any information.
By using a new unique alias for each transaction whenever they need to make their presence known outside their circle of trusted neighbours. All communication is routed through their neighbours, who are the only ones who know to which node the alias actually refers.
It is possible to insert false extra nodes inside the payment-chain messages so no one can really be sure how long the chain is.
Ripple allows each node to identify itself with keywords, preferably those shared by many of the node's neighbours, such as city/province/country, but also possibly with unique keywords, such as the node's URI. Ideally, each node would store the shortest distance in every direction to a node with any given keyword, but that would involve developing an potentially complicated protocol for keeping such tables up-to-date. And since ever-shifting account balances mean that payment paths cannot be counted on long-term, it might not be worth the effort.
Instead, as search messages are sent out with source and destination keywords appended, each node that sees the message keeps track of where those keywords came from, and whether their guess where to route the search message was successful. This information can be used to help route future queries on those same keywords. More about searching....(link to be inserted)
XML for messages between servers, passed over HTTP secured by TLS/SSL. XML digital signatures for authenticating human-initiated messages between nodes. UUID for message IDs, etc. SHA-1 for various things. Tried REST as an architectural philosophy, now leaning more towards straight messaging and maybe even SOAP (yech!).