Bitcoin Armory not as secure as promised?

Sun Aug 10 09:44:22 PDT 2014

So, the response was this:

> Guys, calm down.
> The code you posted doesn't send your username to bitcoinarmory.com, it
> sends the *truncated hash* of your user home directory path.  This does
> not give us any information about you except that it will be the same when
> your system makes multiple requests for version/announcement information.
> We*intentionally* chose this *instead* of tracking by IP because we knew
> that IP logging was "not cool".  And in the end, we don't care about your
> IP, we only use it the ID for collecting statistics about what operatings
> systems are being use to run Armory and what versions people are using,
> especially after announcing new versions.  This helps us remove duplicates.
> Armory (the company) only tracks unique IDs long enough to collect daily
> statistics of our user base, like how many people have upgraded.  If a
> announce-request is made and comes from an ID we have never seen, we add
> the OS and Armory version to the statistics.  Otherwise we ignore it.
> That's it.  We added the unique ID so that we have a way to count unique
> users *without* logging IP addresses.    We also add the ability for you
> disable this by running with "--skip-annuonce-check".
> As a company, we have to have *some* way to measure our userbase, and we
> felt this was the least intrusive way possible.  And you can opt-out.

But without salting the hash it's more reversible than it has to be.
Another issue is the ignoring of proxy settings and therefore collection of
IP addresses either by Armory or by other actors.

Sorry guys, I've been out all day, but I've been thinking about this.  You
> all are absolutely right.  We made two mistakes:
>
> (1) We assumed that because we choose not to store/process the IP data,
> that users would believe us that we don't
> (2) We incorrectly assumed the that space of user home paths on your
> desktop was big enough that the 4 byte identifier would not have adverse
> privacy implications. I did not consider that people's home usernames might
> be, say, their username on bitcointalk.org
>
> It's quite clear that those two pieces of data do have pretty serious
> privacy implications.  I want to fix this ASAP.
>
> To be clear, the reason we made the unique identifiers is *because* we
> don't want to store any IP data for the reasons described: if there was a
> subpoena of some sort, we'd prefer to not have anything to reveal.  And we
> don't store it.  But, we incorrectly assumed that the unique identifiers
> would be sufficiently non-privacy-leaking while still allowing us to remove
> duplicates (in response to justus: we want an identifier that will be
> persistent between loads so that users that start the program over and over
> are not counted for each start--as we all know, a lot of users have
> difficulty with Armory and will start it 300 times to try to get it to
> work).  It is clear these were bad assumptions since we technically
> *could* be storing both which *would be* quite bad.
>
> I hope we've generated enough good faith with the community that we get a
> little slack that this was not our intention.  I take the blame for not
> realizing that, and I want to make sure that it is fixed.  ASAP.  I will
> happily take feedback on how this should be adjusted so that we can meet
> our goals without compromising the privacy of the users.
>
> I agree we should decouple the option from the announcement fetching.  We
> consider announcements to be extremely important, and why we made that
> difficult to disable:  if there's a critical security (or privacy!)
> vulnerability in Armory, there is a very short window where someone might
> try to exploit it to steal peoples' coins, and there's no better way to
> help users than to make sure a big scary warning pops up the next time they
> start Armory.  The fact that we coupled the OS/version reporting with meant
> that it was as hard to disable that as it is the announcement fetching.  We
> can easily separate them and will happily make it easy to disable the
> OS/version reporting.
>
>
> Re privacy policy:  On the advice of our lawyer, we included the "may
> collect IP addresses" because we have no way to prove that we don't.  And
> since our website uses google-analytics, we don't have control over what
> google does with the access patterns of users to our website.  It was a bit
> of CYA that companies have to abide by, especially in the US.  Note we
> describe at the bottom of that page we describe how to disable it
> <https://bitcoinarmory.com/download/privacy-policy/> with a link to our
> troubleshooting page.
>
> On the upside: another positive example of the power of open-source
> software.  We have casually encouraged users to go through the code base,
> and we even contacted the Open Crypto Audit Project to try to get a code
> review (and never heard back from them).  We are obviously believers in
> open-source, and here's the first solid example of Armory getting better
> because of it.  We will get this fixed.

Of course people are still hating. I think it's possible that the
overcollection was accidental. It is somewhat odd that the reason for the
accident was commercialism.

2014-08-10 11:25 GMT+02:00 Crypto <crypto at jpunix.net>:

> Hello Everyone!
>
> It appears that Bitcoin Armory, supposedly one of the most secure Bitcoin
> wallets isn't so secure after all. Check out this forum post for more
> details.
>
> https://bitcointalk.org/index.php?topic=731315.0
>
> --
> Crypto
> https://www.digitalocean.com/?refcode=b90b690ca5bb
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 14060 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140810/9791e854/attachment-0001.txt>