А вы предлагаете уже выявленные дыры в системе с реальными пользователями, находящейся в эксплуатации, держать открытыми до окончания конкурса (у которого только первый этап — 2,5 месяца, а, вообще, он бессрочный)?
Сам по себе классический DH и не может обеспечивать аутентификацию, потому в чистом виде подвержен MITM-у. Однако, разработчики, вроде, только для обмена ключами его используют, перекладывая аутентификацию на плечи пользователей, визуализируя общий ключ.
> все проверки-сертификации ведь снова провести нужно
Какие еще сертификации? И, по-вашему, надо было ждать чьего-то одобрения, чтобы перейти от уязвимосй модификации DH к классической схеме? У вас к последней есть какие-то претензии?
Зачем правительству подделывать сообщения других других людей, если проще придти в ним домой с предложением, от которого нельзя отказаться (сшитое дело с возможностью получить условный срок вместо реального)?
Когда есть мощный аппарат принуждения, подделывать мало что требуется.
Потому что в надежности цифровой подписи получатель заинтересован в большей степени, что отправитель. Почти нет таких случаев, когда правительство хотело бы, чтобы авторство сообщения, подписанного по разработанному правительством алгоритму, осталось под сомнением.
>Я в 16 лет думал, что XOR по ключу дает полностью равномерный «белый шум» и очень радовался
Белый, не белый, но «XOR по ключу» является невзламываемым способом шифрования, если размер ключа не меньше размера шифруемых данных, сам ключ сгенерирован случайным образом и не используется для шифрования других данных. :)
> В чём идея то? Если в том, чтобы пользователь не пытался запомнить
Нет, идея в том, чтобы никто не мог запомнить, включая того, кто смотрит на экран через плечо. чтобы аутентифицироваться можно было лишь ОБЛАДАЯ ключевым файлом. Очевидно, что хэш или base64 от пароля для этого не годится.
> Вот так новость
«Шифрование» секретным ключем называется электронной подписью и в принципе не может помочь скрыть информацию от посторонних, потому что «зашифрованная» информация расшифровывается открытым ключем. ОТКРЫТЫМ.
> Но объясните мне, как это снижает безопасность то и чем повышает сложность?
Так, что вы пытаетесь использовать в качестве фактора «то, чем обладает пользователь» производную от пароля, тем самым смешивая этот фактор с фактором «то, что пользователь знает», что защищенность, как минимум, не увеличивает.
> В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Нафиг такие «средства защиты», которые обеспечивают удобство вместо безопасности. Пароль «123» себе поставьте, очень удобно будет, обещаю вам.
Скрыть от кого? От трояна на клиентском хосте? Он и так сможет до ключа добраться без необходимости разбирать картинки, пересылаемые по сети. От человека посередине? Он просто сравнить посланную и принятую вами картинку. От скомпрометированного удаленного сервера? Да вы же аутентифицируетесь на нем!
> Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе
Как вам поможет второй фактор в виде ключевого файла, если он передается вместе с паролем, избежать успешной MITM-атаки? Аутенификация по сертификатам или OTP-генератор еще бы как-то решили проблему, но голый ключевой файл — нет.
> не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
Если флешка дома под замком, то так вы собираетесь использовать ключи с нее?
Задача сокрытия у пользователя ключа решается очень просто — не аутентифицироваться по фактору «то, что есть у пользователя», а использовать лишь пароль, хранимый только в голове.
> Если удалить оригинальный файл, то, чтобы доказать наличие авторизационного файла у пользователя придется перебрать все картинки.
Удалить откуда? Клиентское устройство все равно должно обладать ключем в каком-то виде, иначе оно не сможет использовать фактор «то, чем пользователь обладает», а сервер вообще аутентифицирует клиента и априори должен мочь сопоставить пользователя с его ключем в любое время. Если же мы считаем, что передаваемые данные не могут попасть к злоумышленнику, тогда от кого скрываем в них ключ с помощью стеганографии? Я не понимаю, от каких угроз вы предлагаете защищаться с ее помощью.
> Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо
говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
Так для двухфакторной аутентификации или для «повышения привилегий»? И как использование картинок в качестве транспорта для ключа усложняет его подбор?
Разные факторы лучше комбинировать, а не использовать в качестве альтернативы. Если планируется аутентифицировать пользователя только по одному из факторов, то проще оставить пароль и не придумывать велосипеды.
Секретным ключем можно только расшифровывать и подписывать информацию.
>Но заводить под это отдельную таблицу в БД?
Колонку
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»? И в многофакторной аутентификации факторы не должны зависеть друг от друга.
Затем, что пароль НЕЛЬЗЯ хранить нигде, кроме головы, иначе он начинает выступать одновременно в качестве факторов «известное пользователю» и «обладаемое пользователем». Содержимосе ключевого файла должно быть случайным и незапоминаемым.
Посмотрите, как сделана работа с ключевыми файлами в truecrypt и LUKS.
Из брокеров я сам работал только rabbitmq, потому с уверенностью ничего посоветовать не могу.
Я знаю, что есть еще другие реализации amqp-брокеров, но они медленнее, чем rabbitmq, при использовании persistent очередей. Возможно, как раз за счет строгого соблюдения консистентности, но это лишь моя догадка.
Суть в использовании фактора «то, что пользователь имеет» вместо «то, что пользователь знает». Конечно, выглядит велосипеднее, чем client certificate auth, но с другой стороны проще в управлении на сервере и использовании пользователями.
В плане же устойчивости в MITM ничем не хуже использования пароля.
> Пользователь регистрируется, закачивает на сервер картинку, а после — скачивает себе на компьютер эту же картинку, но с зашитым ключом.
И в чем смысл такой «защиты», если банальным сравнением обоих файлов злоумышленник не только заметит факт передачи (т.е. задача стеганограии не выполняется), но и получит сам ключ?!
Какие еще сертификации? И, по-вашему, надо было ждать чьего-то одобрения, чтобы перейти от уязвимосй модификации DH к классической схеме? У вас к последней есть какие-то претензии?
Когда есть мощный аппарат принуждения, подделывать мало что требуется.
Белый, не белый, но «XOR по ключу» является невзламываемым способом шифрования, если размер ключа не меньше размера шифруемых данных, сам ключ сгенерирован случайным образом и не используется для шифрования других данных. :)
Ноутбуки в мейлру не выдают?
Нет, идея в том, чтобы никто не мог запомнить, включая того, кто смотрит на экран через плечо. чтобы аутентифицироваться можно было лишь ОБЛАДАЯ ключевым файлом. Очевидно, что хэш или base64 от пароля для этого не годится.
> Вот так новость
«Шифрование» секретным ключем называется электронной подписью и в принципе не может помочь скрыть информацию от посторонних, потому что «зашифрованная» информация расшифровывается открытым ключем. ОТКРЫТЫМ.
> Но объясните мне, как это снижает безопасность то и чем повышает сложность?
Так, что вы пытаетесь использовать в качестве фактора «то, чем обладает пользователь» производную от пароля, тем самым смешивая этот фактор с фактором «то, что пользователь знает», что защищенность, как минимум, не увеличивает.
> В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Нафиг такие «средства защиты», которые обеспечивают удобство вместо безопасности. Пароль «123» себе поставьте, очень удобно будет, обещаю вам.
Скрыть от кого? От трояна на клиентском хосте? Он и так сможет до ключа добраться без необходимости разбирать картинки, пересылаемые по сети. От человека посередине? Он просто сравнить посланную и принятую вами картинку. От скомпрометированного удаленного сервера? Да вы же аутентифицируетесь на нем!
> Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе
Как вам поможет второй фактор в виде ключевого файла, если он передается вместе с паролем, избежать успешной MITM-атаки? Аутенификация по сертификатам или OTP-генератор еще бы как-то решили проблему, но голый ключевой файл — нет.
> не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
Если флешка дома под замком, то так вы собираетесь использовать ключи с нее?
Задача сокрытия у пользователя ключа решается очень просто — не аутентифицироваться по фактору «то, что есть у пользователя», а использовать лишь пароль, хранимый только в голове.
Удалить откуда? Клиентское устройство все равно должно обладать ключем в каком-то виде, иначе оно не сможет использовать фактор «то, чем пользователь обладает», а сервер вообще аутентифицирует клиента и априори должен мочь сопоставить пользователя с его ключем в любое время. Если же мы считаем, что передаваемые данные не могут попасть к злоумышленнику, тогда от кого скрываем в них ключ с помощью стеганографии? Я не понимаю, от каких угроз вы предлагаете защищаться с ее помощью.
> Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо
говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
Так для двухфакторной аутентификации или для «повышения привилегий»? И как использование картинок в качестве транспорта для ключа усложняет его подбор?
>base64(login:password)
>login:md5(password)
Да вы издеваетесь что ли?
>зашифрованное с помощью секретного ключа rsa
Секретным ключем можно только расшифровывать и подписывать информацию.
>Но заводить под это отдельную таблицу в БД?
Колонку
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»? И в многофакторной аутентификации факторы не должны зависеть друг от друга.
Посмотрите, как сделана работа с ключевыми файлами в truecrypt и LUKS.
Я знаю, что есть еще другие реализации amqp-брокеров, но они медленнее, чем rabbitmq, при использовании persistent очередей. Возможно, как раз за счет строгого соблюдения консистентности, но это лишь моя догадка.
В плане же устойчивости в MITM ничем не хуже использования пароля.
И в чем смысл такой «защиты», если банальным сравнением обоих файлов злоумышленник не только заметит факт передачи (т.е. задача стеганограии не выполняется), но и получит сам ключ?!
Security theater такой security theater.