Vulnerabilities

From Open Transactions
Revision as of 08:58, 17 June 2013 by FellowTraveler (talk | contribs) (Created page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Since it's important to keep all the potential vulnerabilities in the forefront, this page will help us keep track of those.

Vulnerabilities in C++ code

An attacker could potentially buffer-overflow the C++ code and gain access to execute their own code.

Solutions:

  • Static and dynamic analysis. Some of this has already been done -- more must be done.
  • Security audit of C++ code.
  • Data validation in C++ code.
  • Test scripts for data validation.
  • Penetration testing.

Attacker might intercept a message and send it twice (Re-play attacks)

Solution: Each message contains a "request number" which must increment with each message. This prevents re-play attacks.

Issuer holding gold might lie about the physical gold

Solutions:

  • A physical audit of the issuer's physical gold is the only way to make sure he actually has the gold.
  • A basket currency on OT allows each Nym to distribute the risk of a currency across multiple issuers.

Issuer holding Bitcoins might lie about the actual Bitcoins

Solutions:

  • Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)
  • Store the BTC in a voting pool, so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)

Transaction server might inflate the currency

Solution: An auditing protocol must be utilized, either by the issuer directly, or by the other members of the voting pool.