Из политики конфиденциальности по ссылке
1.1. Сервис собирает, получает доступ и использует в определенных Политикой целях техническую и иную информацию, связанную с Пользователем.
ст. 3 152-ФЗ «О перс. данных»
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Вывод, если пользователь физ. лицо, сервис обрабатывает перс. данные.
Коллеги, прошу не понять меня неправильно. Я интересуюсь безопасностью IoT с профессиональной точки зрения и не в коем случае не хочу критиковать вашу разработку. Но…
ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен,
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
Ключи создаются случайным образом.
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
Здраствуйте. Подскажите, может я просмотрел, а как по факту работает шифрование?
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
При внедрении SDL компания, сформирует что-то типа политики написания программного кода / разработки ПО.
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
В свое время на уроке физики нам как-то рассказывали, что однажды спросили у ученых —
«Если будет потерянны все знания из физики, но будет возможность сохранить только одну теорию. что бы вы сохранили?» Ответ был — «Молекулярно-кинетическую теорию газов».
Интересно, какая информация считается важной в данном случае?
Смогут ли люди, например четвертое или пятое поколение выживших после апокалипсиса воспользоваться этой информацией? Если вспомнить историю, то например аборигены (или другие дикари) не умели смотреть фотографии.
И еще, послание инопланетянам на Вояджере было на золотой пластине, может от пленок лучше уйти к золоту?
Если только некий id, тогда непонятно причем тут ограничения на 4кб в куку, если же в сессии присутствует состояние полное состояние клиента, то для того чтобы его нехранить на сервере его надо шифровать и оно должно шифроваться на клиенте.
Спасибо за статью идея интересная но есть пару проблемных моментов.
1. HMAC — это не электронная подпись. Поскольку строится на базе симметричного ключа и соответственно может быть подделана одной стороной без возможности это опровергнуть другой стороной. Классическая ЭП на ассиметричной криптографии этого не допускает, поскольку ЭП строится с помощью закрытого ключа который есть только у подписывающей стороны.
2. В приведенных вами исходниках ключ шифрования вшит в код, а с учетом того, то шифрование должно осуществляться на стороне клиента этот ключ может быть перехвачен третьей стороной и после чего данные будут подделаны.
Пример. Вася подключается в Web-клиенту Банка. К нему грузятся скрипты, содержащие ключ шифрования.
Вася отключается, но ключ у него есть. Вася знает что у Зины на счету много денег. Он от имени Зины строит сессию (ему даже авторизовываться не надо) и совершает перевод.
3. Вы скорее всего скажите, что сессия будет защищена TLS. Но раз так, тогда смысла в доп. шифровании нет.
Для исправления ситуации необходимо как минимум для каждой сессии получать рандомный ключ шифрования. Но даже это не защитит от атак повтором. Поэтому нужно капать в сторону использования ассиметричной крипты.
Перед столкновением частицы разгоняют до скоростей как можно более близким к скоростям света, но все таки, когда они сталкиваются друг об друга их скорость друг относительно друга больше скорости света или нет?
Кто в теме скажите, вот разгоняют два протона и бьют друг об друга, потом смотрят что с осколками, а есть ли эксперименты над битьем осколков друг об друга?
Еще вопрос, правда очень тяжело его сформулировать.
Все эксперименты упираются в поиск частиц. Есть ли эксперименты по поиску не частиц, а чего то другого?
Насколько я понимаю считается что частица может существовать везде, но так ли это? Нет ли такого своеобразного океана где могут существовать частицы и чего-то другого где они существовать не могут?
C бозоном Хиггса непонятно, обнаружили его в итоге или нет?
То что вы описываете очень далеко от реальных банковских проблем (бизнеса). Самое интересно это будет внутри — взаимодействие с клиентами.
Выдать кредит хоть по скорингу хоть через аналитика это легко. Вот блокчейн коллекшн (выбивание долгов) вот это тема.
Другой интересный вопрос — как бороться с человеческой глупостью в части утери криптоключей?
В битконе потерял приватный ключ — все наигрался. В обычных клиент-банках это происходит относительно часто.
Ну как говорится респект и уважуха в вашем начинании. Буду ждать следующих серий ваших приключений.
P.S. Про современные технологии. Был опыт внедрения IVR-решения для персонализации пластиковых карт. 30% клиентов — лиц пожилого возраста (основные вкладчики любого банка) не могли набрать на телефоне T-CODE…
Криптовалюта, криптостартап — инструменты направленные на скрытие данных о владельце счетов или компании.
Не совсем понятно, если вы будете пользоваться этим, то как вы будете дружить с FATF, как сдавать отчетность в США по FATCA?
Если же вы идентифицируете владельца, то не о каком крипто не может быть и речи. Просто используете существующие блокчейн решения.
Хотеть купит дешевле, а продать дороже это нормальная ситуация в рыночной экономике.
Судя по статье вы описываете ценовой конфликт с одним из клиентов. Называете его среднюю сумму чека, оборот и т. д., причем делаете без ссылки на раскрывающие данные предоставленные самой компанией. Если это не ваш клиент, значит у вас есть инсайд. Погуглив я такой информации не нашел.
Конечно считать чужие деньги всегда интересно, но делать это публично, мягко говоря не этично, а делать это в отношение клиента…
Коллеги, сори за офтоп, но не удержался. SAP HANA на мой взгляд не самая удачное название для России, у меня почему то все оно превращаться в «Хана сапу», то есть все нет больше сапа.
Хотел уточнить следующие моменты:
1. Как хранится (где и сколько времени) статистика по доступу пользователей в Инет? Какая есть аналитика?
2. Packet Capture с какой скоростью может писать? Какой максимальный размер захвата и в каком формате хранятся данные?
3. Можно ли повесить сертификат (настроить TLS) на страницу аутентификации пользователей? Золотое правило безопасности гласит, что любая аутентификационная информация должна передаваться по защищенному каналу (а не по голому HTTP).
4. Поддерживается ли аутентификация пользователей по сертификатам (smart cards)?
Когда мы оцениваем качество работы автопилотов, то мы сравниваем их с профессиональными водителями, которые водят машины всю жизнь и убеждаемся, что человек все-таки лучше.
Но если сравнить автопилот с новичком, который только получил / купил права, но который уже имеет право перевозить людей, результат подобного сравнения скорее всего изменится диаметрально противоположно.
С точки зрения дизайна в чем проблема добавить round-trip?
На сколько я понимаю, авторизация происходит один раз, при установки сессии при этом если у вас будут 2 пакета или 10 пользователь разницы не заметит.
Конечно можно предположить что плохо написанный софт будет строить и рвать сессию на каждом SQL-операторе, но и в этом случае изменение количества пакетов используемых для авторизации вряд ли существенно исправить ситуацию с быстродействием.
С другой стороны, помогая «криворуким» программистам вы закладываете в систему проблемы безопасности которые отразятся на всех пользователях.
На практике, проводя аудит безопасности систем, когда открываешь табличку с паролями пользователей и видишь что у половины из них одинаковые коды паролей (хэши) испытываешь смешанные чувства… причем, для самого распространённого пароля — «1» можно даже визуально запомнить хэш.
Хочу отметить, что взлом через радужные таблицы это все таки не brute force.
Радужные таблицы mixaplhanumeric1-12 дадут злоумышленикам очень хорошие результаты по взлому любых систем построенных по аналогичной схеме вообще. Причем атака будет проводиться практически в режиме реального времени и для этого могут использоваться облачные сервисы, фактически похачить можно с мобильника.
Фишинговые домены построенные на базе typosquatting это атака на клиентов. Причем у них вообще может не быть каких-либо инструментов защиты, единственной действенной защитой в данном случае будет только их оперативное разделегирование фишинговых доменов. Просить клиентов использовать Cisco OpenDNS в качестве DNS серверов кажеться мало перспективным. Поправите пожалуйста если я ошибаюсь.
Функционал упомянутый в статье есть также в Bot-Treck intellegence от Group-IB, но там возможности больше, они также ищут фишинг по использованию фирменных логотипов и др.
Расскажите пожалуйста в чем преимущества описанного выше решения от Cisco от аналогичных решений ваших конкурентов и кого вы рассматриваете в качестве основных конкурентов.
Из политики конфиденциальности по ссылке
1.1. Сервис собирает, получает доступ и использует в определенных Политикой целях техническую и иную информацию, связанную с Пользователем.
ст. 3 152-ФЗ «О перс. данных»
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Вывод, если пользователь физ. лицо, сервис обрабатывает перс. данные.
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
«Если будет потерянны все знания из физики, но будет возможность сохранить только одну теорию. что бы вы сохранили?» Ответ был — «Молекулярно-кинетическую теорию газов».
Интересно, какая информация считается важной в данном случае?
Смогут ли люди, например четвертое или пятое поколение выживших после апокалипсиса воспользоваться этой информацией? Если вспомнить историю, то например аборигены (или другие дикари) не умели смотреть фотографии.
И еще, послание инопланетянам на Вояджере было на золотой пластине, может от пленок лучше уйти к золоту?
Если только некий id, тогда непонятно причем тут ограничения на 4кб в куку, если же в сессии присутствует состояние полное состояние клиента, то для того чтобы его нехранить на сервере его надо шифровать и оно должно шифроваться на клиенте.
В статье схемы взаимодействия не хватает.
1. HMAC — это не электронная подпись. Поскольку строится на базе симметричного ключа и соответственно может быть подделана одной стороной без возможности это опровергнуть другой стороной. Классическая ЭП на ассиметричной криптографии этого не допускает, поскольку ЭП строится с помощью закрытого ключа который есть только у подписывающей стороны.
2. В приведенных вами исходниках ключ шифрования вшит в код, а с учетом того, то шифрование должно осуществляться на стороне клиента этот ключ может быть перехвачен третьей стороной и после чего данные будут подделаны.
Пример. Вася подключается в Web-клиенту Банка. К нему грузятся скрипты, содержащие ключ шифрования.
Вася отключается, но ключ у него есть. Вася знает что у Зины на счету много денег. Он от имени Зины строит сессию (ему даже авторизовываться не надо) и совершает перевод.
3. Вы скорее всего скажите, что сессия будет защищена TLS. Но раз так, тогда смысла в доп. шифровании нет.
Для исправления ситуации необходимо как минимум для каждой сессии получать рандомный ключ шифрования. Но даже это не защитит от атак повтором. Поэтому нужно капать в сторону использования ассиметричной крипты.
Еще вопрос, правда очень тяжело его сформулировать.
Все эксперименты упираются в поиск частиц. Есть ли эксперименты по поиску не частиц, а чего то другого?
Насколько я понимаю считается что частица может существовать везде, но так ли это? Нет ли такого своеобразного океана где могут существовать частицы и чего-то другого где они существовать не могут?
C бозоном Хиггса непонятно, обнаружили его в итоге или нет?
Выдать кредит хоть по скорингу хоть через аналитика это легко. Вот блокчейн коллекшн (выбивание долгов) вот это тема.
Другой интересный вопрос — как бороться с человеческой глупостью в части утери криптоключей?
В битконе потерял приватный ключ — все наигрался. В обычных клиент-банках это происходит относительно часто.
Ну как говорится респект и уважуха в вашем начинании. Буду ждать следующих серий ваших приключений.
P.S. Про современные технологии. Был опыт внедрения IVR-решения для персонализации пластиковых карт. 30% клиентов — лиц пожилого возраста (основные вкладчики любого банка) не могли набрать на телефоне T-CODE…
Не совсем понятно, если вы будете пользоваться этим, то как вы будете дружить с FATF, как сдавать отчетность в США по FATCA?
Если же вы идентифицируете владельца, то не о каком крипто не может быть и речи. Просто используете существующие блокчейн решения.
Судя по статье вы описываете ценовой конфликт с одним из клиентов. Называете его среднюю сумму чека, оборот и т. д., причем делаете без ссылки на раскрывающие данные предоставленные самой компанией. Если это не ваш клиент, значит у вас есть инсайд. Погуглив я такой информации не нашел.
Конечно считать чужие деньги всегда интересно, но делать это публично, мягко говоря не этично, а делать это в отношение клиента…
А в целом решение и статья интересные.
Хотел уточнить следующие моменты:
1. Как хранится (где и сколько времени) статистика по доступу пользователей в Инет? Какая есть аналитика?
2. Packet Capture с какой скоростью может писать? Какой максимальный размер захвата и в каком формате хранятся данные?
3. Можно ли повесить сертификат (настроить TLS) на страницу аутентификации пользователей? Золотое правило безопасности гласит, что любая аутентификационная информация должна передаваться по защищенному каналу (а не по голому HTTP).
4. Поддерживается ли аутентификация пользователей по сертификатам (smart cards)?
Но если сравнить автопилот с новичком, который только получил / купил права, но который уже имеет право перевозить людей, результат подобного сравнения скорее всего изменится диаметрально противоположно.
На сколько я понимаю, авторизация происходит один раз, при установки сессии при этом если у вас будут 2 пакета или 10 пользователь разницы не заметит.
Конечно можно предположить что плохо написанный софт будет строить и рвать сессию на каждом SQL-операторе, но и в этом случае изменение количества пакетов используемых для авторизации вряд ли существенно исправить ситуацию с быстродействием.
С другой стороны, помогая «криворуким» программистам вы закладываете в систему проблемы безопасности которые отразятся на всех пользователях.
На практике, проводя аудит безопасности систем, когда открываешь табличку с паролями пользователей и видишь что у половины из них одинаковые коды паролей (хэши) испытываешь смешанные чувства… причем, для самого распространённого пароля — «1» можно даже визуально запомнить хэш.
Хочу отметить, что взлом через радужные таблицы это все таки не brute force.
Радужные таблицы mixaplhanumeric1-12 дадут злоумышленикам очень хорошие результаты по взлому любых систем построенных по аналогичной схеме вообще. Причем атака будет проводиться практически в режиме реального времени и для этого могут использоваться облачные сервисы, фактически похачить можно с мобильника.
Функционал упомянутый в статье есть также в Bot-Treck intellegence от Group-IB, но там возможности больше, они также ищут фишинг по использованию фирменных логотипов и др.
Расскажите пожалуйста в чем преимущества описанного выше решения от Cisco от аналогичных решений ваших конкурентов и кого вы рассматриваете в качестве основных конкурентов.