On Fri, Oct 10, 2014 at 7:00 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Thom Brown (thom@linux.com) wrote:
>> To be honest, this all sounds rather flaky. Even if you do rate-limit
>> their queries, they can use methods that avoid rate-limiting, such as
>> recursive queries. And if you're only after one credit card number
>> (to use the original example), you'd get it in a relatively short
>> amount of time, despite some rate-limiting system.
>
> The discussion about looking up specific card numbers in the original
> email from Simon was actually an allowed use-case, as I understood it,
> not a risk concern. Indeed, if you know a valid credit card number
> already, as in this example, then why are you bothering with the search?
> Perhaps it would provide confirmation, but it's not the database's
> responsibility to make you forget the number you already have. Doing a
> random walk through a keyspace of 10^16 and extracting a significant
> enough number of results to be useful should be difficult. I agree that
> if we're completely unable to make it difficult then this is less
> useful, but I feel it's a bit early to jump to that conclusion.
You are obviously wearing your rose-colored glasses this morning. I
predict a competent SQL programmer could write an SQL function, or
client-side code, to pump the data out of the database using binary
search in milliseconds per row. And I think it's more likely than not
that there are other techniques that are much faster. The idea that
you're going to be able to let people query the data but not actually
retrieve it should be viewed with great skepticism. This is the
equivalent of telling a child that she can't open her Christmas
presents until Christmas, but she can shake them, hold them up to a
bright light, and/or X-ray the packages. If she doesn't know what's
in there by the time she opens it, it's just for lack of effort.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company