A lot has been written about how Wikileaks is staying online and I don't propose to add to it - this piece on CNET and this one from Renesys should tell you all you need. If you're looking for mirrors the list is currently here and there's a mirror of the mirror list here.
However, there are a couple of good technical points to be made here that I've not seen elsewhere.
First of all, Wikileaks is a website designed to be easily cloned. If you look at it, each page is a self-contained file with a flat URI - there are no signs of a query string, and each cable released has a unique ID within the same directory. This is important because it means that the process of creating a mirror is just to copy all the files into the /public_html/ directory of another web server. On a Unix-like system, it could be a one-liner command (the site doesn't actually let you do this the quickest way) - the utility wget is capable not only of traversing the directory and downloading all files, but also of changing links within them to point to the same filename in the target directory. The -m or --mirror option activates the options -N -r -l inf --no-remove-listing, which will in order ensure you only download material you haven't already loaded, that wget will get everything in the target directory or directories, and that any directory listings will be preserved. -p requires that everything needed to make up a page, such as a photo of Julian Assange, will be retrieved. -k turns on link conversion.
It might be enough to do:
wget -N -p -k wikileaks.wherever /home/you/public_html/
So it's easy to create a mirror, and it's trivial to keep it up to date - you could just run your script as a cron job to grab whatever gets released every day. Anyone thinking of a really controversial Internet project should, IMHO, consider design-for-cloning to be a useful pattern. The clone count is now in the thousands.
Second technical point: what a horrible idea Mastercard SecureCode (and its pal Verified by Visa) is. I already hated it before this - it's a password, that should be a strong password because it's financial, but that I don't use that often and therefore can't remember, and it trains you to accept the idea of typing confidential information into a random web site you didn't ask for. Essentially all phishing requires you to type your bank details into something that you didn't ask for. Forcing the public to type their bank details into some random website they didn't ask for is howling insane. Right?
Also, the failure case is horrible - you get to reset the password by disclosing a whole lot of confidential information into the same random website you didn't ask for, so an attacker who managed to inject a frame into the original merchant's website could fake a failed payment and harvest all the information they would need to empty your bank account. And the service support when they imposed it on me was dire, especially as the SecureCode web site went down part way through the process.
But it's worse than that. An important part of the way card payments are accepted on the Web is that, as is also true in shops, you interact with the merchant, whose bank interacts with the wider infrastructure. So you should know who you're dealing with. Further, the bank should at least have some idea who its merchants are - they are customers after all - and restrict access to the system to them. And there's more than one bank that provides merchant service, so there are no single points of failure.
The SecureCode (and its Visa twin) websites, though, are customer-facing, so they have to accept traffic from the whole of the Internet. And all the Mastercard payments from the Web have to go via the SecureCode website. So you have a critical operational function, that is a single point of failure, and that is exposed to every last dog on the Internet. It's only surprising that somebody didn't bring it down earlier, especially when things like Bees with machine guns! are available.