Может быть я пытаюсь изобрести велосипед, тогда направьте на путь истинный...
Подскажите в какую сторону копать по такой проблеме.
Есть приложение, клиенты получают от него определенные услуги, оплата за которые производится по карточкам.
Каждая карточка несет следующую информацию:
1) номинал
2) номер карты
3) секретный пин код.
Известно примерное количсетво карточек, которые нужно генерировать в месяц.
У каждой карты есть срок действия, порядка двух месяцев.
Каким образом наиболее эффективно можно организовать такую систему. Эффективность, на мой взгляд, оценивается длинной кодов (как можно меньше) и стойкостью к перебору.
Приложение чем то похоже на организацию оплаты за звонки с мобильных телефонов.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, chocholl, Вы писали:
РМ>Генерируй случайные числа и забивай их в базу данных. Ничего лучше и безопаснее не придумаешь.
Спасибо за ответ.
Это первое, что мне пришло в голову. Но при таком подходе множество пин кодов должно быть очень разряжено, для защиты от простого перебора номеров, что сильно увеличит длинну кода. Кроме того, валидность карты по сроку действия можно будет определить только на стороне сервера бд.
Я ищу алгоритм с наличием состояний, чтобы по номеру карты можно было узнать когда она сгенерирована, какой у нее номинал. Чтобы получение списка карт сгенерированных за n-е обращение осуществлялось не обращением к бд, а запуском алгоритма с определенными входными параметрами (дата, количество, номинал и т.д.).
Здравствуйте, chocholl, Вы писали:
C>Я ищу алгоритм с наличием состояний, чтобы по номеру карты можно было узнать когда она сгенерирована, какой у нее номинал. Чтобы получение списка карт сгенерированных за n-е обращение осуществлялось не обращением к бд, а запуском алгоритма с определенными входными параметрами (дата, количество, номинал и т.д.).
Ну так проблем-то? Номер генерируй, а пароль случайный. Насколько я знаю, обычно так и делают.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, chocholl, Вы писали:
C>>Я ищу алгоритм с наличием состояний, чтобы по номеру карты можно было узнать когда она сгенерирована, какой у нее номинал. Чтобы получение списка карт сгенерированных за n-е обращение осуществлялось не обращением к бд, а запуском алгоритма с определенными входными параметрами (дата, количество, номинал и т.д.). РМ>Ну так проблем-то? Номер генерируй, а пароль случайный. Насколько я знаю, обычно так и делают.
Например, для генерации карточек оплаты сотовой связи применяют функции хеширования MD4, MD5 от номера, числа, суммы и тп...они обладают хорошим рассеиванием и стойкость.
Здравствуйте, vip_delete, Вы писали:
_>Например, для генерации карточек оплаты сотовой связи применяют функции хеширования MD4, MD5 от номера, числа, суммы и тп...они обладают хорошим рассеиванием и стойкость.
Очень интересно, именно это я и имел в виду.
Можно поподробнее.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, chocholl, Вы писали:
C>>Я ищу алгоритм с наличием состояний, чтобы по номеру карты можно было узнать когда она сгенерирована, какой у нее номинал. Чтобы получение списка карт сгенерированных за n-е обращение осуществлялось не обращением к бд, а запуском алгоритма с определенными входными параметрами (дата, количество, номинал и т.д.). РМ>Ну так проблем-то? Номер генерируй, а пароль случайный. Насколько я знаю, обычно так и делают.
Воспользуйся несеметричными алгоритмами шифрования (RSA к примеру). Палик ключ раздаёш всем, а приват — у тебя. Приватом шифруеш строку вида "05.12.2005 бла-бла-бла". На стороне клиента получить эту строку можно всегда, а вот сгенерировать практически нереально. (естественно за разумное время, но при условии, что не було допущено серёзных ошибок при реализации. Поэтому бери готовый алгоритм и вперёд)
При этом паблик ключ мож раздавать на право и на лево, алгоритм держать открытым — ломать даже нечего. А подобрать...
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, Рома Мик, Вы писали:
OV>Воспользуйся несеметричными алгоритмами шифрования (RSA к примеру). Палик ключ раздаёш всем, а приват — у тебя. Приватом шифруеш строку вида "05.12.2005 бла-бла-бла". На стороне клиента получить эту строку можно всегда, а вот сгенерировать практически нереально. (естественно за разумное время, но при условии, что не було допущено серёзных ошибок при реализации. Поэтому бери готовый алгоритм и вперёд) OV>При этом паблик ключ мож раздавать на право и на лево, алгоритм держать открытым — ломать даже нечего. А подобрать...
Хорошо, но тут не шифрованием надо заниматься а генерить пин коды, которые потом сохраняются в базу.
Здравствуйте, vip_delete, Вы писали:
_>Хорошо, но тут не шифрованием надо заниматься а генерить пин коды, которые потом сохраняются в базу.
А чем принципиально пин код отличается от хеша? Длиной? Набором символов? И почему в базу запмсать нельзя — хеш (по крайней мере для известных мне) можно перевести в строку, а её в базу — раз плюнуть
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, vip_delete, Вы писали:
_>>Хорошо, но тут не шифрованием надо заниматься а генерить пин коды, которые потом сохраняются в базу. OV> А чем принципиально пин код отличается от хеша? Длиной? Набором символов? И почему в базу запмсать нельзя — хеш (по крайней мере для известных мне) можно перевести в строку, а её в базу — раз плюнуть
брр...пин код можно считать хешем, его и надо записывать в базу.
Я говорил про то, что шифрование тут ни при чем, так как нам не надо раздавать паблик ключи клиентам (не ясно как их генерить), нам надо продавать им хеши.
Клиент покупает хеш (или пин код, что одно и тоже в нашем случае) вводит его где-то, на сервере по пин коду находится строчка в базе данных, в которой написаны параметры "карточки" (число денег, срок годности и тп.)
Смысл хеша в том, чтобы равномерно рассеить множество значений от данных.
Например (самый простой), у меня есть данные 1, 2, 3. применяю к ним функцию хеширования и получаю: 123, 546, 789 (пусть хеш от 0 до 1000). поэтому "угадать правильный хеш трудно", хотя я знаю, что исходных значений может быть всего 3 штуки.
Каждый месяц на сервере генерируются два ключа (rsa), валидные только один месяц, и хранящиеся на сервере.
на вход алгоритма генерации карточек подается следующие параметры, которые потом помещаются в базу:
1) номер карты (0001, 0002, ..., 000n) — инкрементный.
2) дата.
3) номинал.
1) Эта информация шифруется одним из ключей, что позволяет добится перемешивания. Выход этого этапа — первая часть пин кода.
2) По первая часть пин кода и второму ключу генерируется электронная подпись.
3) Складывая вместе получаем пин-код.
Этап оплаты:
1) Сравниваем полученную электронную подпись из второй части введенного пин кода с вычисленной на основе текущего (месячного ключа и первой части пин кода.
2) Расшифровываем первую часть пин кода для получения номера карты, даты, генерации и номинала.
3) Смотрим в базу для поиска карты по этим параметрам.
Минус, на мой взгляд, — первая и вторая часть пин кода должны быть одинаковой длинны, чтобы на сервере можно было выделить их из всего пин кода.
ключа и первой части пин кода.