Удивительно, но ни в этой статье, ни в других на русском языке не нашел ничего о том, как создавать свои .browser-файлы. Именно по этому написал в блог.
Еще одна фишка, о которой мало инфы — указание мастер-пейджа с привязкой к браузеру в заголовке страницы. Об этом не нашел упоминания даже на MSDN.
Здесь mdbf.codeplex.com можно скачать .browser-файл, который содержит определения практически всех мобильных браузеров. Я хотел лишь определить те браузеры, которые достоверно не являются мобильными. Хотябы самые популярные. Видимо нужно определять по операционной системе в UserAgent: оставить Windows NT, Linux, FreeBSD.
Недавно была горячая тема на rsdn: однин чел. лишился всей зарплаты и премии. Несанкцианированно сделали дубликат его карты (специальным устройством) и увели все через банкоматы в несколько заходов. Банк ничего не возместил. А если бы возмещал, то мошенники давно бы этим пользовались: можно продать дамп карты кардеру из другой страны за 80% стоимости, тот снимает все деньги, а банк возмещает убытки. В итоге 80% прибыли на пустом месте…
Смотря что вы подразумеваете под серьезным банком. Если государственный — возможно, там свои законы. Если коммерческие, то запросто:
1. Райффайзен-банк в Украине предлагает прямое пополнение кошелька WebMoney в онлайн-кабинете клиента.
2. WebMoney можно пополнить через систему НСМЭП, которая создана по проекту НБУ (Нац. банк Украины) через Имэксбанк.
На WebMoney сейчас больше всего грязи льют, т.к. они лидеры. На более мелких, типа Яндекс-денег, мало кто обращает внимание. Хотя Яндекс — лидер в поиске, с манями у них дела обстоят куда хуже…
Вообще-то карты Visa/MC не создавались для расчетов в сети и не обладают достаточной защищенностью для этого. Именно для этого и придумывают процессинговые центры, типа PayPal или LiqPay (украинский, новоиспеченный). На эти центры должны (1) проверить клиента своим способом (как то тестовый платеж с кодом у PayPal или звонок клиенту у LiqPay), (2) идентифицировать клиента каждый раз, когда он совершает платеж (своим способом).
А не легче ли изменить саму систему расчетов: обезопасить ее. Одной из попыток на Ураине была НСМЭП (кстати, использую). В РФ что-то подобное тоже было. Да и сама система Visa по слухам работает над этой проблемой. Но это только в планах…
Еще интересный момент. Не знаю как в России, но в Украине есть закон, который запрещает гражданам, постоянно проживающим на территории страны, иметь счет в иностранном банке. Штраф за нарушение весьма отрезвляющий. Хотя, никогда не слышал, чтоб кого-то за это привлекали.
Скорее всего PayPal не может работать с Росиией и Украиной именно из-за нашей законодательной базы. Кардеры все-равно найдут как грязь вывести.
А как выдавать буквы в случайном порядке? Иметь несколько таких таблиц, или генерировать каждую таблицу динамически?
Если несколько таблиц — то бот должен знать каждую из них. Если генерировать динамически — то не проще ли весь рисунок генерироать динамически?
И вообще, мне не очень нравится вводить буквы/цифры. Лучше использовать какую-нибудь красивую картинку, на которой нужно выбрать предметы или еще чего. Только вот как бы сделать это надежным?
Вы верно уловили суть. Алгоритм подходит только для тех случаев, когда сложно заполучить несколько вариантов подписи (серийник обычно выдается один, второй достать сложно). Практически имеет смысл применить этот алгоритм, если программу используют не более 100-500 тыс. человек.
По поводу replay атак. Для серийников это не так страшно. Обычно подписывают информацию в строгом формате: к примеру, срок использования в месяцах (1 байт) + привязка к железу (4 байта). Т.е. мусор там вставить некуда.
Идея в том, чтобы даже теоретически невозможно было проверить подпись быстрее, чем за x секунд процессорного времени (на средней машине).
Вот сколько на средней машине займет 1 млн. нахождений хеша от хеша?
Хотя, мне вот недавно сообщили, что циклическое получение хешей (т.е. хеш от хеша много раз подряд) — теоретически можно упростить. Насколько это просто и можно ли что-нибуль придумать, чтобы упрощение стало невозможным — пока не могу сказать.
RSA — старый и надежный. И хотя современная криптография активно пропагандирует алгоритмы на эллиптических кривых — RSA позиции не охотно уступает.
Единственная проблема в отношении генерации серийных номеров с RSA — попись (и серийный номер) получается длинной.
Предложенный мной алгоритм — абсолютно не претендует на роль аналога RSA. А вот для генерации серийников для простых программ (с десятками тысяч пользователей) — вполне подойдет.
Имхо, у этих гигантов свой подход к бизнесу: сначала их пользователи юзают версию незаконно, привыкают к ней, потом этих пользователей подталкивают (всяческими методами) использовать продукт легально.
Закрытый ключ в этом алгоритме — это массив случайно сгенерированных чисел. Этот массив условно разбивается на группы по 5 байт. Находится хеш каждой группы (для усложнения находится и хеш от хеша несколько сотен тысяч раз). Эти хеши образуют открытый ключ (их можно укоротить для экономии места на диске).
Подпись закрытым ключем делается так:
Находится хеш исходного сообщения. Берем 3 первых байта этого хеша, и находим в ЗАКРЫТОМ ключе элемент (из 5-ти байт) с таким порядковым номером. Если получилось число большее, чем всего есть элементов — используем остаток от деления.
Проверка подписи открытым ключем так:
Находится хеш исходного сообщения. Берем 3 первых байта этого хеша, и находим в ОТКРЫТОМ ключе элемент с таким порядковым номером. Если хеш подписи равен этому элементу открытого ключа — значит подпись верна. Иначе — подпись не верна.
Надеюсь не слишком запутано. Для большей ясности можно посмотреть пример (есть только на C#).
Еще одна фишка, о которой мало инфы — указание мастер-пейджа с привязкой к браузеру в заголовке страницы. Об этом не нашел упоминания даже на MSDN.
1. Райффайзен-банк в Украине предлагает прямое пополнение кошелька WebMoney в онлайн-кабинете клиента.
2. WebMoney можно пополнить через систему НСМЭП, которая создана по проекту НБУ (Нац. банк Украины) через Имэксбанк.
На WebMoney сейчас больше всего грязи льют, т.к. они лидеры. На более мелких, типа Яндекс-денег, мало кто обращает внимание. Хотя Яндекс — лидер в поиске, с манями у них дела обстоят куда хуже…
А не легче ли изменить саму систему расчетов: обезопасить ее. Одной из попыток на Ураине была НСМЭП (кстати, использую). В РФ что-то подобное тоже было. Да и сама система Visa по слухам работает над этой проблемой. Но это только в планах…
Скорее всего PayPal не может работать с Росиией и Украиной именно из-за нашей законодательной базы. Кардеры все-равно найдут как грязь вывести.
Если несколько таблиц — то бот должен знать каждую из них. Если генерировать динамически — то не проще ли весь рисунок генерироать динамически?
И вообще, мне не очень нравится вводить буквы/цифры. Лучше использовать какую-нибудь красивую картинку, на которой нужно выбрать предметы или еще чего. Только вот как бы сделать это надежным?
Если на клиенте, то эта капча только против людей, боты ведь не обязаны Javascript исполнять.
А если на сервере, то всего-навсего нужно прочитать background-position и вычислить букву.
Чем это лучше обычного способа генерации картинки — пока не ясно.
По поводу replay атак. Для серийников это не так страшно. Обычно подписывают информацию в строгом формате: к примеру, срок использования в месяцах (1 байт) + привязка к железу (4 байта). Т.е. мусор там вставить некуда.
Вот сколько на средней машине займет 1 млн. нахождений хеша от хеша?
Хотя, мне вот недавно сообщили, что циклическое получение хешей (т.е. хеш от хеша много раз подряд) — теоретически можно упростить. Насколько это просто и можно ли что-нибуль придумать, чтобы упрощение стало невозможным — пока не могу сказать.
Единственная проблема в отношении генерации серийных номеров с RSA — попись (и серийный номер) получается длинной.
Предложенный мной алгоритм — абсолютно не претендует на роль аналога RSA. А вот для генерации серийников для простых программ (с десятками тысяч пользователей) — вполне подойдет.
Закрытый ключ в этом алгоритме — это массив случайно сгенерированных чисел. Этот массив условно разбивается на группы по 5 байт. Находится хеш каждой группы (для усложнения находится и хеш от хеша несколько сотен тысяч раз). Эти хеши образуют открытый ключ (их можно укоротить для экономии места на диске).
Подпись закрытым ключем делается так:
Находится хеш исходного сообщения. Берем 3 первых байта этого хеша, и находим в ЗАКРЫТОМ ключе элемент (из 5-ти байт) с таким порядковым номером. Если получилось число большее, чем всего есть элементов — используем остаток от деления.
Проверка подписи открытым ключем так:
Находится хеш исходного сообщения. Берем 3 первых байта этого хеша, и находим в ОТКРЫТОМ ключе элемент с таким порядковым номером. Если хеш подписи равен этому элементу открытого ключа — значит подпись верна. Иначе — подпись не верна.
Надеюсь не слишком запутано. Для большей ясности можно посмотреть пример (есть только на C#).