Re: Column Redaction
От | Stephen Frost |
---|---|
Тема | Re: Column Redaction |
Дата | |
Msg-id | 20141010204930.GO28859@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Column Redaction (Rod Taylor <rod.taylor@gmail.com>) |
Список | pgsql-hackers |
Rod, * Rod Taylor (rod.taylor@gmail.com) wrote: > For fun I gave the search a try. Neat! > On my laptop I can pull all 10,000 card numbers in less than 1 second. For > a text based item I don't imagine it would be much different. Numbers are > pretty easy to work with though. I had been planning to give something like this a shot once I got back from various meetings today- so thanks! Being able to use the CC # *as* the target for the binary search is definitely an issue, though looking back on the overall problem space, CC's are less than 54 bits, and it's actually a smaller space than than that if you know how they're put together. My thought on an attack was more along these lines: select * from cards join (SELECT CAST(random() * 9999999999999999 AS bigint) a from generate_series(1,1000000)) as foo on (cards.cc = foo.a); Which could pretty quickly find ~500 CC #s in a second or so (with a 'cards' table of about 1M entries) based on my testing. That's clearly sufficient enough to make it a viable attack also. The next question I have is- do(es) the other vendor(s) provide a way to address this or is it simply known that this doesn't offer any protection at all from adhoc queries and it's strictly for formatting? I can certainly imagine it actually being a way to simply avoid *inadvertant* exposure rather than providing any security from the individual running the commands. I'm not sure that would make it genuinely different enough from simply maintaining a view which does that filtering to make it useful on its own as a feature though, but I'm not particularly strongly against it either. Thanks! Stephen
В списке pgsql-hackers по дате отправления: