Влагостойкий стол

Question

Я разрабатываю таблицу, которая будет использоваться для хранения информации, с которой клиенты будут платить.
Проблема в том, что база данных может быть на серверах клиентов.
Я думал о добавлении второй таблицы, содержащей хэш первого, чтобы программное обеспечение, использующее базу данных, могло обновить базу данных и хэш, но клиенты не могут редактировать (без нашего ведома) таблицу, содержащую платную информацию (в основание, что они не могут генерировать правильный хэш).

Является ли это хорошим способом предотвращения подделки клиентов за столом, к которому у них есть доступ?
Как бы я создал хеш всех данных в таблице (возможно, более одной таблицы)?

В частности, мне нужно было бы хешировать данные в таблице, а не объект, такой как набор данных (т. Е. Я не хочу, чтобы все хеши менялись, если мы меняем компоненты).

Я рассматривал возможность записи данных в текстовый файл и создания хэша файла, но это было бы мучительно медленно, так как таблица могла содержать до 500 000 записей, и хэш должен создаваться при каждом обновлении!

Реализация этого может быть либо в Delphi, либо в C #.

Answer 1

Хеширование будет работать, но есть еще один элемент, который вам не хватает. Чтобы создать хеш-значение, которое не может быть восстановлено, вам необходимо включить в хеш секретное значение . GUID будет работать, но это может быть любая ценность, которую ваш клиент не знает. Конечно, если у них есть программное обеспечение на их компьютере, то они могли бы обнаружить алгоритм и секретную ценность, таким образом обойдя его. Использование разных секретных значений для каждого клиента было бы хорошим дополнительным уровнем защиты на случай, если один клиент обнаружит его.

Пример:

Hash([Table Data] + [Secret Value]) = [stored hash]

Если вы делаете только хэш данных таблицы, они могут просто перефразировать измененные данные таблицы, и тогда вы не узнаете, что они это сделали.

Что касается хэширования всей таблицы, то вместо каждой строки большинство хэшей поддерживают добавочное хеширование. Причина в том, что если вы хэшируете файл размером 10 ГБ, вам, вероятно, не хватает оперативной памяти, чтобы загрузить все это в память для работы. Вместо этого вы хешируете один блок за раз, а затем, когда вы закончите, вы завершаете хеш. Вы можете использовать этот же метод для ваших данных. Просто добавьте каждую строку в хэш, по одному, и когда вы закончите, завершите хэш. Конечно, не забудьте указать значение вашего секретного ключа.

Некоторые вещи, которые следует иметь в виду:

1. Не включайте процедуру проверки в ваше приложение - другими словами, не предоставьте им способ проверить, что их попытка взлома сработала или не удалась. Это даст им немедленную обратную связь и позволит им разработать окончательное решение.
2. Убедитесь, что вы хорошо протестировали эту систему, особенно если вы планируете наказать клиента в случае сбоя этих хэшей.
3. Убедитесь, что ваш клиент знает, что вмешательство в эти значения запрещено. Возможно, было бы неплохо объединить его с шифрованием на уровне таблицы, чтобы предотвратить случайные изменения.
4. Возможно, лучше зарегистрировать платежи за пределами сайта. Если сервер подключен к Интернету, отправьте информацию в запущенный веб-сервис. Для еще большей безопасности веб-служба проверяет сообщения и отвечает ключом. Затем вы можете проверить этот ключ локально, чтобы убедиться, что он не обошел веб-сервис. Это было бы отличным приложением для подписи открытого ключа.

Также имейте в виду, что большинство людей честны, и многие люди будут прибегать к обходу, если путь честности слишком болезнен (то есть ложные срабатывания на тестах или слишком дорогой ценник). Часто те, украл бы это не заплатит за это так или иначе. Другие, которые могут украсть сегодня, могут заплатить завтра. Вы не хотите сражаться со своими клиентами и относиться к ним как к своему врагу, потому что тогда вы оба проиграете.

Answer 2

Почему бы не просто хэш для каждой записи, а не для таблицы?

Вы можете объединить некоторые поля вместе, добавив 64 символа (используя определенный символ или строку символов), затем ограничить до 64 символов и вычислить хеш - запишите это в другую таблицу:

recordid  tableid  hash

работа сделана - достаточно легко рассчитать на лету и достаточно легко проверить.

Кроме того, было бы трудно найти случайную строку символов, если бы они просто просматривали ваш исполняемый файл (при условии, что здесь есть Delphi)

Answer 3

Ваше хеш-решение звучит так, как будто оно будет работать достаточно хорошо. Если производительность вызывает беспокойство, то проверяйте ваш хэш только со случайными выборками или используйте запланированное задание для обновления проверенной даты хеша (которая может быть зашифрована). Если вы используете триггеры обновления для очистки значений хеш-функции, вы можете легко определить, какие записи были «изменены», и ваша программа может проверить, что триггер все еще находится в рабочем состоянии при каждом запуске.

Answer 4

У нас есть столбец, содержащий строковое значение, представляющее собой очень простой хеш из нескольких системных значений - даты окончания лицензии и других. Это значение пересчитывается на лету программой в ключевые моменты. Если пересчитанное значение не совпадает, мы прекращаем обработку. В столбце также используется ключ для шифрования других фрагментов данных. Процедуры, используемые для пересчета, зашифрованы.

Не надежно, но больше работы, чем кто-либо хотел пройти, чтобы обмануть. Пока.

Answer 5

Я не совсем уверен, решит ли это большую проблему (например, это не поможет, если кто-то восстановит сервер с использованием образа виртуальной машины до более ранней даты, чтобы потерять последние несколько дней расходов)

1. многие алгоритмы хеширования разработаны как дайджесты сообщений так работают постепенно, так что Hash(concat(M,N), seed) == Hash(N,Hash(M,seed))

2. вы можете регистрировать каждое обновление SQL команда отправлена ​​в базу данных

, который должен дать вам более дешевый хеш, независимый от любых компонентов C #.

Answer 6

Я бы, наверное, начал с рассмотрения этого. Как зашифровать столбцы в SQL Server:

http://msdn.microsoft.com/en-us/library/ms179331.aspx

Проблема, с которой вы столкнетесь, заключается в том, что в какой-то момент вам придется ее расшифровать. Так как он находится на их компьютерах, и код, который вы используете для проверки информации, также находится там, это никогда не будет подлинным доказательством подделки. Они могут просмотреть ваш скомпилированный код и выяснить, как обойти имеющиеся у вас механизмы безопасности.

Вы также должны посмотреть на обфускацию кода для .Net http://msdn.microsoft.com/en-us/magazine/cc164058.aspx Это не остановит их, но замедлит.