Topic: Inputs.io Security - page 2. (Read 2638 times)
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
TradeFortress, you seem very very calm about losing a significant amount of the people's Bitcoins. Acting as if nothing has happened.
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.
No, no, it's not a scam! It is a SOCIAL EXPERIMENT!
https://bitcointalksearch.org/topic/m.2166173
Well, he can now rewrite the inputs.io site to read:
https://bitcointalksearch.org/topic/m.2166173
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!
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:
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":Quote
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.
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
http://bitcoin.stackexchange.com/questions/3629/what-is-the-story-behind-the-linode-problem
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?
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
Quote
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
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.
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 :-)
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.
Quote
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!
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!
our web facing server
You mean the one at the end of the SSL tunnel seeing passwords go through it in cleartextWell, 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!
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
Jump to: