Comments 57
Надеюсь, криптографические примитивы (ECC, SHA) вы реализовывали не самостоятельно.
Вот только повторное хеширование с солью выкините нафиг :) Достаточно будет, если вы сконкатенируете соль с паролем перед хешированием.
И, кстати, соль надо не вычислять, а брать из настроек сервера. Она должна быть уникальной для сервера, а не вычисляться.
Вот только повторное хеширование с солью выкините нафиг :) Достаточно будет, если вы сконкатенируете соль с паролем перед хешированием.
И, кстати, соль надо не вычислять, а брать из настроек сервера. Она должна быть уникальной для сервера, а не вычисляться.
> При регистрации юзера выдаем ему зашифрованный файлик с открытым\закрытым ключом и паролем от него. Себе оставляем только открытый ключ.
Т.е. ключи всё-таки проходят через сервера и их можно заполучить при взломе последнего. Более правильным решением будет генерация ключей на стороне пользователя с последующей сертификацией.
> Юзер копирует строку в специальную программу, которая по выданному паролю дешифрует закрытый ключ и подписывает нашу случайную строку.
Вот тут тоже полумера. Я понимаю одноразовые пароли, например на бумажке, которые нужно вводить в форму браузера — доступное решение… но если вы уже используете полноценное приложение — не лучше сразу сделать так, чтобы оно подписывало не случайную строку, а платёжный документ целиком: с реквизитами, временем и прочей требухой. Таким образом можно «математически» и юридически переложить ответственность на пользователя ибо только он может подписать, а мы ничего не знаем — ни паролей ни явок.
> не сможет потратить его деньги\сменить пароль\мыло\любые другие функции которые вы посчитаете нужным защитить с использованием этого метода.
Так вроде сработает in-the-middle-attack… перехватываем подписанную строку на сервере и меняем реквизиты по операции — и всё, БД это проглотит, а денюжки уйдут не туда :)
Т.е. ключи всё-таки проходят через сервера и их можно заполучить при взломе последнего. Более правильным решением будет генерация ключей на стороне пользователя с последующей сертификацией.
> Юзер копирует строку в специальную программу, которая по выданному паролю дешифрует закрытый ключ и подписывает нашу случайную строку.
Вот тут тоже полумера. Я понимаю одноразовые пароли, например на бумажке, которые нужно вводить в форму браузера — доступное решение… но если вы уже используете полноценное приложение — не лучше сразу сделать так, чтобы оно подписывало не случайную строку, а платёжный документ целиком: с реквизитами, временем и прочей требухой. Таким образом можно «математически» и юридически переложить ответственность на пользователя ибо только он может подписать, а мы ничего не знаем — ни паролей ни явок.
> не сможет потратить его деньги\сменить пароль\мыло\любые другие функции которые вы посчитаете нужным защитить с использованием этого метода.
Так вроде сработает in-the-middle-attack… перехватываем подписанную строку на сервере и меняем реквизиты по операции — и всё, БД это проглотит, а денюжки уйдут не туда :)
не сработает — операция уже сформированная лежит ждет подписи
Если описанная выше схема аутентификации полна, то работает это примерно так:
1. P-->U: r
2. U-->P: r, SU( r )
где r — случайное число, SU( r ) подписанное юзером число, P — payment system
Тогда возможна самая примитивная реализация MiM атаки:
1. P-->A: r
… A-->U: r, SU( r )
2. U-->A: r
… A-->P: r,SU( r )
Вуаля, теперь Adversary = User с точки зрения Payment system, м?
1. P-->U: r
2. U-->P: r, SU( r )
где r — случайное число, SU( r ) подписанное юзером число, P — payment system
Тогда возможна самая примитивная реализация MiM атаки:
1. P-->A: r
… A-->U: r, SU( r )
2. U-->A: r
… A-->P: r,SU( r )
Вуаля, теперь Adversary = User с точки зрения Payment system, м?
Эм… если случайное число привязано к платежному документу, то имхо единственный способ повлиять на операцию это mim в момент отправки неподписанной платежки на сервер. Тут вы правы, лучше подписывать весь документ (его хэш) целиком.
Тут, кстати, у меня маленькая ошибочка из-за неаккуратного копи-паста :) Должно быть так, разумеется:
1. P-->A: r
… A-->U: r
2. U-->A: r, SU( r )
… A-->P: r, SU( r )
1. P-->A: r
… A-->U: r
2. U-->A: r, SU( r )
… A-->P: r, SU( r )
Кстати, вебмани тоже сама выдает и генерирует клиентские сертификаты)
По-моему это не совсем так:
https://wiki.webmoney.ru/wiki/show/%D0%9F%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9+%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82
Идентификация обеспечивается путем применения закрытого ключа, который генерируется на компьютере пользователя в процессе регистрации, хранится только у владельца персонального цифрового сертификата WM Keeper Light и никогда не передается по сети.
https://wiki.webmoney.ru/wiki/show/%D0%9F%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9+%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82
Идентификация обеспечивается путем применения закрытого ключа, который генерируется на компьютере пользователя в процессе регистрации, хранится только у владельца персонального цифрового сертификата WM Keeper Light и никогда не передается по сети.
А зачем внешняя программа? Завтра придет человек с другой операционной системы — как он воспользуется сервисом?
Вообще это изобретение велосипеда.
Генерировать закрытый ключ должен только клиент, а не сервер чтобы избежать перехвата.
Тем более что браузер умеет генерировать приватный ключ, которым и надо подписывать все операции.
Генерировать закрытый ключ должен только клиент, а не сервер чтобы избежать перехвата.
Тем более что браузер умеет генерировать приватный ключ, которым и надо подписывать все операции.
Помоему в банках с СМС паролем гараздо удобнее.
Пользователь клиентской программы проверяет её подлинность тоже с помощью подписи? Можете рассказать об этом подробней? Например, какой используется сертификат (купленный VeriSign?) или свой.
Усложняется процедура платежа для конечного клиента — доп.софт постепенно вымирает, хотя и предлагает более защищенное решение.
Как-то запутано всё. По-русски говоря у юзера получается два «ключа» — то есть его пароль при регистрации и некий файлик, который он получает вместе с программкой. И дальше вы начинаете свистопляску с этими двумя «кодами»? Или я не прав?
По первой части статьи. Насколько я понимаю, там у вас две физические машины — то есть СКЛ-сервер, открытый только для процедур и веб-сервер, который управляет базой через процедуры?
Если так, то для меня (не профи) все не выглядит достаточно защищенным. Трафик в SQL запросах между машинами шифруется? Что мешает взломщику веб-сервера установить на нем прокси и дальше оперировать от имени юзера?
По первой части статьи. Насколько я понимаю, там у вас две физические машины — то есть СКЛ-сервер, открытый только для процедур и веб-сервер, который управляет базой через процедуры?
Если так, то для меня (не профи) все не выглядит достаточно защищенным. Трафик в SQL запросах между машинами шифруется? Что мешает взломщику веб-сервера установить на нем прокси и дальше оперировать от имени юзера?
Тот самый ключ в идеале и мешает. Сейчас (да и тогда) это можно было помимо ключа с програмкой организовать при помощи клиентских сертификатов.
Все равно не понимаю, простите, я дилетант в этом, но хочу разобраться.
Если злоумышленник получает контроль к серверу, то ему нужен не только пароль, но и ключ с компьютера клиента? Чтобы создать «транзакцию».
Что мешает взломавшему веб-сервер использовать существующие транзакции клиента (живые сессии), подменяя в них например платежные реквизиты (назначение) или сумму операции?
Если злоумышленник получает контроль к серверу, то ему нужен не только пароль, но и ключ с компьютера клиента? Чтобы создать «транзакцию».
Что мешает взломавшему веб-сервер использовать существующие транзакции клиента (живые сессии), подменяя в них например платежные реквизиты (назначение) или сумму операции?
По поводу шифрации SQL подскажите пожалуйста.
И еще сразу, пока вы не ответили. Если мы взломали веб-сервер, то есть фактически поставили свой веб-сервер (сайт) на место настоящего. Что мешает нам самим генерировать одноразовую строку? Где она создается — на компьютере с базой данной или на компьютере с веб-сервером?
Где вбиваются платежные реквизиты? Что мешает нам на сайте показывать юзеру одни платежные реквизиты, но заставлять его генерировать строчку под поддельные реквизиты? Другими словами, юзеру мы показываем 50 рублей, а в input формы у нас стоит 500 рублей, которые уходят на подпись в базу данных для временной строки? И мы юзеру даем подписать уже платеж на скрытые 500 рублей?
И еще сразу, пока вы не ответили. Если мы взломали веб-сервер, то есть фактически поставили свой веб-сервер (сайт) на место настоящего. Что мешает нам самим генерировать одноразовую строку? Где она создается — на компьютере с базой данной или на компьютере с веб-сервером?
Где вбиваются платежные реквизиты? Что мешает нам на сайте показывать юзеру одни платежные реквизиты, но заставлять его генерировать строчку под поддельные реквизиты? Другими словами, юзеру мы показываем 50 рублей, а в input формы у нас стоит 500 рублей, которые уходят на подпись в базу данных для временной строки? И мы юзеру даем подписать уже платеж на скрытые 500 рублей?
Одноразовая строка генерится хранимкой в БД, но это фиг с ним. Да, на самом деле выползает такая штука что можно подменить реквизиты платежа. Поэтому, как уже было замечено выше, лучше подписывать весь платежный документ (его хэш), а не одноразовую строку.
То есть вы признаете что я могу взломать вашу систему просто взломав WWW?
Вы — вряд ли)
Почему? Что меня остановит? Где подписывается строка? Какие поля есть у юзера в программе на компе?
строка подписывается на клиенте программой… Взломать единичную операцию да, можно, подменив данные документа в момент его формирования (и не факт что строку для него подпишут, кстати)и только в тот момент когда пользователь решит оплатить что либо. Да и к тому времени скорей всего дыры будут уже закрыты а хацкер изгнан с системы. Поменять подпись случайной строки на подпись хэша документа дело максимум часа
Я вижу две уязвимости по крайней мере. В любых сценариях. Вы не ответили по поводу шифрации команд SQL от ВВВ до базы данных.
«шифрация» sql команд тут не нужна(сервера друг с другом напрямую соединены) и не поможет при взломе веб сервера
Чем соединены? Машрутизатором, хабом, циской? Сетевая в сетевую?
сетевая в сетевую
Еще как-то друг друга видят? Если я отключу интерфейс на ВВВ и прокину маршрут через свой роутер, что произойдет?
Вы название статьи читали? Немножко не в ту тему мне кажется пишете
Почему не в ту? Вы описали двузвенную структуру и сказали что мне не хватит рута на WWW. Я же вижу, что мне хватит рута полностью и еще мне хватит врезаться между двумя серверами. Возможно я ошибаюсь, еще раз говорю, я не специалист в платежных системах, просто интересно.
если будет цифровая подпись документа то вам и двух рутов не хватит
Я вообще вижу что мне не нужен ни один ключ. Ни в базе, ни у пользователя. То есть достаточно подредактировать public_html.
ага, и бд, проверяющая ЭЦП, помахает вам ручкой, когда подпись оригинального документа(которую формирует на своем компе пользователь) не совпадет с подписью сформированного вами документа. Тут уж хоть вклинивайтесь хоть не вклинивайтесь. Учите матчасть.
В том и дело что я матчасть не знаю. Поэтому иду по простому пути. Я ставлю прокси на WWW и заставляю юзера подписывать фальшивые чеки. Вернее даю юзеру строчки от других чеков. А сам дальше работаю с базой. Что меня остановит кроме совести?
Юзер по определению видит что подписывает. В клиентской программе (мы уже рассматриваем вариант с подписью документа) отобразятся все поля, начиная от назначения платежа и заканчивая датой и суммой. Как их заполнять — дело техники, можно автоматом а можно и руками. Разве что при автоматическом заполнении он лишний нолик не заметит, но это уже его проблемы
Я смотрю вы обновили статью. Надо подумать. Давайте посмотрим. Я владею ВВВ. Создаю лживый чек с правильной суммой. Даю этот чек юзеру в программу. Что остановит юзера?
Если юзер не совсем дурак (примем это за точку отсчета), то он увидит, например, что платеж был на 50 рублей, а стал на 100, или платил он за пчелайн, а тут ему предлагается МТС, да еще и номер телефона левый. Конечно есть вероятность что он этого НЕ заметит, но если заметит то увы и ах, не видать вам его цифровой подписи без которой вы можете хоть удолбиться в сервер бд: Он ничего вам не даст
Тут довольно просто. Я ввожу в систему подставную фирму МТС (заменяя последнюю букву на Ц), и выписываю юзеру в его сессии лживый чек на свою фирму. Чек валидный, он для него им же создан. Что его остановит?
Вы не введете в систему подставную фирму МТС. У вас рут от веб сервера, а не от БД
Почему нет? Кто меня остановит? Я по-белому введу себя как получатель, в вашем офисе. Назову себя МТС Консалт. Мобильные теле-системы для малого бизнеса. Мобильный кошелек. Как угодно.
Безопасность строится не только в компьютере, но и вокруг него.
Безопасность строится не только в компьютере, но и вокруг него.
Уверяю вас, те, кто будут забивать название получателя денег в бд позаботятся о том, чтобы не было разночтений с существующими контрагентами. К тому же, если выяснится, что хакер работает на одного из наших контрагентов, за жопу возьмут обоих. У вас поинтереснее аргументы остались? Так то можно и со стволом в офис придти и заставить выдать все пароли от сервера. Тоже к компьютерной безопасности и криптографии это приписывать будете?
Да нифига они не позаботятся. Вообще я тут не беру фактическую ситуацию. По факту бы просто в течение часа слили все деньги на ИЧП и скрылись в неизвестном направлении. Вернее в направлении каких-нибудь южных морей.
попутного ветра!
Предлагаю остановить обсуждение на этой точке. Я не желаю вам зла и на самом деле ни являюсь ни хакером, ни специалистом в платежных системах.
Хотя в качестве рекламы могу сообщить, что я принимаю заказ на анализ чужих платежных систем, буквально вчера имел наглость составить такое коммерческое предложение. Смотрите мой профиль — кому интересно.
Хотя в качестве рекламы могу сообщить, что я принимаю заказ на анализ чужих платежных систем, буквально вчера имел наглость составить такое коммерческое предложение. Смотрите мой профиль — кому интересно.
По факту, для регистрации ИЧП вы 5 дней регистрировались в налоговой, после чего приходили в банк.
И вывод разовый БОЛЬШОЙ суммы денег без предупреждения банка событие маловероятное. Так что минимум на сутки Вас в банке остановят, а за это время ваши фотки будут уже легко лежать на всех пограничных терминалах..:)…
И вывод разовый БОЛЬШОЙ суммы денег без предупреждения банка событие маловероятное. Так что минимум на сутки Вас в банке остановят, а за это время ваши фотки будут уже легко лежать на всех пограничных терминалах..:)…
Сумма та же. 50 рублей.
Обсуждение взлома. Топик гадкий, но интересный.
habrahabr.ru/blogs/pay_sistem/96438/#comment_2953781
habrahabr.ru/blogs/pay_sistem/96438/#comment_2953781
Я не понимаю смысла вашего цикла статей, который описывает весьма кривую архитектуру, написанную вами 3 года назад, в комментариях которой на каждый указанный вам ляп архитектуры вы жалуетесь, что это придуманно 3 года назад.
Sign up to leave a comment.
Некоторые аспекты разработки платежных систем. Часть II. One time passwords и ECDSA