Re: payswarm vocabs http vs https

For what is worth, here are a few things I've found interesting, or would
like to learn more about:

TCP/IP/HEX

IBM Red Book: http://www.redbooks.ibm.com/abstracts/gg243376.html
Hexadecimal: http://en.wikipedia.org/wiki/Hexadecimal
   - Hex Editor: http://en.wikipedia.org/wiki/Hex_editor
   - Hex Dump: http://en.wikipedia.org/wiki/Hexdump


Patvera Maltego (network visualization used for social engineering)

http://www.paterva.com/web6/products/maltego.php


Social Engineering Risks (the weakest link)

- Social Engineering:
http://en.wikipedia.org/wiki/Social_engineering_%28security%29
- Hacking the Human, Ian Mann


Rainbow Tables, Dictionary Attacks, Brute Force Attacks  (for Cracking)

https://en.wikipedia.org/wiki/Rainbow_table
https://en.wikipedia.org/wiki/Dictionary_attack
https://en.wikipedia.org/wiki/Brute_force_attack


Rainbow Series (Collection of infosec books)

- https://en.wikipedia.org/wiki/Rainbow_Series


BackTrack Linux (penetration testing distribution)

- http://www.backtrack-linux.org/


Wireshark (packet analyzer)

- http://www.wireshark.org/


Network Security Conferences, such as:

- DEFCON: https://www.defcon.org/   (curiously, no mention of the semantic
web)
- Blackhat: http://www.blackhat.com/


Metasploit (platform for exploitation)

- MetaSploit http://www.metasploit.com/
- http://en.wikipedia.org/wiki/Metasploit_Project


SNORT (network intrusion detection and prevention)

- http://en.wikipedia.org/wiki/Snort_%28software%29


netstat (network statistics)

- https://en.wikipedia.org/wiki/Netstat


ISO/IEC 27000-series (standards for information security)

- https://en.wikipedia.org/wiki/ISO/IEC_27000-series


Books:

The Network Security Bible, Eric Cole


Magazines:

Phrack Magazine: http://phrack.org/







On Fri, Jan 25, 2013 at 11:10 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> On 01/25/2013 09:02 PM, Manu Sporny wrote:
> > #4 is dangerous. JSON-LD does have a feature where it allows you to
> > load any other context from the Web. Those contexts can override
> > 'source' and 'destination'.
>
> Dave Longley and I just talked this attack vector through and it doesn't
> seem like it's a valid attack. Here's the attack in a nutshell:
>
> 1. A buyer is attempting to swap the source/destination fields on who
>    gets paid for a particular asset. There are two places that they
>    could corrupt the source/destination: the listing, the contract
>    before payment is made.
> 2. The buyer finds a seller that is overlaying their own JSON-LD
>    context and poisons the DNS that the seller is using to load their
>    own context. The buyer's poisoned context swaps source/destination
>    in the PaySwarm listing.
> 3. The buyer poisons the PA's DNS with their poisoned context that
>    swaps source/destination in the listing and the PaySwarm contract.
>
> #2 fails because swapping source/destination in the listing creates an
> invalid payee for the digital good. The PaySwarm Authority will reject
> the listing because it doesn't contain a destination field.
>
> #3 fails because the PaySwarm Authority (and this part is implementation
> dependent) uses the listing to figure out who should be paid what, and
> the listing is invalid at this point. Even if the listing were valid,
> the poisoned JSON-LD context isn't applied until /after/ payment is
> made, so the money would still go to the right place. The poisoned
> JSON-LD context could still be written to the database with
> source/destination swapped, which would cause a transaction audit to
> fail, at which point the attack would be detected.
>
> So, a successful attack results in no monetary damage, but a corruption
> of the transaction record (that is easily detected and fixed).
>
> However, that this attack didn't work out is just a result of the way
> PaySwarm is designed. There could be other fields that the seller could
> sign in the future that would affect the flow of payment. So, it's
> probably best that we implement some sort of more heavy-weight
> requirement that all JSON-LD Contexts used in PaySwarm transactions MUST
> be loaded over HTTPS. This makes it so that implementers don't have to
> worry about this sort of attack vector at all, which will simplify
> implementations and lead to a tighter security model in general.
>
> I've raised an issue in the JSON-LD group to discuss the issue in more
> depth:
>
> https://github.com/json-ld/json-ld.org/issues/213
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/
>
>