Сбор информации о кредитной карте, безопасность?

Question

Сбор информации о кредитной карте, безопасность?

0

Мы создали портал для пользователей, которые платят онлайн через наш веб-сайт.

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

Каков наилучший способ сохранить данные кредитной карты в базе данных mySQL? Я хочу, чтобы это было безопасно, я не хочу просто сохранять их данные в поле как "XXXXXXXXXXXXXXXX".

Какой самый безопасный способ сохранить данные кредитной карты? У нас будет SSL на нашем сервере, когда сайт будет работать.

Привет

Latox 19 янв. 2011, в 03:46

Источник

2

Самый простой способ - это НЕ Оставьте платеж третьей стороне, такой как Paypal или Google Checkout. Я считаю, что вы должны пройти сертификацию в США, чтобы даже сохранить данные кредитной карты в базе данных для общедоступного веб-сайта.
Earlz 19 янв. 2011, в 02:31
0

самый безопасный способ? Не надо! Второй самый безопасный: зашифрованный.
Mitch Wheat 19 янв. 2011, в 02:31
0

Мы не используем Paypal или Google Checkout, я должен рассмотреть, что предлагает наш шлюз, так как мы используем этот хостинг.
Latox 19 янв. 2011, в 02:32

Показать ещё 1 комментарий

Теги:

php

mysql

3 ответа

0

Просмотрите требования pci, связанные с Mark B.

В одном из моих недавних контрактов я работал с государственным департаментом, хотя я не имел ничего общего с соблюдением pci, я знаю, что он стоит более 1 миллиона долларов. Вам, конечно, не нужно тратить столько. но воспринимайте это как предупреждение.

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

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

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

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

Ваши клиенты, вероятно, будут смотреть на вас более любезно, если вы указали "Неформатированные данные карты"

DC

DeveloperChris 19 янв. 2011, в 01:28

0

Это неверно, или, может быть, времена изменились, или, возможно, это был 1 миллион, потому что они были правительственным департаментом. Я знаю несколько PCI SAQ-D-совместимых (самый высокий и самый строгий уровень соответствия PCI), которые управляют сервером и безопасностью для вас, тогда вам просто нужно надежно хранить данные карты с шифрованием и все. В общем, скажем, максимум $ 800 / м
3zzy 07 дек. 2012, в 03:42
0

@Nimbuz Вы говорите об оплате $ 800 в месяц третьему лицу, уже сертифицированному провайдеру. Не о том, чтобы получить согласие самостоятельно. Сколько это им стоило? Я хотел сказать, что это может стоить много денег. возможно, не так много, как Gov Dpt, но большинство людей в любом случае не могут позволить себе 800 долларов в месяц. Большая часть моего комментария была о том, что я этого не делал (сохраненный номер), особенно в недорогой общей среде.
DeveloperChris 10 дек. 2012, в 05:45
0

Его даже не 800, я только что купил один виртуальный сервер VMware в частном облаке, который совместим с SAQ-D, за 360 / месяц. Вы правы, стоит сделать это самостоятельно, но вам не обязательно это делать. Я имею в виду, что почти все на каждом сайте, в блоге и на форуме просто говорят, что это слишком дорого и сложно и т. Д., Что не совсем верно, если вы знаете, что делаете.
3zzy 10 дек. 2012, в 13:04

Показать ещё 1 комментарий

0

шифрование (в двух направлениях)

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

НЕТ

ЕСЛИ ВЫ МОЖЕТЕ ИЗБЕЖАТЬ ХРАНЕНИЯ ТАКОЙ ИНФОРМАЦИИ НА ВАШЕМ СЕРВЕР, КОТОРУЮ ВЫ ДОЛЖНЫ. PERIOD! Как и кто-то еще, даже Jeff Atwood (автор Stackoverflow) советует вам не хранить такую информацию. Вы можете быть скомпрометированы, а затем эта информация будет доступна в Интернете. Как вы все равно делаете платежи? Разве вы не используете что-то вроде PayPal или что-то такое, что пользователи даже не должны вводить эту информацию в любом случае?

Alfred 19 янв. 2011, в 00:32

0

Это никак не помогает. В прошлом я сам занимался обработкой платежей (до PCI) и могу сказать вам, что есть много причин не использовать сторонний процессор (за исключением иногда непомерных сборов).
DeveloperChris 19 янв. 2011, в 03:16
0

@DeveloperChris вы не должны хранить этот период информации. PS: я предоставил то, что я думаю, может быть решением. Согласно @Earlz, это даже запрещено в США, если вы не сертифицированы или что-то еще.
Alfred 19 янв. 2011, в 03:19
0

Я не сказал хранить информацию, которую я сказал, а не направлять ее стороннему платежному процессору (например, PayPal), можно принимать платежи самостоятельно, как я делал в прошлом сам. Я не верю, что двустороннее шифрование является совместимым, чтобы использовать его, ключ должен храниться на сервере, что делает шифрование бесполезным. потому что хакер может получить оба компонента. Хммм, учтите, что двустороннее шифрование с использованием пароля пользователя как части ключа может работать. При условии, конечно, вы не храните пароль пользователя в виде открытого текста.
DeveloperChris 19 янв. 2011, в 03:38

Показать ещё 1 комментарий

Ещё вопросы

Самый простой способ - это НЕ Оставьте платеж третьей стороне, такой как Paypal или Google Checkout. Я считаю, что вы должны пройти сертификацию в США, чтобы даже сохранить данные кредитной карты в базе данных для общедоступного веб-сайта.
самый безопасный способ? Не надо! Второй самый безопасный: зашифрованный.
Мы не используем Paypal или Google Checkout, я должен рассмотреть, что предлагает наш шлюз, так как мы используем этот хостинг.
Это неверно, или, может быть, времена изменились, или, возможно, это был 1 миллион, потому что они были правительственным департаментом. Я знаю несколько PCI SAQ-D-совместимых (самый высокий и самый строгий уровень соответствия PCI), которые управляют сервером и безопасностью для вас, тогда вам просто нужно надежно хранить данные карты с шифрованием и все. В общем, скажем, максимум $ 800 / м
@Nimbuz Вы говорите об оплате $ 800 в месяц третьему лицу, уже сертифицированному провайдеру. Не о том, чтобы получить согласие самостоятельно. Сколько это им стоило? Я хотел сказать, что это может стоить много денег. возможно, не так много, как Gov Dpt, но большинство людей в любом случае не могут позволить себе 800 долларов в месяц. Большая часть моего комментария была о том, что я этого не делал (сохраненный номер), особенно в недорогой общей среде.
Его даже не 800, я только что купил один виртуальный сервер VMware в частном облаке, который совместим с SAQ-D, за 360 / месяц. Вы правы, стоит сделать это самостоятельно, но вам не обязательно это делать. Я имею в виду, что почти все на каждом сайте, в блоге и на форуме просто говорят, что это слишком дорого и сложно и т. Д., Что не совсем верно, если вы знаете, что делаете.
Это никак не помогает. В прошлом я сам занимался обработкой платежей (до PCI) и могу сказать вам, что есть много причин не использовать сторонний процессор (за исключением иногда непомерных сборов).
@DeveloperChris вы не должны хранить этот период информации. PS: я предоставил то, что я думаю, может быть решением. Согласно @Earlz, это даже запрещено в США, если вы не сертифицированы или что-то еще.
Я не сказал хранить информацию, которую я сказал, а не направлять ее стороннему платежному процессору (например, PayPal), можно принимать платежи самостоятельно, как я делал в прошлом сам. Я не верю, что двустороннее шифрование является совместимым, чтобы использовать его, ключ должен храниться на сервере, что делает шифрование бесполезным. потому что хакер может получить оба компонента. Хммм, учтите, что двустороннее шифрование с использованием пароля пользователя как части ключа может работать. При условии, конечно, вы не храните пароль пользователя в виде открытого текста.

Marc B · Accepted Answer · 2011-01-19T01-00-00.000Z

Вы никогда не должны хранить детали CC, кроме сильно замаскированного формата "XXXX XXXX XXXX 1234", и вам не разрешено хранить номера CVV.

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

SSL не имеет отношения к защите вашей базы данных, соединение SSL существует только в то время, когда транзакция HTTP открыта, а затем исчезла. Вы должны всегда иметь 100% -ную защиту на своем сервере и в своей базе данных.

Я бы посоветовал получить копию стандартов PCI, в которых очень подробно описываются требования к различным уровням кредита обработка/обработка карт.

Стандарты PCI - отличное место для начала. Хранение данных карты - очень плохая идея, даже если она зашифрована. Просто слишком сложно разобраться в этом и сохранить его на протяжении всего жизненного цикла данных.