The site currently runs on 4 dedicated servers, hosted in a locked cabinet. All servers run behind a dedicated cisco security appliance with intrusion detection. On the servers themselves various “booby traps” are set to alert the webmaster if an intrusion is detected.
The java code deployed to the Site is deployed in a single war (zip) file. Each server monitors the checksum of this file to detect any unauthorised changes to the code. In order to make reverse engineering our encryption schemes more difficult the the java class files are obfuscated using proguard.
A copy of every wallet is stored all our servers. Additionally the latest 50 versions of a wallet are stored on Amazon S3 and can be restored from the [Import / Export] section.
The server side code that handles wallets is open source.
The site is not vulnerable to CSRF requests as no login details or sensitive data is ever saved in session cookies.
In the time the Site has been running there has been handful of XSS vulnerabilities reported. None of these were on a wallet page and could not have resulted in any direct loss of funds.
Wallets are simply json files containing private keys. The entire json file is encrypted by the users browser before being uploaded to us. So when a wallet reaches our server is appears as random Base64 string. This means we cannot view your balance, see your transactions or addresses and cannot make transactions on your behalf.
The encryption is only as strong as the users password. The minimum password length is 10 characters however if the a weak password is chosen e.g. “1234567890” using a dictionary attack the wallet would likely be broken quickly. Rainbow tables will not work as each wallet is prepended with a unique salt combined with the users password using PBKDF2 to derive the actual encryption key.
The private keys in a wallet can be “double encrypted” using a second password. One password is then required to login and another password is required to send funds. This makes wallets significantly harder to brute force and also makes key logging more difficult.
You can backup a wallet via Email, Dropbox, Google Drive and Download. With a backup funds can be accessed without blockchain.info using themultibit desktop client.
The Site supports a variety oftwo factor authenticationmethods and the ability to lock down a wallet to a specific ip address. We will not give out your wallet to anyone who cannot authenticate themselves fully, however we cannot prevent someone from using your wallet if they gain access to it another way. For example if you keep a wallet backup in your email account and that is compromised.
This has got a little technical but it isn’t an easy answer. There are many factors involved including the security of your own computer. The site has been running for over a year and currently hosts nearly 40,000 wallets. There have been reports of some individual wallets being compromised (reusing passwords) but no major security incidents.
Finally a couple of recommendations for using our service:
Upon sign up print a “Paper Wallet”, store it somewhere safe and hidden.
Never reuse the same password on another site. Or if using double encryption it is acceptable to use a slightly weaker main password but ensure the second password is unique.
If storing large amounts generate a private key offline (bitaddress.org is great for this). Print it on a paper wallet, then import the address as “Watch Only” address. When you attempt to spend the funds you can scan the private key off the paper wallet using a webcam.
In future multisig will be available for even greater security but this isn’t quite ready yet.