Предотвращение MITM нападает на сервере

Получив сертификат Боба, подписанный доверенной третьей стороной (Verisign, ваша корпорация, сеть доверие и т. д.), или попросив Боба послать свой сертификат Алисе по отдельному безопасному пути вне диапазона (например, передать ей USB-ключ лично).

И то, и другое раскрывает суть того, что должен означать сертификат Боба. Вы доверяете тому, что сертификат Боба является сертификатом Боба, только потому, что его сертифицировал кто-то, кому вы доверяете. Этим «кем-то» может быть сам Боб или доверенная третья сторона, подписывающая сертификат Боба. Вы можете доверять этому только настолько, насколько доверяете органу по сертификации.

Пока вы не контролируете сервер, вы не можете. Если, конечно, вы уже не знаете открытый ключ Боба, но тогда ..... Я думаю, что здесь вы столкнулись с проблемой курицы и яйца.

Старайтесь сосредоточиться на коротких циклах доставки, т.е. заставляйте себя доставлять что-то осязаемое и полезное пользователям каждые несколько недель или месяцев. Определение приоритетов задач на основе их ценности для клиента. Таким образом у вас всегда есть удобное, функциональное приложение с довольными пользователями, в то время как под капотом вы можете переформатировать архитектуру небольшими шагами, если хотите (и если вы можете обосновать необходимость в нем - то есть в сторону руководства/клиентов, а не только товарищей по команде!).

Это очень помогает, если у вас есть стабильный процесс сборки с хорошим номером люкс автоматических (блок/интеграция) тестов.

Быстрые методы разработки, такие как Scrum , делают это, и они тепло рекомендуются. Но конечно не всегда легко или даже возможно адаптировать такой метод в своей команде. Даже если вы не можете, вы все равно можете взять его элементы и применить его к выгоде вашего проекта (возможно, даже без упоминания слов «agile» или «Scrum» публично; -)

Nettuts имеет отличное учебное пособие для формы CodeIgniter for Login. Следуйте заставке, и она прояснит ваши вопросы.

http://net.tutsplus.com/videos/screencasts/codeigniter-from-scratch-day-6-login/

В криптографии вы - то, что знаете. Если вы хотите избежать MITM, то Алиса должна иметь представление о том, кто такой «Боб», что означает, что Боб должен знать какой-то элемент данных, который не знает атакующий. Здесь ваш злоумышленник является сервером, который идеально расположен для установки атаки.

Итак, вопрос в том, кто такой Боб? Как сервер «не-Боб»?

Например, «Боб» может быть определен как: «Боб - это человек, у которого есть водительское удостоверение с написанным на нём» Бобом «». Или: «Боб - тот парень, с которым я познакомился в баре и выпил пиво».

Использование асимметричной криптографии позволяет свести проблему к вопросу доверия к открытому ключу. Элис будет использовать то, что она считает открытым ключом Боба. Поэтому Алисе нужен только какой-то способ убедиться, что открытый ключ, который у нее есть, действительно принадлежит Бобу. Владение открытым ключом определяется контролем соответствующего закрытого ключа: открытый ключ Боба является ключом, для которого закрытый ключ находится под исключительным контролем Боба (например, только Боб знает этот ключ или закрытый ключ находится в аппаратном маркере - смарт-карте, которую Боб хранит в своем кошельке).

Основным решением является прямой обмен открытым ключом. Когда Элис встретила Боба в баре, они отдали друг другу свои открытые ключи. Таким образом, Алиса может доверять открытому ключу Боба «по определению». Для облегчения обмена (особенно после нескольких сортов пива) Алиса и Боб могут обмениваться только «отпечатками пальцев», то есть значениями хэша, вычисленными по открытым ключам. Эти значения короче, чем открытые ключи (например, 128 битов вместо более чем тысячи битов для типичного открытого ключа RSA), и достаточны для проверки соответствия данного открытого ключа. В этой настройке сервер имеет репозиторий открытых ключей,и Алиса и Боб только пересчитывают отпечатки пальцев, чтобы убедиться, что сервер не играет в фальшивые игры.

Более перспективным решением, которое уменьшает потребность в прямом употреблении алкоголя, является использование сертификатов . Сертификат - это поле, содержащее идентификатор (например, имя, например, «Боб») и открытый ключ. Поле подписано центром сертификации (CA): CA утверждает, что открытый ключ действительно принадлежит Бобу, применив его подпись. Если Алисе известен открытый ключ ЦС, то она может проверить подпись на сертификате, а затем получить доверие к связи между открытым ключом и удостоверением, содержащимся в сертификате.

Сертификация является делегированием доверия. Алиса делегирует свое доверие ЦС; предположительно, ЦА (назовем его Чарли) отправился в бар, чтобы встретиться с Бобом; через сертификат Чарли говорит Элис: «Да, это действительно ключ Боба, он показал его мне после своей третьей пинты». Здесь дела становятся немного мутными, потому что делегировать доверие непросто (особенно если Чарли по привычке пьянствует). Делегирование может быть продолжено, когда ЦС подписывает сертификат для другого ЦС. Здесь Чарли рассказывает Алисе: «Я не встречался с Бобом, но я познакомился с Дафни, которая, возможно, встретила Боба и выступила в качестве ЦА». Элис, используя как сертификат, выданный Чарли Дафни, так и сертификат, выданный Дафни Бобу, может проверить, что цепочка подписей.

В то время как Алиса может знать Чарли и доверять ему в его способности правильно идентифицировать Боба, когда он встретится с ним, даже под влиянием галлона Гиннесса, Алиса не знает Дафни. В цепочке Алиса-Чарли-Дафна-Боб Алиса должна не только доверять тому, что Чарли был надежен (он правильно идентифицировал Дафну), но и тому, что Чарли не был доверчивым, то есть что Чарли отказался бы подписать сертификат на Дафни, если бы Дафни сама не заслуживала доверия. В практических ситуациях доверие быстро ухудшается, когда оно делегировано.

При использовании сертификатов в основном существуют две возможные структуры:

• Иерархический ЦС: существует один или несколько «корневых ЦС», которые известны всем по конструкции. ЦС делегирует другому ЦС (т.е. подписывает сертификат с обычным флагом, который гласит: «этот открытый ключ может быть доверенным для целей проверки подписей на сертификатах») только в рамках договорного соглашения, которое устанавливает юридические обязанности обоих ЦС в отношении сертификации. Это означает, что делегация формально определена, и так бывает, что это непросто. Совместимый с юристами сертификационный договор, обычно называемый «Заявлением о политике сертификации» (CPS), представляет собой документ длиной 200 страниц.

• Web of Trust: все действуют как CA. В отсутствие «формальной благонадежности» каждая отдельная цепочка дает лишь очень небольшой объем доверия. Это должно компенсироваться огромными цифрами.Алиса примет ключ Боба, только если сможет проверить несколько (много) различных цепей, которые ведут к Бобу, проходя через различных участников. Например, Алисе потребуется цепочка Чарли-Дафна-Боб, а также цепи Элайджа-Фиона-Боб и Джеральд-Хиллари-Иван-Боб. Они все пьяницы, но они могут быть коллективно надежными, в том, что фальшивый Боб должен был бы заплатить много раундов, чтобы испортить одного участника каждой из цепочек, которые использует Алиса (если Алиса требует n цепочек с различными сертификатами, то злоумышленник должен испортить по крайней мере n участников).

Так что сертификационный бизнес в основном вопрос процедуры: кто является ЦС, что ЦС проверяет перед выдачей (подписанием) сертификата, как все это выглядит с юридической точки зрения и так далее. Эти процедуры по своей сути сложны и должны поддерживаться подробностями в формате сертификата (например, флагом "этот открытый ключ является ключом ЦС"). В настоящее время определены два основных стандартных формата: X.509 и PGP . X.509 имеет большую поддержку иерархического CA, и это очень запутанный беспорядок стандартов, форматов, практики и комитетов. PGP (стандартизированный под названием "OpenPGP") не имеет реальной поддержки иерархического CA; он предназначен для использования с Web of Trust. OpenPGP проще X.509 но более ограничен, особенно если вы хотите иметь сильное юридическое значение за сертификатами.

Для сервера мгновенных сообщений все это, скорее всего, будет переполнено. Понятие идентичности, которого действительно хочет Алиса, вероятно, является понятием повторения : "что Боб такой же Боб, как тот, с которым я болтал вчера". Алиса не знает Боба заранее, но разговор с ним однажды устанавливает его личность в глазу Алисы. Она просто хочет, чтобы ее не обманул другой Боб. Для этого простой процесс, такой как "программное обеспечение Алисы сохраняет объявленный открытый ключ любой новой болтовни, и использует его впоследствии" сделает трюк. Помните, что основная проблема состоит в том, чтобы правильно определить , какое понятие идентичности вы ищете.