Я строю безопасный платежный портал.
В настоящее время у нас есть два приложения, которые будут использовать это. Один - это веб-приложение, другой - приложение для ПК. Оба из них требуют, чтобы пользователи входили в систему / аутентифицировались, одинаковые учетные данные могут использоваться для любого приложения.
Я хочу создать механизм автоматического входа в систему, который будет заполнять все различные данные для входа в систему / заказа и иметь возможность вызывать это из любого приложения, упомянутого выше. Я думал, что лучший способ сделать это - передать эту информацию в зашифрованном виде через URL. т.е. https://mysite.com/TakePayment.aspx?id=GT2jkjh3....
Поскольку мы не хотим слишком тесно интегрировать обработку платежей в настольное приложение, чтобы уменьшить нашу область применения PCI, мы решили открыть браузер для центральной защищенной страницы платежей с помощью простой оболочки, выполняемой с полным URL-адресом. вызывая браузер по умолчанию, чтобы открыть эту страницу.
Первоначально мы использовали AES для шифрования, но в настоящее время это пересматривается, поскольку мы предпочли бы не выдавать ключ конечному пользователю (AES является симметричным, симметричным шифрованием = обеим сторонам нужен закрытый ключ, зачем вообще шифровать, так как мы собираемся распространять приложение?) Поэтому я собираюсь переключить его на использование шифрования с открытым ключом со встроенными подпрограммами RSA в .NET
После кодирования части RSA я заметил, что большинство примеров в сети использовали длину ключа 1024 бита, я пошел с этим и теперь наш портал работает с шифрованием с открытым ключом, однако генерируемые URL-адреса намного длиннее, чем когда я Я использовал AES, поэтому я начал изучать максимальные ограничения для URL. http://www.boutell.com/newfaq/misc/urllength.html Говорит, что IE - это браузер с ограничением в 2048 символов в части пути. Мои первоначальные тесты с шифрованием RSA показали, что мои URL будут иметь длину около 1400 символов.
Мои вопросы сводятся к следующему:
1) Есть ли лучший способ передачи информации из настольного приложения на веб-сайт, о котором я не думаю? Я бы предпочел, чтобы его было так же легко использовать с другой веб-страницы, как и с рабочего стола, поэтому мое текущее решение.
2) Нужны ли 1024-битные ключи RSA? Или перебор для чего-то подобного? Более короткий ключ будет означать более короткий зашифрованный текст, верно?
3) Есть ли другие непредвиденные проблемы с URL-адресами в диапазоне 1200–1400 символов? Доверенные? Межсетевые экраны? Веб-акселераторы?
Спасибо
Обновление 12/11/2011:
Приходите, чтобы узнать, метод, который мы в итоге использовали здесь, в конечном итоге укусил нас в задницу (или, скорее, мы узнали об этом сегодня, хотя проблема была очень спорадической и трудной для отслеживания ...)
Обычный текстовый токен, который мы зашифровали, изначально был довольно маленьким, всего около ста байтов или около того. Это то, что привело к тому, что мои тестовые URL были длиной около 1400 байт. Благодаря ползучести функций мы были обязаны добавить больше данных в токен, а средняя длина URL-адреса увеличилась до 1700-1800.
Как только длина нашего обычного текста достигает 173 символов в длину и выше, длина URL снова увеличивается, на этот раз до 2080+ или около того, что теперь вызывает проблемы для IE. После некоторого изучения того, как работает шифрование RSA, этого вполне следовало ожидать, но изначально это был недосмотр с моей стороны.
Мы используем 1024-битное шифрование RSA, что означает, что максимальный размер блока данных, который может быть зашифрован, составляет 1024/8 - 24 = 86 байтов, каждые 86 байтов необходимо «нарезать» и шифровать отдельно, поэтому при 86 * 2 = 172, мы только зашифровываем два блока, выше этого мы зашифровываем три, четыре, пять и т. Д. Пройдя 172, длина нашего шифрованного текста выросла настолько, что URL-адреса теперь слишком длинные ... Я Вероятно, здесь немного запутано объяснение, но в этом его основная суть ..
Похоже, мы будем искать лучший способ, чтобы это работало, поскольку можно ожидать, что они захотят добавить «больше возможностей» в будущем, и, таким образом, наш токен будет расти еще больше