> 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.
> 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?
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.
Because it has the amazing feature of storing all your passwords in a file. It's nothing like the features offered by lastpass with respect to serving you your passwords from a remote host and if you can't trust your password manager to KDF & encrypt then you really shouldn't be using it as it's doubtful it's properly generating secure passwords.
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
You probably already know this, but you can set up unique emails through gmail using the "+" character. name+servicename@gmail.com. This will let you keep track of who is using what email address. Although, as this becomes more common knowledge, people could just strip off the anything after the "+" when saving email addresses.
Sad part is that, even with all of this, you're only as secure as each service not being otherwise breached, and that scenario is probably more likely in aggregate than your credentials being compromised. We are all as vulnerable as the engineering practices of each service with which we engage.
We (especially in the tech community) tend to focus strictly on tech solutions. But, one of things that isn't discussed nearly enough is the legal aspect of all of this. That is, penalties for hacking, international cooperation, etc. As it is, the scammers have an unlimited free pass to just keep coming at us/services. The worst that can happen to them in most cases is that they simply don't get what they are after. It's all upside and little risk. With that motivation, they will simply persist until they find the weak links.
I've come to the conclusion that the most important thing by far is a different password for every site. If you do nothing else, figure out a way to do that. It's probably also a good idea to make sure that your security question answers are anything but the actual answers to those questions. I prefer looking up random words for each one, and storing them in the Lastpass entry for the site.
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?
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.
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.
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?
This threw me off as well, I think you are suppose to use the first chart if your password was generated randomly and the second chart if you used words. I am not 100 percent sure though.
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.
The way password crackers work now, it is quite easy to crack passwords that are combinations of words, even with alphanumeric substitution. The best passwords are completely random, and 24+ characters.
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.
I wouldn't say all - but many. However, there is always more than one way to skin a cat.
Gandi states that they won't reset it - but offers instructions on how to do it [1]. Which, presumably if you are spinning up VMs the owner of the account should get an email notification.
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".
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.)?
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).
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?
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.
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.
Dice map trivially to alphabet+numbers, and you know there are no flaws in the generation.
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.
That quote is not saying computer generated random numbers are bad. It is saying computer generated random numbers are good. (And human generated random numbers are bad.)
If you simply use the C rand function that is bad. But he's assuming you're using something with real randomness, like urandom.
56 comments
[ 4.5 ms ] story [ 112 ms ] threadUgh. 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://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?
I'm currently using Password Hasher (https://chrome.google.com/webstore/detail/password-hasher-pl...), but that only works well because I mostly use just one machine.
LastPass and 1Password are good choices if you don't care about letting others host your (supposedly encrypted) passwords.
Also, there's Mitro, encrypted password manager living inside a Chrome extension: https://www.mitro.co/
That statement doesn't apply to 1Password; AgileBits does not host your data.
Because it has the amazing feature of storing all your passwords in a file. It's nothing like the features offered by lastpass with respect to serving you your passwords from a remote host and if you can't trust your password manager to KDF & encrypt then you really shouldn't be using it as it's doubtful it's properly generating secure 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
We (especially in the tech community) tend to focus strictly on tech solutions. But, one of things that isn't discussed nearly enough is the legal aspect of all of this. That is, penalties for hacking, international cooperation, etc. As it is, the scammers have an unlimited free pass to just keep coming at us/services. The worst that can happen to them in most cases is that they simply don't get what they are after. It's all upside and little risk. With that motivation, they will simply persist until they find the weak links.
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?
Somewhat interesting that the bounty is not priced in terms of Bitcoin.
15 XAU is by the way currently around USD 18000.
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.
Is https://xkcd.com/936/ bad advice?
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.
* http://www.merriam-webster.com/help/faq/total_words.htm
It's (generally) easier to just use a longer passphrase and a shorter wordlist of only relatively common words.
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.
While it was helpful on that occasion, it should probably go completely against policy to do stuff like this.
Gandi states that they won't reset it - but offers instructions on how to do it [1]. Which, presumably if you are spinning up VMs the owner of the account should get an email notification.
[1] - https://wiki.gandi.net/en/hosting/gandi-expert/change-root-p...
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.)?
[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).
Is it more likely that the RNG is compromised than the bitcoin software?
> 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#...
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?
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.