
Bitcointalk Server Compromised - psykovsky
http://webcache.googleusercontent.com/search?q=cache:Y4vlAkSdJFsJ:https://bitcointalk.org/index.php%3Ftopic%3D1067942.0&hl=en&gl=fr&strip=1
======
CyberShadow
> Somehow, the attacker got KVM access credentials for the server. [...] After
> he got KVM access, the attacker convinced NFOrce that he was me (using his
> KVM access as part of his evidence) and said that he had locked himself out
> of the server. So NFOrce reset the server's root password for him, giving
> him complete access to the server and bypassing most of our carefully-
> designed security measures...

Ugh. We need to remember that social engineering your ISP, hosting provider,
etc. is a very real attack vector. Do not trust them.

Reminds me of the "N" twitter username story: [https://medium.com/@N/how-i-
lost-my-50-000-twitter-username-...](https://medium.com/@N/how-i-lost-
my-50-000-twitter-username-24eb09e026dd)

~~~
nadams
> convinced NFOrce that he was me

> 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?

~~~
sytse
GitLab CEO here, I don't understand the hint, when you set up 2FA on GitLab we
give you backup codes to recover, but that might not be what you mean.

------
hobarrera
I've had Digital Ocean reset a VM on a different account (a client's) just by
asking politely from my own account (not impersonation or anything alike on my
part).

While it was helpful on that occasion, it should probably go completely
against policy to do stuff like this.

~~~
grubles
You literally only asked politely? I feel like there was at least /some/ sort
of info you had to provide.

~~~
nadams
When he submitted the ticket or whatever he was probably logged into his
account and to DO that is probably a "the user is logged in so we don't have
to verify his identity".

------
tedunangst
> The forum will pay up to 15 XAU

Somewhat interesting that the bounty is not priced in terms of Bitcoin.

~~~
weinzierl
If it would be priced in terms of Bitcoin it would make the bounty less
attractive for a lot of people. Bitcoin is highly volatile and not everyone
believes it will rise.

15 XAU is by the way currently around USD 18000.

~~~
firethief
The bounty is to be paid in Bitcoin anyway; I don't see how your
attractiveness explanation is applicable.

The problem with setting the price in Bitcoin _is_ the volatility: someone
with information could attempt to time their contact with Theymos to maximize
their bounty. This could significantly delay revealing the information, if the
bounty claimant felt the price were temporarily in a slump, and could cost
Theymos a lot more than expected if they got lucky.

~~~
kbenson
Although, over a two week period in late February and early March, gold
appears to have dropped from 75.94 to 63.78. That's less volatile than BTC,
but if that's the metric that we are measuring, why not use USD?

~~~
psykovsky
Bitcoiners don't use the devils money.

------
ah-
What's the best way nowadays to protect yourself as a user against this? You
certainly can't trust anyone to store your password securely, so you're forced
to have a strong password per site, and it's impossible to memorize that many
passwords.

I'm currently using Password Hasher
([https://chrome.google.com/webstore/detail/password-hasher-
pl...](https://chrome.google.com/webstore/detail/password-hasher-plus-
pass/glopbmohkffbnplcjbbbfmmimfhfnhgd)), but that only works well because I
mostly use just one machine.

~~~
jiayo
I am using KeePass Password Safe v2 (while on Windows), and KeePassX on linux
and OS X.

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

~~~
ams6110
Nitpick, "mydomain.com" is a real domain (registrar). Use "example.com" for
example domains.

~~~
jiayo
Fixed, thanks!

------
scanr
Anyone know what this table means:

    
    
            1 word   0
            2 words  0
            3 words  0
            4 words  3m
            5 words  19d
            6 words  405y
            7 words  3My
    

Does it mean that if your password contains only 4 words, it 3 minutes to
crack regardless of the words?

Is [https://xkcd.com/936/](https://xkcd.com/936/) bad advice?

~~~
TheLoneWolfling
That XKCD comic is good advice. But use a long enough passphrase.

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.

~~~
DanBlake
Doesnt the english language consist of 500,000-1,000,000 words?

* [http://www.merriam-webster.com/help/faq/total_words.htm](http://www.merriam-webster.com/help/faq/total_words.htm)

~~~
TheLoneWolfling
Yes. But most of them are far too close to each other to remember easily. Or
relatively not used words.

It's (generally) easier to just use a longer passphrase and a shorter wordlist
of only relatively common words.

------
crobertsbmw
Interesting that he says, "If your password is not completely random (ie.
generated with the help of dice or a computer random number generator), then
you should assume that your password is already broken."

1) When he says "dice" is he talking about physical dice or something, or is
there some protocol called dice that I am not aware of?

2) I feel like even though a computer generated random string isn't completely
random, that it could still be effective. Could someone elaborate on this a
little bit more? What if you do tricky things like concatenate multiple random
strings together? What about functions like urandom (I'm pretty sure that is
truly random.)?

~~~
imaginenore
Yes, he is talking about real dice. He comes from Bitcoin security point of
view: don't trust anything.

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).

~~~
Dylan16807
I don't quite follow your logic. You still need an airgapped computer to turn
those random bits into a working address, don't you? Is there a way to do that
by hand?

Is it more likely that the RNG is compromised than the bitcoin software?

~~~
imaginenore
Yes, but you have eliminated one vector of attack - a faulty or compromised
RNG.

> _Is it more likely that the RNG is compromised than the bitcoin software?_

1) That's a weird question. It's not like they are mutually exclusive. Both
are possible. Dice allows you to eliminate the RNG problems.

2)
[http://en.wikipedia.org/wiki/Random_number_generator_attack#...](http://en.wikipedia.org/wiki/Random_number_generator_attack#Prominent_examples)

~~~
Dylan16807
If I think the risk is high enough to worry about, I'm going to use a method
that gets close to eliminating it. I'm not going to settle for only removing
one vector.

~~~
imaginenore
So don't. Using an airgapped computer will not save you against against a
compromised RNG (e.g. reduced entropy). Your computer-generated numbers might
look random to you, but you can't really be sure.

~~~
Dylan16807
>So don't.

Isn't that my argument? Maybe I should try again to clarify my position.

'Just' an airgapped computer solves neither backdoored RNG nor backdoored
bitcoin software.

A trusted airgapped computer comes close to solving both.

Using dice only gives me half a solution; why bother?

~~~
imaginenore
Airgapped computer definitely solves the compromised software/firmware
problem, because it can't send your private keys to the attacker.

~~~
Dylan16807
Compromised software can do anything a compromised RNG can do and more.
Especially with something finicky like asymmetric crypto.

