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

Отсюда поэтапные проблемы:
1) Формирование пинкодов... Скорее всего это случайные величины, выбранной длины. Однако,
поскольку карточки будут печататься партиями (допустим, по 1000 шт.) как отследить уникальность пинов.
Думаю, либо хранить их всех в базе (по -моему не очень удобно), либо при формировании завязать первые n-байт на текущем времени (относительно какой-то исходной точки), остальные — случайные.
2) хранение пин-кодов. Думаю использовать односторонюю функцию (хэш-функцию).
Я так понитмаю, что она должна быть не стандартной (типа md5) иначе злоумышленник, при получении доступа к таблице (ХЭШ(пин) — значение остатка), сможет применить к своему пин — эту же функцию и без труда исправить остаток.

Не хочется решать задачу об изобретении велосипеда, может быть уже есть стандартные подходы, тем более вещи серьезные.
Вобщем, подскажите литературы или поправьте меняя
Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Добрый день.
А>Возникла надобность создания системы платежей на основа карточек с пин-кодами.

А>Отсюда поэтапные проблемы:
А>1) Формирование пинкодов... Скорее всего это случайные величины, выбранной длины. Однако,
А>поскольку карточки будут печататься партиями (допустим, по 1000 шт.) как отследить уникальность пинов.
А>Думаю, либо хранить их всех в базе (по -моему не очень удобно), либо при формировании завязать первые n-байт на текущем времени (относительно какой-то исходной точки), остальные — случайные.

Ни в коем случае не хранить пин-коды в базе. Это громадная брешь в безопасности. Просто используй какой-нить псевдослучайный алгоритм генерации пин-кодов. К тому же, зачем тебе уникальность пинов?
Упрощенно: в таблице хранишь пару (id-карточки, id-карточки закриптованное пином). Этого будет достаточно, чтобы аутентифицировать пользователя. Если злоумышленник получит доступ к этой базе, то ничего полезного он там для себя не найдет.

Здравствуйте, MaximVK, Вы писали:

MVK>Здравствуйте, Аноним, Вы писали:

А>>Добрый день.
А>>Возникла надобность создания системы платежей на основа карточек с пин-кодами.

А>>Отсюда поэтапные проблемы:
А>>1) Формирование пинкодов... Скорее всего это случайные величины, выбранной длины. Однако,
А>>поскольку карточки будут печататься партиями (допустим, по 1000 шт.) как отследить уникальность пинов.
А>>Думаю, либо хранить их всех в базе (по -моему не очень удобно), либо при формировании завязать первые n-байт на текущем времени (относительно какой-то исходной точки), остальные — случайные.

MVK>Ни в коем случае не хранить пин-коды в базе. Это громадная брешь в безопасности. Просто используй какой-нить псевдослучайный алгоритм генерации пин-кодов. К тому же, зачем тебе уникальность пинов?
MVK>Упрощенно: в таблице хранишь пару (id-карточки, id-карточки закриптованное пином). Этого будет достаточно, чтобы аутентифицировать пользователя. Если злоумышленник получит доступ к этой базе, то ничего полезного он там для себя не найдет.



Карточки будут подобными интернет картам. Т.е. у них будет баланс. Т.о. на сервере нужно хранить, допустим id карты и статок. Если двум разным пользователям попадаются карточки с одинаковыми пин-ами, тогда для них будет один баланс. Система будет неправильно отслеживать остаток.

Здравствуйте, Аноним, Вы писали:

А>Карточки будут подобными интернет картам. Т.е. у них будет баланс. Т.о. на сервере нужно хранить, допустим id карты и статок. Если двум разным пользователям попадаются карточки с одинаковыми пин-ами, тогда для них будет один баланс. Система будет неправильно отслеживать остаток.

Остаток должен привязываться к ИДу карточки, а не к ПИНу. ПИН — это инструмент для авторизации, не более того. Поэтому, ИДы должны быть уникальными, а ПИНы — нет.

Здравствуйте, fefelov, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Карточки будут подобными интернет картам. Т.е. у них будет баланс. Т.о. на сервере нужно хранить, допустим id карты и статок. Если двум разным пользователям попадаются карточки с одинаковыми пин-ами, тогда для них будет один баланс. Система будет неправильно отслеживать остаток.

F>Остаток должен привязываться к ИДу карточки, а не к ПИНу. ПИН — это инструмент для авторизации, не более того. Поэтому, ИДы должны быть уникальными, а ПИНы — нет.

Каким образом будет определятся ID карты? Пользователи вводят одинаковые пин'ы, как система определит, что они соответствуют разным id? Ввод доп. информации (типа серийного номера карты)- неприемлим — операторы сотовой связи, например, обходятся без него.

Здравствуйте, Аноним, Вы писали:

А>Каким образом будет определятся ID карты? Пользователи вводят одинаковые пин'ы, как система определит, что они соответствуют разным id?

Ага... Кажется возникла путаница в терминологии. Задайте ваш вопрос с учетом определения термина PIN в Википедии.

А>Ввод доп. информации (типа серийного номера карты)- неприемлим — операторы сотовой связи, например, обходятся без него.
Я уже давно не пользуюсь картами для оплаты мобильной связи. Но, покопавшись в чулане, нашел у себя старую карту Би+, на которой указаны:
— серийный номер (10 цифр)
— код активации (12 цифр).
Для оплаты услуги нужно указать только код активации.
Но здесь проблемы нет. Ведь информационная емкость кода активации (12 цифр) больше информационной емкости серийного номера (10 цифр).