search

Tallefer / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
0 stars 0 forks source link

Add Nonce parameter to the authentication mechanism for content distribution requests #61

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
SUMMARY:

When signing the request a Nonce should be included to prevent replay attacks. 

RELEVANT SECTION:  7.4. Authenticated Content Distribution

COMMENT/REQUEST:

It is now possible to sign POST requests to subscribers, guarantee a level
of authenticity and message integrity (non-tempering). However there is
still a vulnerability when POST requests are replayed by an unauthorized
party (e.g. man-in-the-middle). 
The hub will be perceived as a spammer and blame will likely be put on the
publisher as well. Subscribers are not expected to filter out entries that
were already POSTed.
To guard against this scenario the signing mechanism should include a Nonce.
The spec must specify, how the payload to be signed/verified is normalized.

The downside is that the implementation of the subscriber gets a little
more complex. However, using signatures is entirely optional.

Original issue reported on code.google.com by jbeck...@gmail.com on 3 Sep 2009 at 7:21

GoogleCodeExporter commented 9 years ago 
Nonce isn't needed. The update time on the feed always rolls forward in time. 
All
Atom entry and RSS item elements have both an ID and update time for de-duping
purposes. Replay attacks can't happen because the protocols are inherently
idempotent. Does that make sense?

Original comment by bslatkin on 4 Sep 2009 at 5:20

GoogleCodeExporter commented 9 years ago 
yes, that makes sense if we say that the subscriber also has a responsibility 
to keep
track of the last update times for all the feeds they receive POSTs for. They
basically would do de-duping as well; something I had hoped is confined to the 
Hub.
I agree, that this would make the replay attack ineffective.

Original comment by jbeck...@gmail.com on 4 Sep 2009 at 6:54

GoogleCodeExporter commented 9 years ago 
The subscriber needs to dedupe no matter what because their ACK response of a 
200
code on notification delivery could be lost by the Hub, causing the hub to 
retry.

I'll mark this as not an issue. Thanks for reporting it and the feedback!

Original comment by bslatkin on 4 Sep 2009 at 8:52