Доступ к данным о заказе из эл. письма

Требуется разослать множеству клиентов по эл. почте прикреплённый документ или ссылку на него на внешнем ресурсе.
Электронный документ (PDF) представляют из себя некоторое количество квитанций и может быть очень увесистым, теоретически свыше 50 МБ (когда много квитанций).

Обдумывались следующие варианты:

1. прикреплять документ несмотря на его теоретически высокий размер
2. давать ссылку на ресурс, в котором PDF будет динамически создаваться по запросу через HTTP(S)
3. давать ссылку на отдельный хостинг-ресурс (Amazon S3 или подобные), куда будут помещаться все файлы PDF

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

Среди вариантов аутентикации был предложен метод получения доступа к документу с помощью дополнительного параметра в URL, хеш-кода (MD5, SHA-1).
То есть, совершив покупку, пользователь получает ссылку типа _http://storage.mycompany.com/get_document?code=XXX . Насколько это безопасно?

Какой вариант предпочтительнее и почему? Или предложите другой вариант.

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

Сообщение отредактировано: Adil - 04.01.12, 10:53

Насчёт уязвимости эл. почты известно. Однако, в эл. документе нет никаких данных кроме тех, которые нужны для покупки (фио, сумма сделки и прочие детали). То есть в них не будет ничего конфиденциального.

Задачей является избежать ситуации, когда некто несанкционированно получает доступ к этому эл. документу и распечатывает его.

Необходимо ли обязывать пользователя заходить в систему для получения документа? Или наличия хеш-кода достаточно?
И не может ли тогда применение хеш-кода стать потенциальной уязвимостью?

a. чревато проблемами с доставкой, битостью файлов и т.п. Потом руками разгребать недошедшие заказы и переотправлять.

Лучше конечно размещать на своем сервера с персональные ссылками.
Всегда можно держать БД в актуальном состоянии ("банить" штрафников, оперативно добавлять новых, корректировать PDF)
Ссылка конечно со сроком - иначе с одной стороны будут копиться мертвые души, с другой - ссылка уйдет в массы

Цитата Romtek @ 04.01.12, 10:38

Среди вариантов аутентикации был предложен метод получения доступа к документу с помощью дополнительного параметра в URL, хеш-кода (MD5, SHA-1).
То есть, совершив покупку, пользователь получает ссылку типа _http://storage.mycompany.com/get_document?code=XXX . Насколько это безопасно?

что под безопасностью подразумевается? Застраховаться от передачи ссылки/документов "соседу" никак не получится.
Только если вся работа делается через свой софт, которые привязан к конкретной системе.

Цитата Romtek @ 04.01.12, 11:02

Необходимо ли обязывать пользователя заходить в систему для получения документа? Или наличия хеш-кода достаточно?
И не может ли тогда применение хеш-кода стать потенциальной уязвимостью?

Для такого уровня секретности заставлять входить в систему - лишнее, хеша достаточно.

Цитата Romtek @ 04.01.12, 11:02

Необходимо ли обязывать пользователя заходить в систему для получения документа? Или наличия хеш-кода достаточно?
И не может ли тогда применение хеш-кода стать потенциальной уязвимостью?

что "личный кабинет", что "хэш-код" уязвим к атакам "передать соседу", который используется значительно чаще, чем "украсть/подсмотреть".
Можно конечно делать привязку к IP-подсети, вполне вариант если покупатель юзает ссылки только с работы/дома.
А так, кроме бана проштрафившихся пока вроде ничего универсального не придумано

Всем спасибо за советы.

Цитата lepit @ 04.01.12, 11:35

А так, кроме бана проштрафившихся пока вроде ничего универсального не придумано

Ну да. Штрафы с клиентов сисадмину на счёт. Ему же надо на что-то жить.

Romtek, предлагаю вариант b, с поправками:

• Каждый клиент имеет личный сертификат и открытый ключ. Можно рассмотреть возможность сделать это прозрачно и ещё более безопасно, используя в качестве отправной точки сеансовый ключ текущей защищённой сессии, но ИМХО это неудобно и вообще перебор.
• Каждый PDF при создании шифруется личным ключом клиента и подписывается своим (твоим) сертификатом. Поочитать его т.о. сможет только уникальный клиент, и при этом сможет убедиться в подлинности документа.
• По успешному получению PDF клиент отсылает письмо, подписанное своим сертификатом, что является сигналом, что этот документ этому клиенту больше не нужен. Можно удалять.

Тут даже SSL-сессии не нужны. Есть нюансы, связанные с начальной раздачей ключей и сертификатов, но это решается однократно.

Сколько в последнее время утекло личной информации через эти url с хэшами, включая те же СМСки Мегафона, а воз и ныне там...

Цитата Uncle_Bob @ 08.01.12, 16:40

Сколько в последнее время утекло личной информации через эти url с хэшами, включая те же СМСки Мегафона, а воз и ныне там...

Это к чему-то конкретно сказано или для общей информации?

Цитата Romtek @ 08.01.12, 21:12

Это к чему-то конкретно сказано или для общей информации?

по сабжу, точнее пункту b

Сообщение отредактировано: Uncle_Bob - 09.01.12, 19:17

Страхи вызваны чем-то конкретным?

У меня страхов нет, по-моему это удел проектировщика. Ты готов отвечать за что там у пользователя за тулбар стоит и куда он отсылает данные о посещенных url?

Про конкретику я уже привел пример с мегафоном.

Сообщение отредактировано: Uncle_Bob - 09.01.12, 19:24

Согласен. Но к той же категории тогда можно отнести и кейлоггер. Разве не так?

Цитата Romtek @ 09.01.12, 19:26

Но к той же категории тогда можно отнести и кейлоггер. Разве не так?

Нет. Кейлоггер - это троян, который ловится антивиром в общем случае. Тулбар браузера - это малварь, против которой антивир бессилен.