С другой стороны, перехватив значимую часть параметров, передаваемых в функцию хэша, и результат хэша - перебором получают остальные параметры хэша. Тоесть борьба низачто.
Под остальными параметрами имеется в виду пароль? Полученному хэшу будет соответствовать множество паролей. И в этом случае атака ничем не отличается от перебора паролей украденной базы хэшей с помощью программ типа JtR. За одним исключением, hash(real_pass, rand_num) != hash(good_pass, rand_num), где good_pass и real_pass члены одного подмножества для которых верно утверждение hash(good_pass) == hash(real_pass).
Грамотнее будет выдавать сессию на логин на основе косвенных факторов - тоесть ip, user-agent, заголовки. Тоесть не показывать и не рассказывать никому о принципе привязки к сессии.
Дополнительно при ожидание логина с определенного "выданного" псевдослучайного идентификатора можно сделать дополнительную привязку к этому идентификатора еще и IP, user-agent, разрешение экрана и т.п.
Понял. Но сессия может (должна !? :)) иметь срок жизни и привязку к IP. Вообще решение, предложенное в топике, должно было обеспечить невозможность того, чтобы любой имеющий доступ к логам прокси сервера, через который я ползаю по вебу, мог посмотреть мои пароли к веб сервисам (форумы, блоги, почта и т.п.), которыми я пользуюсь. И ничего более.
Но думаю мы друг друга поняли и смысла спорить нет.
Про куки сеанса не совсем понял, имеется в виду что в них сохранятся эти самые N бит? В принципе можно генерить новую связку ключей для каждой аутентификации.
про MITM это да, но думаю защиты от пассивной атаки достаточно для задачи аутентификации на веб ресурсах типа форумов, блогов и т.п. Когда за SSL платить как-то неохото да и смысла в нем нет для таких ресурсов, а как-то решить проблему хочется. Естествено для защиты от реальных угроз только SSL.
hash(pass, rand_num ) заменяется на hash( hash(pass), rand_num ). сервер, получив данные, берет хэш пароля из БД, число, а затем высчитывает хэш от всего этого и сравнивает с полученным.
Да, конкретно в описанном случае, не получится хранить на сервере хэш пароля вместо самого пароля. Но алгоритм можно модифицировать. Например использовать ассиметричный шифр - передавать вместо псевдослучайного числа открытый ключ, высчитывать хэш от введенного пароля, затем зашифровывать хэш + N любых псевдослучайных бит этим ключом и передавать на сервер. Там он расшифровывается при помощи закрытого ключа, удаляется N последних бит и полученный хэш сравнивается с хэшом в БД. Реализация например RSA также есть уже готовая на JS. Число бит открытого и закрытого ключа и периодичность их перегенерации на сервере нужно обдумать с точки зрения стойкость/производительность.
Передается хэш от пароля и псевдослучайного числа известного серверу. Это число применяется для того, что при перехвате хэша нельзя было бы его использовать повторно для аутентификации. А как хранятся пароли в БД это дело десятое, для простоты описан лишь общий принцип.
1. куда я буду отправлять "SSL запросы" если на сервере нет поддержки SSL?
2. установленный кейлоггер переводит проблему совсем в другую плоскость spyware/malware, в которой существуют свои способы обнаружения и противодействия, к описанным в моем посте отношения не имеющие.
Да статья хорошая, но вот перешел по ссылке - почитал о покупедии.ру и как-то разочаровало - после такой статьи ожидал большего.
Вот предпосылки создания проекта из приведенной выше ссылки
* Во-первых, часто задача выбора конкретного товара из товарной категории становится трудно решаемой.
* Во-вторых, появляется желание четко оценить количественный и качественный состав приобретаемых товаров.
* И в-третьих. Выбирать товары и магазины помогают рекомендации. Люди, которые могут их дать, существуют, но мы их не знаем.
Это чисто мое мнение, но по моему
1. Для реализации этих задач совсем не обязательно заставлять пользователя фотографировать и отсылать чеки. Или фишка с чеками были придумана чтобы была причина позаниматься OCR и DSP? :)
2. Места в интернете, сильно помогающие по первому и второму пункту давно существуют - это тематические форумы, обзоры и статьи, рейтинги и комментарии как у market.yandex.
Как настроить SSL если есть
1. третий сервер, не поддерживающий https, например habrahabr.ru
2. мой комп, например на работе, с которого я имею доступ в инет через локальный прокси и с которого я хочу залогиниться на habrahabr.ru и при этом не засветить пароль сисадмину, который рулит всем компьютерно-серверным хозяйством на работе
Куда здесь SSL приткнуть? А описанный способ
1. реализуется не мной а разработчиком сайта (мне не надо суетиться - все уже сделано)
2. универсален и будет работать во всех современных браузерах
3. достаточно прост в реализации
А если имелся в виду не SSH, а https, тогда нет - в этом случае http трафик просто инкапсулируется в SSL туннель, а для аутентификации используются шифры с открытым ключом.
SSH поддерживает много разных способов аутентификации. Обычно используется аутентификация на основе криптографии с открытым ключом, но в принципе там есть и аутентификация по паролю, где наверное реализовано что-то подобное.
Основное в моем посте не методика аутентификации - она в принципе стандартная, а ее применение в Web. Цель этого не передавать пароль в открытом виде, что может быть полезно при работе в web через шлюзы третьих лиц - http прокси на работе, небольшие домашние сети и т.п.
Как происходит внедрение этой DLL в адресное пространство заражаемых процессов? "дроппер, который скидывает анализируемую DLL на диск и прописывает ее в систему." Вот этот вопрос можно раскрыть?
С этим полностью согласен :) Хорошо всегда использовать лучшее, но не всегда так выходит..
Для меня критерием качества источника информации является смогу ли я извлечь из представленных данных нужную мне информацию за заданный отрезок времени. Если материал удовлетворяет этим требованиям, значит он хороший независимо от его оценок относительно всего множества материалов данной тематики, так как он позволяет решать текущие задачи прямо здеcь и сейчас, а ничего другого и не требуется. Ведь по сути дела, кроме самих данных решающее значение имеют методы работы с ними и тот бэкграунд знаний которые уже есть на момент начала работы с новым источником информации. Оба этих параметра оказывают очень серьезное влияние на восприятие и усваивание новой информации.
Выше я имел в виду то, что когда "беспорядочных" знаний в разных смежных областях становится много, они начинают обрастать связами и представлять собой одну ясную картину.
Может быть способ и не лучший, но свои преимущества имеет. Например когда-то именно раздел по WinAPI сайта firststeps помог мне быстро начать писать Win32 API приложения, а не чтение упорядоченного и структурированного MSDN и даже не книжки Рихтера про программирование под Windows. Лично мне было проще начать так, а потом по мере необходимости был подтянут MSDN и была прочитана книга Рихтера.
Беспорядочно накопленные знания, при наборе определенной критической и массы и при условии их реального применения имеют свойство упорядочиваться сами собой :)
Под остальными параметрами имеется в виду пароль? Полученному хэшу будет соответствовать множество паролей. И в этом случае атака ничем не отличается от перебора паролей украденной базы хэшей с помощью программ типа JtR. За одним исключением, hash(real_pass, rand_num) != hash(good_pass, rand_num), где good_pass и real_pass члены одного подмножества для которых верно утверждение hash(good_pass) == hash(real_pass).
Дополнительно при ожидание логина с определенного "выданного" псевдослучайного идентификатора можно сделать дополнительную привязку к этому идентификатора еще и IP, user-agent, разрешение экрана и т.п.
/home/neo$ matrix -me
Segmentation fault. Core dumped.
/home/neo$
Но думаю мы друг друга поняли и смысла спорить нет.
про MITM это да, но думаю защиты от пассивной атаки достаточно для задачи аутентификации на веб ресурсах типа форумов, блогов и т.п. Когда за SSL платить как-то неохото да и смысла в нем нет для таких ресурсов, а как-то решить проблему хочется. Естествено для защиты от реальных угроз только SSL.
Передается хэш от пароля и псевдослучайного числа известного серверу. Это число применяется для того, что при перехвате хэша нельзя было бы его использовать повторно для аутентификации. А как хранятся пароли в БД это дело десятое, для простоты описан лишь общий принцип.
2. установленный кейлоггер переводит проблему совсем в другую плоскость spyware/malware, в которой существуют свои способы обнаружения и противодействия, к описанным в моем посте отношения не имеющие.
Вот предпосылки создания проекта из приведенной выше ссылки
* Во-первых, часто задача выбора конкретного товара из товарной категории становится трудно решаемой.
* Во-вторых, появляется желание четко оценить количественный и качественный состав приобретаемых товаров.
* И в-третьих. Выбирать товары и магазины помогают рекомендации. Люди, которые могут их дать, существуют, но мы их не знаем.
Это чисто мое мнение, но по моему
1. Для реализации этих задач совсем не обязательно заставлять пользователя фотографировать и отсылать чеки. Или фишка с чеками были придумана чтобы была причина позаниматься OCR и DSP? :)
2. Места в интернете, сильно помогающие по первому и второму пункту давно существуют - это тематические форумы, обзоры и статьи, рейтинги и комментарии как у market.yandex.
1. третий сервер, не поддерживающий https, например habrahabr.ru
2. мой комп, например на работе, с которого я имею доступ в инет через локальный прокси и с которого я хочу залогиниться на habrahabr.ru и при этом не засветить пароль сисадмину, который рулит всем компьютерно-серверным хозяйством на работе
Куда здесь SSL приткнуть? А описанный способ
1. реализуется не мной а разработчиком сайта (мне не надо суетиться - все уже сделано)
2. универсален и будет работать во всех современных браузерах
3. достаточно прост в реализации
Основное в моем посте не методика аутентификации - она в принципе стандартная, а ее применение в Web. Цель этого не передавать пароль в открытом виде, что может быть полезно при работе в web через шлюзы третьих лиц - http прокси на работе, небольшие домашние сети и т.п.
Для меня критерием качества источника информации является смогу ли я извлечь из представленных данных нужную мне информацию за заданный отрезок времени. Если материал удовлетворяет этим требованиям, значит он хороший независимо от его оценок относительно всего множества материалов данной тематики, так как он позволяет решать текущие задачи прямо здеcь и сейчас, а ничего другого и не требуется. Ведь по сути дела, кроме самих данных решающее значение имеют методы работы с ними и тот бэкграунд знаний которые уже есть на момент начала работы с новым источником информации. Оба этих параметра оказывают очень серьезное влияние на восприятие и усваивание новой информации.
Может быть способ и не лучший, но свои преимущества имеет. Например когда-то именно раздел по WinAPI сайта firststeps помог мне быстро начать писать Win32 API приложения, а не чтение упорядоченного и структурированного MSDN и даже не книжки Рихтера про программирование под Windows. Лично мне было проще начать так, а потом по мере необходимости был подтянут MSDN и была прочитана книга Рихтера.