Ayende has a point. The guys from RSA also gone for the it's safe approach and then they were reverse engineered and cracked. And DSA was born. :P I don't think couch hashes where created with security in sight. I never saw the code but they might as well be a simple fingerprint of the document.
Why don't you simply restrict access to couch to the local network? On Tue, Oct 7, 2008 at 8:16 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > Really bad idea.Security through obscurity is no security. I can listen on > the network and see what kind of requests are made, for example. > > On Wed, Oct 8, 2008 at 1:54 AM, Matthew King <[EMAIL PROTECTED]> > wrote: > > > Block requests to the all docs query, and you have the beginnings of a > > capability system. > > > > On Tue, Oct 7, 2008 at 6:42 PM, Jeremy Wall <[EMAIL PROTECTED]> wrote: > > > This assumes that the user has to guess. If the user gets the docif > > > via some other means, say by the all docs query built in to couchdb > > > then h doesn't have to guess. > > > > > > > > > > > > On 10/7/08, Paul Carey <[EMAIL PROTECTED]> wrote: > > >> My webapp PUTs data to a url like /controller/couchdb_db_doc_id. The > > >> associated action currently performs no security checks. Specifically, > > >> it doesn't ensure that the user making the PUT request and modifying > > >> the data actually owns the associated document. > > >> > > >> Given a uuid as a doc id, the chances of guessing a doc id are very > > >> low indeed; successfully guessing a typical user's password would be > > >> much easier. In order for an attack to be successful the attacker > > >> would have to first guess a document id - extremely unlikely. This > > >> leads me to believe that I don't *need* to perform any security checks > > >> when modifying a document as described above. Any thoughts to the > > >> contrary? > > >> > > >> Cheers > > >> > > >> Paul > > >> > > > > > > -- > > > Sent from my mobile device > > > > > >
