Security via probability

[Paul Carey <pa...@gmail.com>]

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

Re: Security via probability

[Ed Finkler <fu...@gmail.com>]

It really depends on the nature of the data and such, but in general
I'd be pretty wary of doing such a thing for a write action. Might be
okay for a read if the data isn't terribly sensitive.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Tue, Oct 7, 2008 at 7:35 PM, Paul Carey <pa...@gmail.com> 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
>

Re: Security via probability

[Paul Carey <pa...@gmail.com>]

> Block requests to the all docs query, and you have the beginnings of a
> capability system.

Yes, preventing users from retrieving all docs ids would be critical.

Re: Security via probability

[Sho Fukamachi <sh...@gmail.com>]

On 08/10/2008, at 11:16 AM, Ayende Rahien 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.

All security is via some sort of obscurity, be it obfuscated URLs,  
passwords, a challenge response or the location of bumps on a key. The  
only thing that differs is how hard it is to get that information.  
Obviously having a properly secure session provide authentication is  
the ideal, but I can think of many cases where a nearly unguessable  
URL is plenty.

Funny this came up, I've had an email in my drafts folder for a couple  
of weeks asking for some basic "security via obscurity" features for  
similar purposes. I thought I'd wait until I'd decided exactly what I  
wanted, but since it's come up ...

[from another reply]

On 08/10/2008, at 10:54 AM, Matthew King wrote:

> Block requests to the all docs query, and you have the beginnings of a
> capability system.


Not just that. You'll need a few more as well:

- ability to turn off all "write" access for a non-local IP  
(especially post new views!)
- block meta functionality like all_docs, all_dbs,  _utils, and  
replication for non-local IPs
- set a limit on how many 404s could be served to a specific IP before  
a timeout period began

and I'm sure there are more.

I'm aware that by proxying through another server like Apache or  
Nginx, applying various rules or what not to stop those adminstrative  
views being accessed. But the thing is, CouchDB already has a very  
capable web server built in. All other things being equal, I'd like to  
just have it serve the documents (well, attachments, I'm mainly  
talking about) natively....

Sho

Re: Security via probability

[Paul Carey <pa...@gmail.com>]

> 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.

If you're already listening to the network you could simply extract a
users password and log in as that user. I'm not writing a banking
application, or an app with rigorous security requirements. I don't
expect to serve anything over https.

Re: Security via probability

[Nuno Job <nu...@gmail.com>]

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 <ay...@ayende.com> 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 <au...@gmail.com>
> 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 <jw...@google.com> 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 <pa...@gmail.com> 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
> > >
> >
>

Re: Security via probability

[Ayende Rahien <ay...@ayende.com>]

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 <au...@gmail.com> 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 <jw...@google.com> 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 <pa...@gmail.com> 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
> >
>

Re: Security via probability

[Matthew King <au...@gmail.com>]

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 <jw...@google.com> 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 <pa...@gmail.com> 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
>

Re: Security via probability

[Jeremy Wall <jw...@google.com>]

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 <pa...@gmail.com> 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