Или флешем. Или Сильверлайтом. Или чем-то еще, но на стороне клиента. Бывает?
Прелюдия:
Полностью вопрос звучит так: есть 10,000 магазинов. В практических целях они хотят обмениваться информацией о покупках, на предмет «а у вас есть такой же покупатель?». Есть единый центр, который будет проводить сравнения. Но ни один из участников сети не доверят ни центру ни друг другу. Сдавать конкретные данные о своих покупателях никто не хочет. Тогда возникает мысль: каждый магазин в отдельности считает хеш по всем полям (имя покупателя, номер карточки, адрес...) и сливает их в один единый центр, откуда ему и сообщается, что такой же есть у кого-то другого в сети. Это, по идее, проблему доверия решает.
Акт:
Рассчитывать хеш на стороне сервера можно, это проблему снимет, но имплементация такого механизма требует уже вмешательства програмистов. А из 10,000 магазинов-участников у подавляющего большинства такой возможности нету или она им кажется слишком геморойной. Они хотели бы иметь что-то типа Гугль Аналитиксового кода для чекаута, который относительно легко встраивать, но который бы при этом все же не передавал бы данные покупателя в открытом виде центру, ибо центру они таки не верят.
Тут мне кажется, что в принципе сделать это можно (не принимаем во внимание пока громоздкость скрипта). Итого первая часть вопроса, для проформы задаваемая: верно ли я понимаю, можно ли?
Тяжелая часть:
Как быть с авторизацией? Если все-все-все хеширование делается на стороне клиента, то как сделать так, что бы посторонний злоумышленник не мог насовать левых данных в систему от имени одного из магазинов? При этом не трогая (или сведя к минимуму) исполняемые скрипты на стороне сервера магазина.
Бытовое пояснение: вот есть у вас магазин на Yahoo Store. Не разрешает вам Яха трогать свои сервера. Ява скрипт вписать можете в страницу чекаута. Но не более того. А жить как-то надо.
Реализовать какой-нибудь алгоритм хеширования (md5, sha1, etc) можно. Но: если скрипт будет иметь доступ ко всей той информации, которую нужно зашифровать, то без анализа скрипта не получится сказать, не отсылает ли он все это в открытом виде. К тому же, для того, чтобы предоставлять скрипту информацию об имени юзера, номере карточки и его адресе, всё это все равно придется извлекать откуда-нибудь из БД на сервере. А это — работа с серверной частью.
Почитайте. Возможно, будет лучше, если вся логика определения юзера будет лежать у Вас, а клиенту нужно будет только подключить скрипт.
Оценивая пространство номеров выпущенных банковских карт в 26 бит, фамилий — в 13 бит, имен — в 13 бит (добуквенно с карты, чтобы не было проблемы опечаток)) получаем около 52 бит. Учитывая, что для проверки соль должна быть единой для всей системы, выявляется угроза построения радужных таблиц для вашей системы.
Если же добавлять адрес, возникает множество проблем с опечатками.
Возможно, добавление expiration date и дня рождения покупателя (трудно ввести эти показатели ошибочно) перекинет множество значений за вычислимый предел, но все таки опасные значения будут очень близко («на грани»).
Угрозу вброса фальшивых данных от магазина-участника системы или от стороннего злоумышленника не вижу — при пространстве хеш-функции в 128-256 бит у него не хватит возможностей «навбрасывать» до реальной коллизии.
Можно было бы с помощью javascript считать хэш по нужным полям, и отправлять в центр, который будет анализировать и сравнивать эти хэши.
Для того, чтобы злоумышленник «не мог насовать левых данных в систему от имени одного из магазинов» можно было бы подписывать отправляемые хэши закрытым ключом магазина. Но если делать это всё джаваскриптом, то ключ придётся хранить в месте доступном из джаваскрипта, а значит, любой из покупателей с FireBug может получить закрытый ключ для подписи.
Для того, чтобы злоумышленник «не мог насовать левых данных в систему от имени одного из магазинов» лучше воспользоваться клиентскими сертификатами — удобно для пользователя и не нужна разработка — ограничение доступа работает на уровне браузера и веб сервера.
Тяжелая часть:
Как быть с авторизацией? Если все-все-все хеширование делается на стороне клиента, то как сделать так, что бы посторонний злоумышленник не мог насовать левых данных в систему от имени одного из магазинов? При этом не трогая (или сведя к минимуму) исполняемые скрипты на стороне сервера магазина.
Это не тяжёлая часть. Это основная причина не делать такую глупость.
Код на клиенте открыт со всеми вытекающими последствиями.
Дело не в коллизии. Если скрипт виден целиком, то негодяй берет его и размещает у себя на сервере с большим трафиком. Только теперь он кормить его не переменными со страницы чекаута, а генерирурет данные. Теперь при посещении страницы с такой миной скрипт попадает в браузер посетителя, рассчитывает хеш и отправляет в центр. Тихо спокойно сгружается куча левых записей в центр.
Средний
Средний
