Post
Topic
Board Service Discussion
Re: Instawallet/Bitcoin-Central Security Breach
by
Nicolai
on 04/04/2013, 11:41:58 UTC
Quote from: Vladimir link=topic=164143.msg1736247#msg1736247
Having password in URL is a security flaw. It opens obvious attack vectors with very high probability of being exploited sooner or later. Information Security is all about risks and probabilities. Everything that increases risk is a "security flaw" to some degree.
No it is not. What you don't get, is that there is a huge difference between "not following best practice" and "having a security flaw in your website". The reason why the "password in url" was described as a "security flaw", was because 'the founder' (a user) wanted it to look worse than it was (so Instawallet would look more bad for not paying him, even trough it was public knowledge that this was possible loooong before 'the founder' even "found" this).

Instawallet had a security flaw that got them hacked (this incident, we don't know how, but we do know that it had NOTHING to do with "password in url"), however the "password in url" was just a case of "not following best practice" (NOT a security flaw). It is just like when a websites uses a simple username+password combination to authenticate users, instead of a "zero-knowledge password proof"-protocol. Most websites use the lesser-secure username+password, but this doesn't mean you should create a forum post for each website, whining that you told all the websites on the internet that ZKPP is better and now you want a cookie + pay check ( <-- this was what 'the founder' did).

So to sum up, it is not a security flaw/exploit, if you can't exploit/get access to *anything*, without requiring the users to tell you their passwords (<-- this is ofc just very simplified, but the point is that if your exploit is "give me your shared secret, and I can authenticate as you" then it isn't a exploit, it is a intend behaviour. You could argue "why use a shared secret, why not something else and more secure?" but it still wouldn't be a security flaw. Not now, not ever).

[...]

3. The hacker has some info

This is as far as i could go with this. I am not technically minded and can only guess from reading this thread the kind of data he could have. I have listed the possibilites from worst cast scenario to best.

  • 1) All 3.5 million URLS and public addresses in a list with balance attached to them in the list. - this would mean they have probably emptied all the big ones straight away
  • 2) All 3.5 million URLS and public addresses in a list with no balance attached. - this would mean having to search each address on the blockchain to find out what is on each one. Quite time consuming. 2 people doing that for 90 days, 14 hours a day, looking up 1 every ten seconds would be 907,200
  • 3) A portion of the URLS and public addresses, maybe gained from Google or Chrome as mentioned earlier in the thread - same as above but obviously some of us will not be affected
  • 4) All 3.5 million URLS but not the public address - this would mean that as soon as the website was closed they no longer had access to the site to search for bitcoins in the URLS they were holding
  • 5) A portion of the URLS but no public address - the same as above but again doesn't affect everyone

There may be more but that's all i could think of for now.

[...]

What do you guys think?

I agree on most parts, but:

2) Actually "2" would be almost like "1". It wouldn't be time consuming at all, because you can just write a parser to parse the blockchain and sort by amount (change a bit here and there, and this source code + the blockchain, is all you need).

3) As I wrote earlier, then this is 100% without any doubt NOT the case.