Могу ли я использовать шифрование JS вместо SSL для платежей по кредитным картам?

Question

У меня есть HTML-форма, где люди могут совершать платежи на моих сайтах. Вместо использования SSL я задаюсь вопросом, могу ли я использовать библиотеку JS, которая зашифровывает информацию о кредитной карте и отправляет ее на сервер в виде открытого текста, но зашифрованный, чем сервер расшифровывает. Я нашел несколько библиотек, которые делают это, они в основном запрашивают пару ключей с сервера, шифруют ее и отправляют на сервер в зашифрованном виде. Вот те, которые я нашел:

http://www.jcryption.org/

http://www.hanewin.net/encrypt/

http://www.vincentcheung.ca/jsencryption/

Это достаточно безопасно для платежей по кредитным картам? Я знаю, что сеанс не зашифрован, но единственное, что действительно имеет значение, это информация о кредитной карте, верно?

Answer 1

Это небезопасно ни в какой форме, форме или форме.

Человек посередине может заменить открытый ключ своим собственным. Любой клудж, который вы разработаете с помощью "referer" или чего-либо еще, кроме SSL, не восстановит безопасность этой ужасной схемы.

Когда вы можете получить маржинальный сертификат бесплатно или приличный сертификат за бесценок, почему вы облажались с номером кредитной карты людей? Не получая номер кредитной карты при транспортировке, вы нарушаете PCI и, вероятно, подвергаете себя ответственности, во много раз превышающей стоимость получения и использования сертификата. Или, может быть, вы просто решили, что это проблема владельцев карт?

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

Независимо от схемы, вы не можете создать безопасность из незащищенности.

Answer 2

Нет. Не используйте JavaScript для защиты платежей по кредитным картам.

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

Вот сценарий.

1. Вы заполняете свой веб-сайт example.com и размещаете все в Интернете. Сайт запускает, ууу. Вы использовали javascript для защиты своей системы платежей по кредитным картам.

2. Кто-то по имени Nefarious Hacker замечает, что вы не используете проверенный и надежный метод защиты важной личной информации, поэтому он загружает все ваши HTML, JS и CSS.

3. N. Хакер удаляет все шифрование на основе js, оставляя только форму. Затем он размещает его на evil-example.com. Он выглядит точно , как ваш сайт, и ведет себя точно так же, как ваш сайт. За исключением того, что он передает незашифрованные данные кредитной карты в базу данных N Hacker.

4. N. Хакер рассылает некоторые фишинговые письма, которые указывают пользователям на evil-example.com. Несколько пользователей, считающих злой сайт действительным, вносят платежи. Их кредитная карта теперь украдена.

5. N Хакер может успешно отравить кэш DNS, поэтому некоторые пользователи, заходящие на example.com, получают обслуживание evil-example.com. У них нет оснований полагать, что сайт является поддельным (URL-адрес - это то, что они ожидают), поэтому они отправляют платежи. Их карты теперь украдены.

Если бы у вас был сертификат SSL, пользователи НЕМЕДЛЕННО знали бы, что evil-example.com не был доверенным, или что evil-example.com, выдававший себя за example.com, был поддельным.

(я сделаю его большим, чтобы он был очевиден)

Итог - javascript недостаточно безопасен для осуществления платежей CC .

Answer 3

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

Answer 4

Вы можете использовать шифрование JS и игнорировать тот факт, что это не безопасно.

В таком случае проблема заключается в том, что люди не захотят вводить данные своей кредитной карты на странице без SSL-соединения. Это не просто технари; Многие нетехнические пользователи знают, что нужно искать замок перед вводом номера своей кредитной карты, даже если они не знают, что такое TLS или SSL.

Answer 5

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

Answer 6

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

Answer 7

Что если пользователь отключит JavaScript в своем браузере? Я бы сказал, будьте осторожны и придерживайтесь SSL.

Answer 8

Хотя технически данные, зашифрованные в JS, были бы аналогичны шифрованию с помощью реального сертификата, я думаю, что здесь вам не хватает ключевого элемента; ДОВЕРЯТЬ. При использовании настоящего сертификата SSL от надежного поставщика вы создаете круг доверия:

• Клиент доверяет Microsoft
• Microsoft доверяет GoDaddy / Verisign / кому угодно (благодаря Windows или любому другому веб-браузеру, поставляемому с корневыми сертификатами)
• GoDaddy / Verisign / тот, кто доверяет Вам (благодаря тому, что вы купили у них сертификат, и они подтверждают вашу личность)
• В веб-браузере появляются зеленые индикаторы и замки, и пользователь может при желании проверить сами сертификаты, что, в свою очередь, означает, что Клиент доверяет вам.

Если у вас просто незащищенный веб-сайт со словами «ваши данные в безопасности, просто игнорируйте то, что говорит ваш веб-браузер», тогда клиент не доверяет вам.

(и если они это сделают, то отправьте мне их информацию, у меня есть мост, чтобы продать их ...)

Кроме того, для того, чтобы это стоило, есть стандарты от основных компаний CC о том, как обрабатывать и хранить информацию о кредитных картах. Google "PCI DSS" для деталей, или: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Answer 9

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

Answer 10

@timms хорошо объясняет, почему это опасно - SSL обеспечивает шифрование и , что обеспечивает зашифрованные данные и в нужном месте. Кроме того, браузеры по-разному относятся к кешированию SSL и не-SSL - если вы не обслуживаете эти страницы по SSL, браузер пользователя может хранить важную информацию в открытом виде на компьютере пользователя.

Даже если это совершенно безопасно, это тоже не будет хорошей идеей. У многих пользователей было правило «искать значок замка для электронной коммерции», которое было введено в их мозг ИТ-специалистами, технически подкованными родственниками и т. Д. Весной за 25 долларов за сертификат SSL.

edit: Другая потенциальная проблема - большинству компаний кредитных карт требуется передача по SSL. Выполнение этого только с JS может привести к нарушению вашего торгового соглашения - могут возникнуть штрафы и расторжение.