Bitcointalk Server Compromised

https://twitter.com/n

> So NFOrce reset the server's root password for him

So a couple of things:

I do my hosting with gandi (moving away from self hosting as Comcast business is...well anyways...). I had setup TOTP with their service and my phone died and I lost my OTP key (lesson learned - always backup OTP keys - hint gitlab developers...). I had submitted a ticket and they called the number that was on the account and had me answer a few questions. I don't remember what the questions were - but they weren't certainly "can you reboot this server?".

The simple fact that the company used that as verification should be a red flag.

Here is another red flag - why does the hosting provider have the ability to reset a VM's root password? Gandi states that in their FAQ that they won't reset the root password - though they give you instructions on how to do that.

Though if he had access to KVM (through virtsh or virt-manager ?) he could have easily reset it himself (which would require a reboot). Perhaps he wanted to be discrete as possible?

15 XAU is by the way currently around USD 18000.

LastPass and 1Password are good choices if you don't care about letting others host your (supposedly encrypted) passwords.

I use a strong password, and a key file, which is just a blob of random bytes. The encrypted password database (.kdbx) is published to Dropbox, which handles sync across devices. The key file (.key) stays on an encrypted USB stick on my physical keychain, and is physically backed up in a few safe places. It is never published online. This makes it effectively a second factor.

I have a domain, example.com, which is set up for wildcard email forwarding. When I sign up for a service, I use servicename@example.com (recently I have started obscuring this a bit more, e.g. srvcnm.49jg49kf34@example.com). This limits password reset exposure, and also the ability for other services that are in cahoots with each other to link my accounts together by email address.

Everything connected to this domain (registrar, DNS provider, email provider) is protected by separate TOTP 2FA tokens.

I simply do not access any authenticated services if I don't have access to KeePass and my password vault.

I have over 250 entries in my vault. At this point, it's less about remembering and generating passwords than it is about keeping track of what I've signed up for and when. Some things, you only look at once every few years, and my S.O.P. before KeePass was usually password resets.

For extremely high value accounts, I have memorized a "prefix" which I prepend to generated passwords. This limits exposure in the case my entire password database leaks, to just things like hackernews, reddit and other low value services.

I do not use KeePass for my dropbox password, because I could end up locked out entirely.

So this is really 3 things to remember: Password vault password, Dropbox password, and high security prefix.

There are some weaknesses in this scheme. As another user mentioned below, I am not invulnerable to an @N style hijacking. Someone could socially engineer my registrar, DNS provider or email provider, hijack my email and then initiate a password reset. I'm not sure how to defend against this. Common knowledge is to not use custom domains, since it's easier to hijack example.com than gmail.com, but for me the value of having unique email accounts per service is too high to give up.

The other obvious point of vulnerability is keyloggers and trojans that attack the KeePass processes directly. This is not something I've spent a lot of time thinking about. It is a scorched earth scenario, and in that case I won't be the only one in trouble.

This method has served me well for over 5 years. I've acknowledged there's some flaws here, but I fundamentally do not trust any of the online password management services (LastPass, 1Password, etc.) and I find the idea of paying to store/access them distasteful at best and extortionate at worst.

edit: I also use KeePass to generate my security questions. Very few online services are savvy enough to use a one-way hash on these questions, that are the keys to the castle. I've had to recite these to support reps over the phone, who can see them in clear text.

e.g.,

What was the name of the street you grew up on? => xcmqbbpgpuuxyrdw

What was your first pet's name? => owuynnfhwscgigciq

gandi.net is a pretty decent provider not full of BS (as their slogan states).

[1]: http://zx2c4.com/projects/password-store/

I view password complexity and obsessing over how hard it would be to crack your password hash with various setups to be of little value. If they're far enough in to get your password hash, it's better to assume they can see and do anything and everything on the site even if they can't crack your password. If you've actually used a different password on every site, there isn't much left to worry about. Still, if you're using a password manager, it's cheap to make all of your passwords long, random strings with upper, lower, numbers, and specials, so why not do it?

Also, he's being (very) conservative. In other words, he's assuming a very fast password cracker. Roughly speaking, he has a wordlist of ~8070 words, which works out to ~13 bits of entropy / word. Which implies at 3My to crack 7 words he's assuming ~26 trillion (!) password hashes per second.

That's potentially realistic if you're using a fast hash - but you should be using something that's slow (and memory-constrained) for a password hash.

In reality GPU crackers can do 100,000,000,000 guesses per second. https://hashcat.net/oclhashcat/

You need to add another 2-3 words.

[1] http://world.std.com/~reinhold/diceware.html

Dice, being physical objects outside of computer networks can be trusted to a pretty good degree.

When it comes to creating something random on a computer, it's actually incredibly hard to guarantee randomness. Most RNGs are black boxes or are so non-transparent that they might as well be black boxes.

You might have an idea how your *nix /dev/random works, but can you actually guarantee your OS is not compromised? Can your guarantee your BIOS is not compromised? Can you guarantee that your hardware is not compromised?

That's why if you want a truly secure Bitcoin cold storage, you generate a wallet offline using something like dice or coinflips (dice are quicker).

It doesn't have to be competely random, but when humans make up passwords they grossly overestimate the entropy levels; it's easier to say not to do it at all. Especially since the longer a password a human makes, the more likely they are to use shortcuts to gut the entropy, such as involving not only words but actual sentences.

Biased random number sources are okay, but you have to understand the bias, and it's easier to use an unbiased source. urandom is nearly perfect (post-boot) so use that.

If you simply use the C rand function that is bad. But he's assuming you're using something with real randomness, like urandom.