Возникла необходимость хранить в базе данных (SQL Server 2000) номера кредиток. По простому вариант выглядит так: человек вводит на сайте (https присутствует) номер кредитки, дальше этот номер должен сохраниться в базе данных. Хотелось бы сделать это более секьюрно.
В открытом виде хранить в таблице номер неохота, надо его как-то шифровать/дешифровать. Думаю, сделать это через отдельную внешнюю длл. Каким образом лучше делать это шифрование?
Также думаю под хранения номеров кредиток сделать отдельную базу данных. Просто к основной могут приходить запросы с публичного сайта и вдруг, кто-то получит к ней доступ.
Если кто сталкивался с подобной задачей или знает какие полезные ссылки - поделитесь. Очень неохота потерять базу кредиток и потом приносить извинения клиентам. :)

miksoftВы сначала определитесь - от каких конкретных угроз вы хотите защититься.
От угрозы, что кто-нибудь скомуниздит номера кредиток.
miksoftПотому как, если, например, кому-то удастся подсоединиться к вашей базе под видом скрипта сайта (с точки зрения СУБД), то все ваше шифрование не поможет.
Ну это так. Значит надо и от этого предохраниться. Строки подключения как-то особо хранить и еще, чтобы имея возможность просмотреть и проапдейтить одну кредитку не было возможности поменять/просмотреть номера остальных. Поэтому и спрашиваю здесь.
miksoftИ вообще, а они нужны эти номера кредиток? Может, хранить только первые+последние цифры и/или код авторизации и/или хэш номера?
В банке, через который операции проводите, пробовали проконсультироваться?
Хочется автоматически биллить кредитки через авторайз.нет. Там вроде нужен полный номер и дата окончания. Потом планируется переход на процессинг через QB. Там вроде тоже нужен полная инфа.

И каждый раз вручную забивать этот номер? Или клиента просить его забивать?
Одну кредитку можно, десять можно. А 300 штук раз в месяц? Клиента уже достало. Хочет автоматизировать процесс. :)

softwarer1. Подумайте, так ли нужно хранить номера целиком.

2. При таком подходе я бы подумал примерно над следующей схемой:

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

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

в. Номера хранятся в тривиально замутненном виде, скажем, каждая тетрада хранится в виде 1XX4X2XXXXX3XXXX, где 1234 - реальная цифра номера, соответствующая по счету, X - случайный мусор.

г. БД получает номера в таком вот замутненном виде. Как собрать из полученного результата нужный номер - знает только серверный скрипт.

В итоге всего этого получается, что для осуществления кражи потребуется практически полный контроль над системой (нужна будет возможность унести файлы с номерами, информация из БД для сопоставления id и fio, а также исходники скриптов с веб-сервера для получения реального номера из замутненного состояния). При этом ввод в систему собственных реквизитов не слишком-то поможет в расшифровке.
Спасиб за предложение. Сейчас еще нарисую архитектуру систему и что пока планирую сделать. А вы покритикуете. :)

miksoft rgrИ каждый раз вручную забивать этот номер? Или клиента просить его забивать?
Одну кредитку можно, десять можно. А 300 штук раз в месяц? Клиента уже достало. Хочет автоматизировать процесс. :)человек совершает 300 платежей в месяц? Как говорится, не верю!
А в 200 веришь? :)
Не знаю точное число.
Сейчас клиент реально тратит 5 часов раз в месяц на процессинг кредиток. А если количество его пользователей увеличится (на что он оч. надеется), то время только возрастет. Работа нудная и тупая, ввел номер кредитки (сейчас они у него хранятся в отдельном десктоп приложении), нажал кнопку и дальше по новой. Логично желание этот процесс автоматизировать.

miksoft softwarerВ итоге всего этого получается, что для осуществления кражи потребуется практически полный контроль над системойЛибо подменить один файл со скриптом. Например, через дырявый FTP.
Это вопрос отдельный. У нас полный доступ к серверу (фтп даже и не пользуемся) и если клиент кому отдаст пароли, то его его проблемы. Постараемся сами эти пароли никуда не отдавать. :)

softwarer rgrРабота нудная и тупая, ввел номер кредитки (сейчас они у него хранятся в отдельном десктоп приложении), нажал кнопку и дальше по новой. Логично желание этот процесс автоматизировать.
Cделайте у себя возможность схавать список кредиток за одну операцию. Обработайте и забудьте. И пусть хранение этого списка будет головной болью клиента, а не вашей.
Не, не пойдет. Клиент должен иметь возможность проапдейтить свой номер. Можно, конечно, мылом его клиенту слать и пускай в своем приложении апдейтит вручную. Но там есть свои трудности, хотя такой вариант мне в голову приходил. :)

Не, не пойдет. Кастомер должен иметь возможность проапдейтить свой номер. Можно, конечно, мылом его клиенту слать и пускай в своем приложении апдейтит вручную. Но там есть свои трудности, хотя такой вариант мне в голову приходил. :)

Архитектура системы. Черновой вариант.

gtdbШифровать каждый из номеров кредитки можно по паролю пользователя. А сам пароль в базе естественно не хранить (только MD5). Соответственно восстановить каждый номар можно только зная оригинальный пароль каждого клиента. При востановлении забытого пароля номер кредитки теряется.
Бизнес-логика позволяет так сделать ?
Пока нет. Оригинальный пароль клиента хранится в базе. И есть функциональность для того, чтобы выслать ему письмом этот забытый пароль.

softwarer rgrРабота нудная и тупая, ввел номер кредитки (сейчас они у него хранятся в отдельном десктоп приложении), нажал кнопку и дальше по новой. Логично желание этот процесс автоматизировать.
Cделайте у себя возможность схавать список кредиток за одну операцию. Обработайте и забудьте. И пусть хранение этого списка будет головной болью клиента, а не вашей.
В итоге все таки пришли к этому решению. :)
Всем спасибо за участие.