|
You should disable SWAP space. This will make it unable to hibernate, but that's worth the security benefit!
It could be even better to use a smaller distribution, but I think Ubuntu is a good start. They have pretty good security policies (for example all kind of buffer and stack overflow protections, and special treatment for potentially dangerous stuff like PDF and printing servers).
|
|
|
|
The OP can prove that he has the private keys to the account the money was stolen from.
That means that we have two people claiming property, which is way better than nothing.
The issue is not proving he owns the addresses the bitcoins came from, the problem is he has no way of proving that he does not own the addresses the bitcoin went to. That could be a problem, but it isn't when it is directly associated with an MtGox account. This seems to be the case here. |
|
|
|
Whats to stop a scammer from lying and claiming they were ripped off then ?
Whats the evidentiary criteria ?
Sure the transactions exist, but what does that prove in and of itself ?
that the transactions exist ?
Anyone can log into a website through tor or another proxy and change those details. Even the real account holder in an effort to solidify the claim.
How do we know they were not legitimate, other than taking someones word on it, who might have ulterior motives ?
There is a reason BitCoin is designed the way it is with reversible anonymous transactions.
The OP can prove that he has the private keys to the account the money was stolen from. That means that we have two people claiming property, which is way better than nothing. |
|
|
|
|
I think you should definitely have a machine that has Linux on it. Not because it is more secure, it isn't. But you get a pretty secure system with a lot useful built-in tools to achieve security. You could also have that with some fancy enterprise version of Windows, but with the Windows versions most people have you have to deal with a lot of external tools and take care about security yourself.
For example you should always prefer your system's built-in disk encryption, because this is meant to protect your data. You can do a similar setup with TrueCrypt, but then you have to know exactly how you avoid each of the many mistakes. That's pretty hard. Just installing TrueCrypt doesn't do the job.
Another advantage of Linux is that you are not dependend on running software from the web. You find most thing in the distribution's repository, and over this way it is secured via cryptography that you don't get manipulated program versions.
|
|
|
|
|
There is nothing you can do but total reinstall. And you really have to let stuff go to be sure that you don't carry the infection to the new system. That's a sacrifice - but it should never happen anyway.
|
|
|
|
1. Software Keylogger? Hardware keylogger?
2. Vulnerability in the Ubuntu encryption algorithm? From what I read, Truecrypt is supposedly the gold-standard. Can you configure Ubuntu to use it for the home dir?
3. Vulnerability in Ubuntu? If you update your OS, can your download be redirected to another location with a compromised OS patch?
4. For those who use an "air gapped" machine, how do you spend the coins? Is it possible to manually enter a Bitcoin transaction by paper, pen & a networked PC?
1. Hardware Keylogger would be a problem. Software Keylogger would require the System to be fully comprimised, which I already mentioned. 2. No, it is not. TrueCrypt has a lot of fanct featues, most of them very useful. That is why it is hyped a lot by people who don't understand it. Even the TrueCrypt manual says almost literally that it is not true that you can easily be secure with TrueCrypt. (I already opened a thread about it: http://forum.bitcoin.org/index.php?topic=16246.0) Ubuntu home folder encryption is based on ecryptfs, which is a part of the Linux kernel itself. It is based on the very crypto implementations of the kernel - like a lot of other disk crypto solutions (luks/dm-crypt). I would not use TrueCrypt for this because it is bloated with a lot of features that are not needed here. For a security concept you should always prefer the simpler solution. A more complicated solution just opens the danger of making mistakes. 3. Yes, a vulnerability that allows root access would be a problem, I mentioned that. |
|
|
|
What do I get if I get your money back?
Is there hope after all? 1. mtgox has the money 2. our victim can at least prove that he also has the private key of the account where the money got stolen from. |
|
|
|
|
What do I get if I get your money back?
|
|
|
|
|
I added a list of possible attacks, does anybody see an attack I haven't thought of?
|
|
|
|
I'm far more paranoid - I used a dedicated machine for BTC and only connected it to the network to do transactions. Also sent most of my coins to an offline wallet all the way in the beginning - generated on a computer with no network connection, hand keying the address off the screen. The only way Bitcoin or any other cryptocurrency will succeed in the future IMO is a hardware-based wallet (which is essentially what I have been using, it just happened to be in the shape of an old laptop).
Yeah, that's what I would do if I had thousands of coins. |
|
|
|
Once again: Encryption would not have protected anything. Encryption can protect stored data. It does not protect a wallet file that is in use, because it is accessed by the client and stored unencrypted in main memory.
In theory yes. Of course it would protect against stealing the wallet file. Normally you only need the data encrypted for doing transactions which is a very short time window. Especially with savings wallets which get accessed not very often. An encrypted wallet that stays encrypted even while the client is running would do tons in favor of security. There is a big difference between getting one time access to a machine and having a program running to wait for the wallet to be decrypted in memory for 100ms. Encrypt wallet, decrypt only when the user wants to send coins - interesting idea. That's how I do it. I described it in a thread: http://forum.bitcoin.org/index.php?topic=15068.0 |
|
|
|
Once again: Encryption would not have protected anything. Encryption can protect stored data. It does not protect a wallet file that is in use, because it is accessed by the client and stored unencrypted in main memory.
In theory yes. Of course it would protect against stealing the wallet file. Normally you only need the data encrypted for doing transactions which is a very short time window. Especially with savings wallets which get accessed not very often. An encrypted wallet that stays encrypted even while the client is running would do tons in favor of security. There is a big difference between getting one time access to a machine and having a program running to wait for the wallet to be decrypted in memory for 100ms. You always have to assume that the attacker knows how the client works. Anything else isn't security. |
|
|
|
taken that mining leaves you with an already quite serious amount of bitcoins once you get just one block, air gapping serious amounts of btc will not work  The miner has to be online, but the address receiving the mined coins doesn't. |
|
|
|
|
You really should try to track the thief. That's your only chance! And the chance isn't that small, bitcoin is not exactly anonymous.
|
|
|
|
|
Once again: Encryption would not have protected anything. Encryption can protect stored data. It does not protect a wallet file that is in use, because it is accessed by the client and stored unencrypted in main memory.
|
|
|
|
What would be the best solution for the lack of encryption problem? The only thing I can think of would be to created an encrypted volume (via truecrypt) and drop the wallet file in there. But then it'd have to be replaced any time you were mining. I'm not talking about a back up here, I mean the original obviously.
Dropping a wallet into an encrypted disk does not protect at all. The wallet must be created in there and never be stored outside. I thought so, just wondering if there was some solution I hadn't thought of. It is not a solution to the OP's problem at all. Encryption only protects data while you are not using it. |
|
|
|
What would be the best solution for the lack of encryption problem? The only thing I can think of would be to created an encrypted volume (via truecrypt) and drop the wallet file in there. But then it'd have to be replaced any time you were mining. I'm not talking about a back up here, I mean the original obviously.
Dropping a wallet into an encrypted disk does not protect at all. The wallet must be created in there and never be stored outside. |
|
|
|
I am an excellent speaker and I do a Bitcoin podcast every now and then. I am pretty well-versed in the general workings of Bitcoin and I believe I can sufficiently explain it to the average layman.
Hit me up on how to proceed.
What's your podcast? |
|
|
|
Maybe one should state a new rule:
Don't hang around on IRC with a machine storing a lot of BTC.
I never did. I did backup my wallet.dat file to dropbox, wuala, and spideroak. Once I read an article about employees of dropbox having access to users's files I deleted the wallet.dat file from there. I dunno, I doubt it was caused becaused someone had access to where i backed it up. It most likely means he/she (hacker) had access to my windows box and the UNENCRYPTED wallet.dat file. The first thing I did when I saw this was restore the backup from these online storage sites, but still the transaction was still there so I could not invalidate one damn thing. Are you serious? I can't imagine a dropbox employee not searching the servers for wallets. |
|
|
|
I am really interested in what your strategy was. Because I really did not put much effort in it. I just took the first tool Google gave me.
Maybe the high performance has something to do with the fact that I have a SSD? I tried to run the tool on a university machine with 32 CPUs and it was way slower there.
Then I just created a 10 MB tmpfs (a folder that is stored in RAM instead of disk), and it went even faster (2400+ tests per second).
I am at "d3x2x" now, but still not lucky. But be patient, I want to crack it!
I don't understand why filesystem performance should affect such a small file, it should only depend on the processing power. My strategy was to make the password be found by brute-force attacks a bit after 35^5/2 tries. I see it does take a bit of time for a 5 characters password, I usually go with passwords with more than 8 characters these days for accessibility reasons, looking forward to increase that to over 90 bits of entropy per password by using 14 or more characters. To get the equivalent of a 256-bit unique key, you would need to use the whole alphabet twice, numbers and punctuation in a password of no less than 40 characters. Enjoy typing your 40 character password or accept lower security  It should not depend - but it does. One explanation may be that 7zip is a crappy piece of software. |
|
|
|
|
Show Posts
