Inputs.io Security

[🏰 TradeFortress 🏰]

Why's that funny?

For one : what's special about it ?

For two :

Code:

$ dig NS inputs.io | grep linode

Congratulations, you have figured out our web facing server runs on Linode. While it runs bitcoind (for blockchain access, verifying signed messages and pushtx), it contains zero coins and communicates securely to the hot pocket / "main" server, which also does it's own database integrity checks  

[davout]

our web facing server

You mean the one at the end of the SSL tunnel seeing passwords go through it in cleartext
Well, at least you're not using cloudflare :-)

Anyway, I got a little concerned about the whole "let's integrate inputs.io" thing, thinking about JD leaving some of the user funds there.
Got reassured about it knowing dooglus had that insured with some sort of bond.

Ended up removing my coins anyway because I wanted to take some time to calmly review the whole thing and decide how much I'd be able to deposit and feel comfortable losing should anything go wrong.

To go back to this Linode thing, if your server gets compromised without you getting knowledge of it you can have your user passwords progressively harvested and bogus transactions authorized. When BC comes back online we'll demonstrate a setup that gracefully handles a fully compromised frontend AND (N-out-of-M) compromised backend nodes. It relies on the crypto we all know and love and mechanisms for decentralized transaction clearance and audit.

Cheers!

[🏰 TradeFortress 🏰]

You mean the one at the end of the SSL tunnel seeing passwords go through it in cleartext
Well, at least you're not using cloudflare :-)

Passwords are never communicated through cleartext in any circumstance. Your browser automatically hashes your password.

You will never see cloudflare or similar services, or 3rd party tracking services like Google analytics on Inputs.

To go back to this Linode thing, if your server gets compromised without you getting knowledge of it you can have your user passwords progressively harvested and bogus transactions authorized. When BC comes back online we'll demonstrate a setup that gracefully handles a fully compromised frontend AND (N-out-of-M) compromised backend nodes. It relies on the crypto we all know and love and mechanisms for decentralized transaction clearance and audit.

Cheers!

We use bcrypt with a user unique salt. The server does not get plaintext passwords, because your browser does not send it.

We have decoy accounts which are populated by "real" user data from our other databases. The hot pocket server automatically dumps all coins to cold storage if it sees a payment request from a decoy account. We have methods that makes it very hard for an attacker to determine if an account is decoy or not, even with root access to the linode machine and listening to traffic.

Thank you for being concerned about our security!

[davout]

Passwords are never communicated through cleartext in any circumstance. Your browser automatically hashes your password.

So the hash becomes the password, right?
If the hash is intercepted can it not be used to authorize bogus requests?
I mean if the server never sees the password in clear it can't check it in any way, if it checks the hash, and the hash is intercepted it can be used to forge requests.

We use bcrypt with a user unique salt.

Thumbs up. Isn't the salting already built right into bcrypt though?

We have decoy accounts which are populated by "real" user data from our other databases. The hot pocket server automatically dumps all coins to cold storage if it sees a payment request from a decoy account. We have methods that makes it very hard for an attacker to determine if an account is decoy or not, even with root access to the linode machine and listening to traffic.

If I was you I wouldn't underestimate the ability for an attacker to tell a decoy apart from a legitimate account given enough time, access to your traffic, access to blockchain data and access to basic taint-analysis tools of wallet fundings. But since I don't really know anything about your specifics I won't comment further.

The approach we'll outline is more systematic and doesn't use tricks such as decoys, honeypots and other traps, I think you'll like it when you read about it.

Feel free to answer in another thread and point me to it so we stop diverting dooglus' thread.

[🏰 TradeFortress 🏰]

The approach we'll outline is more systematic and doesn't use tricks such as decoys, honeypots and other traps, I think you'll like it when you read about it.

Count me interested

I mean if the server never sees the password in clear it can't check it in any way, if it checks the hash, and the hash is intercepted it can be used to forge requests.

Great point. We'll roll out something soon which'll work as long as you were not compromised when first registering (which is when we store your password) or when you upgrade your account.

Thanks for your comments, I really appreciate it. I'm interested in knowing your approach.

OK, will stop derailing the thread for now

[dree12]

Why's that funny?

For one : what's special about it ?

For two :

Code:

$ dig NS inputs.io | grep linode

Congratulations, you have figured out our web facing server runs on Linode. While it runs bitcoind (for blockchain access, verifying signed messages and pushtx), it contains zero coins and communicates securely to the hot pocket / "main" server, which also does it's own database integrity checks  

Something's not right about this statement. How can 4000 BTC be "stolen" if no coins are on Linode?

[killerstorm]

It was planned all along. Bitcoinica was also hosted on Linode, and was hacked in the same way. Now he can just point at Linode and claim he isn't guilty.

http://bitcoin.stackexchange.com/questions/3629/what-is-the-story-behind-the-linode-problem

[Sukrim]

No, no, it's not a scam! It is a SOCIAL EXPERIMENT!

https://bitcointalk.org/index.php?topic=206948.msg2166173#msg2166173

This social experiment has ended - here was the goals:

1) teach people that Ripple BTCs are not real BTCs
2) teach people that your BTC.* can be substituted for anything you trust, automatically

There was also mass invasion of ripple.com/forum posters. It's not too hard to figure out who they are. Keep this in mind:

1) I have not profited at all from this.
2) Anyone who lost BTC.* had their BTCs exchanged by other people.
3) Anyone who I sent a BTC to could have redeemed someone else's Bitstamp or whatever IOU.

Please read http://ripplescam.org/ to learn more!

Well, he can now rewrite the inputs.io site to read:

This social experiment has ended - here was the goals:

1) teach people that input.io BTCs are not real BTCs
2) teach people that your BTC.inputsio can be substituted for anything you trust, automatically

There was also mass invasion of bitcointalk.org posters. It's not too hard to figure out who they are. Keep this in mind:

1) I have not profited at all from this.
2) Anyone who lost BTC.inputsio had their BTCs stolen by other people.
3) Anyone who I credited a BTC on inputs.io could have redeemed them before the "hack".

Please read [is there a webwalletsarescams.org?] to learn more!

Don't worry, Theymos won't think he is a scammer:

For a scammer tag, the accused person needs to have promised to do something and then failed to deliver on the promise. TradeFortress never promised to pay anyone any bitcoins here. If you trust him to do something that he didn't promise, that's your problem.

As per the "legal disclaimer":

Bitcoin is not legal tender. As with any Bitcoin service, any storage on inputs.io is at the users own risk. Exchange rates are estimates only.

[nimda]

Why's that funny?

For one : what's special about it ?

For two :

Code:

$ dig NS inputs.io | grep linode

Congratulations, you have figured out our web facing server runs on Linode. While it runs bitcoind (for blockchain access, verifying signed messages and pushtx), it contains zero coins and communicates securely to the hot pocket / "main" server, which also does it's own database integrity checks  

Riight.

[Remember remember the 5th of November]

TradeFortress, you seem very very calm about losing a significant amount of the people's Bitcoins. Acting as if nothing has happened.

[BIGMERVE]

TradeFortress, you seem very very calm about losing a significant amount of the people's Bitcoins. Acting as if nothing has happened.

Because he just became BTC4100 richer.

[killerstorm]

While we are here, a claim that it's OK to have a web-facing server on a VPS because it has no wallet on it is outrageous.

A compromised web-facing server can be used for a MitM attack no matter what other tricks you use.

MitM attack can be used to steal funds of users who are currently use the site.

So if person tells you that VPS is OK because it doesn't have a wallet in it, we can decipher it as this:

"Well, we know that attacker will be able to steal coins from our users via MitM attack, but we don't give a fuck; after all, without VPS we'd have to pay whopping $70/month for a real physical server, and it takes a whole hour to set it up. No fucking way we'll go through this just to prevent a pesky MitM attack."

This is outrageous... If somebody claims that, he is either a complete moron or scammer.

Of course, inputs.io is already dead... But if somebody else will try using VPS to handle non-negligible amount of bitcoins, he should get scammer-tag right away, before the thing gets compromised. There is simply no excuse for this stupidity.

Physical dedicated servers are cheap. It isn't hard to set them up.

[davout]

While we are here, a claim that it's OK to have a web-facing server on a VPS because it has no wallet on it is outrageous.

[...]

Physical dedicated servers are cheap. It isn't hard to set them up.

I failed to locate the slightest clue in your message.

[killerstorm]

While we are here, a claim that it's OK to have a web-facing server on a VPS because it has no wallet on it is outrageous.

[...]

Physical dedicated servers are cheap. It isn't hard to set them up.

I failed to locate the slightest clue in your message.

It's your own fucking problem.

Do you represent geniuses who were running Instawallet?

If so, you have already proven that you have no effing clue. No surprise here.

[davout]

It's your own fucking problem.

Do you represent geniuses who were running Instawallet?

If so, you have already proven that you have no effing clue. No surprise here.

Drop the butthurt, start the thinking.

[Damnsammit]

TradeFortress, you seem very very calm about losing a significant amount of the people's Bitcoins. Acting as if nothing has happened.

Because he just became BTC4100 richer.

No kidding!

Still not sure what the appeal of that website was anyways.  I'd never want to keep my bitcoins on the internet.

[killerstorm]

It's your own fucking problem.

Do you represent geniuses who were running Instawallet?

If so, you have already proven that you have no effing clue. No surprise here.

Drop the butthurt, start the thinking.

What are you talking about?

My point is that VPS should never be used to host projects which need to handle non-negligible amounts of users' bitcoins as virtual private servers have extra attack surface as compared to dedicated servers.

Which part of this you disagree with?

It's worth noting that I do not care about inputs.io or any crap like this, I'm just trying to warn people so that they'll have a chance to avoid obvious traps in future.

[davout]

My point is that VPS should never be used to host projects which need to handle non-negligible amounts of users' bitcoins as virtual private servers have extra attack surface as compared to dedicated servers.

If your security model depends on not having one or more servers compromised it's probably flawed anyway.
A correct security model depends much more on thorough continuous auditing and business operations procedures than it does on technical considerations.

Designing your system to fail gracefully without financial consequences is far more important than designing it not to fail or get compromised.

[tvbcof]

My point is that VPS should never be used to host projects which need to handle non-negligible amounts of users' bitcoins as virtual private servers have extra attack surface as compared to dedicated servers.

If your security model depends on not having one or more servers compromised it's probably flawed anyway.
A correct security model depends much more on thorough continuous auditing and business operations procedures than it does on technical considerations.

Designing your system to fail gracefully without financial consequences is far more important than designing it not to fail or get compromised.

This reminds me, have you published a debriefing about the technical details of your problems davout?  If so, can you point to it?

If not, do you have a plan to?  I would think that by now

 - enough time has passed to have re-constructed your procedures

 - any defects which made the attacks possible would be resolved and those mistakes would not be made again.

For my part, I just have curiosity about things.  Believe it or not I actually want the Instawallet hassles to be an understandable failure against a significant attack (vs. a bogus story invented to mop up unclaimed Instalwallet funds or some such.)  Also, I think it would help other system designers to understand the nature and capabilities of attackers.  If it helps others, great.  It is in no ones interest when hacks occur (except criminals, bankers, politicians, etc.)

[davout]

This reminds me, have you published a debriefing about the technical details of your problems davout?  If so, can you point to it?

I have a comprehensive forensic audit report sitting in one of my drawers, made by a decent IT security firm.
There's no perceived interest on my side to share it with bitcointalk though.

For my part, I just have curiosity about things.

Well then, lurk some more I'd say, and comment if you have something interesting to add, instead of rehashing the same stuff over and over.

Believe it or not I actually want the Instawallet hassles to be an understandable failure against a significant attack

Nobody cares about what you want.
It is however in our plans to publish some procedures at some point, maybe some security-related code too.