Комментарии 54
А то ли самое (концептуально) делает ssh?
НЛО прилетело и опубликовало эту надпись здесь
SSH поддерживает много разных способов аутентификации. Обычно используется аутентификация на основе криптографии с открытым ключом, но в принципе там есть и аутентификация по паролю, где наверное реализовано что-то подобное.
Основное в моем посте не методика аутентификации - она в принципе стандартная, а ее применение в Web. Цель этого не передавать пароль в открытом виде, что может быть полезно при работе в web через шлюзы третьих лиц - http прокси на работе, небольшие домашние сети и т.п.
Основное в моем посте не методика аутентификации - она в принципе стандартная, а ее применение в Web. Цель этого не передавать пароль в открытом виде, что может быть полезно при работе в web через шлюзы третьих лиц - http прокси на работе, небольшие домашние сети и т.п.
А если имелся в виду не SSH, а https, тогда нет - в этом случае http трафик просто инкапсулируется в SSL туннель, а для аутентификации используются шифры с открытым ключом.
Для полного щастя все последующие операции должны подобным же образом защищаться. Но проще SSL настроить если вы не в Китае...
Как настроить SSL если есть
1. третий сервер, не поддерживающий https, например habrahabr.ru
2. мой комп, например на работе, с которого я имею доступ в инет через локальный прокси и с которого я хочу залогиниться на habrahabr.ru и при этом не засветить пароль сисадмину, который рулит всем компьютерно-серверным хозяйством на работе
Куда здесь SSL приткнуть? А описанный способ
1. реализуется не мной а разработчиком сайта (мне не надо суетиться - все уже сделано)
2. универсален и будет работать во всех современных браузерах
3. достаточно прост в реализации
1. третий сервер, не поддерживающий https, например habrahabr.ru
2. мой комп, например на работе, с которого я имею доступ в инет через локальный прокси и с которого я хочу залогиниться на habrahabr.ru и при этом не засветить пароль сисадмину, который рулит всем компьютерно-серверным хозяйством на работе
Куда здесь SSL приткнуть? А описанный способ
1. реализуется не мной а разработчиком сайта (мне не надо суетиться - все уже сделано)
2. универсален и будет работать во всех современных браузерах
3. достаточно прост в реализации
1. Если у вас не с дуба рухнувший админ запретивший всё на свете включая mail.ru и gmail.com, то SSL-запросы proxy пропускает не обрабатывая.
2. Если админ рулит всем хозяйством то он может рулить и вашим браузером - так что все пароли будут аккуратно записаны в файл ещё до отправки их на сервер.
В общем перед тем, как начинать борьбу - поймите с чем именно вы боретесь, а то так и будете с ветряными мельницами воевать...
2. Если админ рулит всем хозяйством то он может рулить и вашим браузером - так что все пароли будут аккуратно записаны в файл ещё до отправки их на сервер.
В общем перед тем, как начинать борьбу - поймите с чем именно вы боретесь, а то так и будете с ветряными мельницами воевать...
1. куда я буду отправлять "SSL запросы" если на сервере нет поддержки SSL?
2. установленный кейлоггер переводит проблему совсем в другую плоскость spyware/malware, в которой существуют свои способы обнаружения и противодействия, к описанным в моем посте отношения не имеющие.
2. установленный кейлоггер переводит проблему совсем в другую плоскость spyware/malware, в которой существуют свои способы обнаружения и противодействия, к описанным в моем посте отношения не имеющие.
если у вас есть только http-прокся на 80-м порту - то никакие ухищрения не помогут - все ваши пароли (впрочем, не только) через проксю легко проглядываются.
При ssl-содениении _ни_один_ узел между вашим браузером и конечным сервером не способен разпотрошить трафик.
http-протокол сам по себе - это передача открытого текста по дебрям инета. Даже без прокси, а просто разглядывая пакеты между вами и конечным узлом (а делатьь это можно на любой точке между вами и сайтом - коих будет с полдесятка) можно и пароли выдрать и все остальное.
При ssl-содениении _ни_один_ узел между вашим браузером и конечным сервером не способен разпотрошить трафик.
http-протокол сам по себе - это передача открытого текста по дебрям инета. Даже без прокси, а просто разглядывая пакеты между вами и конечным узлом (а делатьь это можно на любой точке между вами и сайтом - коих будет с полдесятка) можно и пароли выдрать и все остальное.
А куда вы будете посылать свои хешированые пароли, если на сервере нет их поддержки? И ваше решение и SSL требуют работ на сервере и не требуют работ на клиенте. Первое - разработчика, второе - админа. Вот и вся разница.
пользуйтесь http://vidalia-project.net/
Что-то я не пойму... SSL тоже:
1. Реализуется не вами, а разработчиком сайта.
2. Универсален и будет работать во всех современных браузерах.
3. Достаточно прост в реализации (вообще не надо писать кода, только получить/сгенерить сертификат и настроить сервер).
1. Реализуется не вами, а разработчиком сайта.
2. Универсален и будет работать во всех современных браузерах.
3. Достаточно прост в реализации (вообще не надо писать кода, только получить/сгенерить сертификат и настроить сервер).
давно уже использую подобный алгоритм, но у меня псевдослучайное число хранится в сессии а не в бд. конечно, ssl надежнее, но если нет возможности заюзать его, такой вариант лучше, чем ничего.
я вот что то не понял чего ж в этом безопасного? И идентификатор и все пароли и все хеши - всё передаётся по сети открытым текстом. Собственно нужно только просёрфить траф в момент логина пользователя (бляха, а когда ж ещё?).
глупости короче.
в ssh наиболее безопасный метод авторизации - с открытым ключом. Авторизация по паролю там работает несколько иным способом:
1) сначала устанавливается зашифрованный канал связи
2) потом уже пересылается хеш от пароля
ssh очень похож на ssl в этом плане.
глупости короче.
в ssh наиболее безопасный метод авторизации - с открытым ключом. Авторизация по паролю там работает несколько иным способом:
1) сначала устанавливается зашифрованный канал связи
2) потом уже пересылается хеш от пароля
ssh очень похож на ssl в этом плане.
Если я правильно понял, то тут предлагается передавать hash(nonce:pass) вместо пароля. Вариация на тему DIGEST, но там чуть иначе.
Мне только не понятно, предполагается ли хранить пароль в базе в открытую?
Мне только не понятно, предполагается ли хранить пароль в базе в открытую?
тьфу да пусть хоть во что угодно превращается пароль перед передачей - превращаться-то он будет яваскриптом. Что мешает проглядеть алгоритм?
глупости короче. (:
глупости короче. (:
Ну, а чем поможет просмотр алгоритма? Все алгоритмы и так известны.
оО
если знать чего нужно передать серваку, чтобы тот посчитал, мол ты взял пароль, применил к нему непонятночто на яваскрипте и выдал - какой смысл вообще узнавать пароль если нужен только хеш?
И, поверьте, мой алгоритм вам не известен.
если знать чего нужно передать серваку, чтобы тот посчитал, мол ты взял пароль, применил к нему непонятночто на яваскрипте и выдал - какой смысл вообще узнавать пароль если нужен только хеш?
И, поверьте, мой алгоритм вам не известен.
Посмотрите внимательней: хеш пароля не нужен. Нужен хеш от нонса и пароля, а его без пароля не узнать.
(Но это так, справедливости ради. Идея страдает примерно так же, как и DIGEST, плюс ещё недостатки, упоминаемые самим автором).
(Но это так, справедливости ради. Идея страдает примерно так же, как и DIGEST, плюс ещё недостатки, упоминаемые самим автором).
>И, поверьте, мой алгоритм вам не известен.
И что это даёт? Защита на основе "неизвестного алгоритма" считается слабой и нигде не используется, кроме как в поделках начинающих кулхацкеров не догадавшихся прочесть ни одной книжки по теме :).
И что это даёт? Защита на основе "неизвестного алгоритма" считается слабой и нигде не используется, кроме как в поделках начинающих кулхацкеров не догадавшихся прочесть ни одной книжки по теме :).
RTFM хэш функции
Передается хэш от пароля и псевдослучайного числа известного серверу. Это число применяется для того, что при перехвате хэша нельзя было бы его использовать повторно для аутентификации. А как хранятся пароли в БД это дело десятое, для простоты описан лишь общий принцип.
Передается хэш от пароля и псевдослучайного числа известного серверу. Это число применяется для того, что при перехвате хэша нельзя было бы его использовать повторно для аутентификации. А как хранятся пароли в БД это дело десятое, для простоты описан лишь общий принцип.
Как хранятся пароли важно потому, что этот метод не позволяет хранить пароли в необратимом виде, вне зависимости от реализации.
тоже подумал это сказать
но вприниципе можно делать хеш пароля на стороне клиента, а потом уж делать хеш и хеша и секретного числа. И отправлять эту только эту штуку серверу.
но вприниципе можно делать хеш пароля на стороне клиента, а потом уж делать хеш и хеша и секретного числа. И отправлять эту только эту штуку серверу.
Да, но тогда как раз см. ваш же комментарий выше: для аутентификации нет обязательно знать пароль, достаточно хеша :)
действительно, это будет решением.
Да, конкретно в описанном случае, не получится хранить на сервере хэш пароля вместо самого пароля. Но алгоритм можно модифицировать. Например использовать ассиметричный шифр - передавать вместо псевдослучайного числа открытый ключ, высчитывать хэш от введенного пароля, затем зашифровывать хэш + N любых псевдослучайных бит этим ключом и передавать на сервер. Там он расшифровывается при помощи закрытого ключа, удаляется N последних бит и полученный хэш сравнивается с хэшом в БД. Реализация например RSA также есть уже готовая на JS. Число бит открытого и закрытого ключа и периодичность их перегенерации на сервере нужно обдумать с точки зрения стойкость/производительность.
А потом тот, кто слушает трафик тупо возьмет куки сеанса и привет. :)
А ещё возможность подмены ключа через MITM (он же ничем не заверен). Можно много чего придумать, наверное, и в результате мы придём к реализации SSL на JS :)
Давайте воспользуемся бритвой Оккама: если есть чего защищать, то SSL. Если нет средств на SSL - нечего защищать.
А ещё возможность подмены ключа через MITM (он же ничем не заверен). Можно много чего придумать, наверное, и в результате мы придём к реализации SSL на JS :)
Давайте воспользуемся бритвой Оккама: если есть чего защищать, то SSL. Если нет средств на SSL - нечего защищать.
Про куки сеанса не совсем понял, имеется в виду что в них сохранятся эти самые N бит? В принципе можно генерить новую связку ключей для каждой аутентификации.
про MITM это да, но думаю защиты от пассивной атаки достаточно для задачи аутентификации на веб ресурсах типа форумов, блогов и т.п. Когда за SSL платить как-то неохото да и смысла в нем нет для таких ресурсов, а как-то решить проблему хочется. Естествено для защиты от реальных угроз только SSL.
про MITM это да, но думаю защиты от пассивной атаки достаточно для задачи аутентификации на веб ресурсах типа форумов, блогов и т.п. Когда за SSL платить как-то неохото да и смысла в нем нет для таких ресурсов, а как-то решить проблему хочется. Естествено для защиты от реальных угроз только SSL.
После того, как введут и проверят пароль, будет сессия передаваться в куках. Заполучить её, конечно, несколько хуже, чем пароль, но тоже сойдёт.
Короче, в технической части мы, вроде, сошлись, а все уступки в безопасности, как Шнайер говорит, субъективны.
Короче, в технической части мы, вроде, сошлись, а все уступки в безопасности, как Шнайер говорит, субъективны.
Понял. Но сессия может (должна !? :)) иметь срок жизни и привязку к IP. Вообще решение, предложенное в топике, должно было обеспечить невозможность того, чтобы любой имеющий доступ к логам прокси сервера, через который я ползаю по вебу, мог посмотреть мои пароли к веб сервисам (форумы, блоги, почта и т.п.), которыми я пользуюсь. И ничего более.
Но думаю мы друг друга поняли и смысла спорить нет.
Но думаю мы друг друга поняли и смысла спорить нет.
чего толку спорить, если все равно об этом уже тысячу раз говорили на протяжении последних лет 10.
ssl и точка. Остальное - глупости.
ssl и точка. Остальное - глупости.
А пароль в БД хранится в открытом виде?
воооооот!
вот это самые большие глупости из всех глупостей в этой идее.
вот это самые большие глупости из всех глупостей в этой идее.
Это не обязательно. В БД можно хранить md5 (или ещё чего) от пароля. При этом на стороне клиента нужно будет сначала склеить md5 от введённого пароля и проверочный ключ, а результат ещё раз захешить.
Уже обсуждалось. См. выше.
Можно шифровать саму БД. Например, Transparent Data Encryption в Oracle.
можно поспорить только в том случае, если пароли в БД уже лежат в хэше. Тогда выполнение любого хэша на стороне клиента - бессмысленно.
С другой стороны, перехватив значимую часть параметров, передаваемых в функцию хэша, и результат хэша - перебором получают остальные параметры хэша. Тоесть борьба низачто.
Грамотнее будет выдавать сессию на логин на основе косвенных факторов - тоесть ip, user-agent, заголовки. Тоесть не показывать и не рассказывать никому о принципе привязки к сессии.
С другой стороны, перехватив значимую часть параметров, передаваемых в функцию хэша, и результат хэша - перебором получают остальные параметры хэша. Тоесть борьба низачто.
Грамотнее будет выдавать сессию на логин на основе косвенных факторов - тоесть ip, user-agent, заголовки. Тоесть не показывать и не рассказывать никому о принципе привязки к сессии.
С другой стороны, перехватив значимую часть параметров, передаваемых в функцию хэша, и результат хэша - перебором получают остальные параметры хэша. Тоесть борьба низачто.
Под остальными параметрами имеется в виду пароль? Полученному хэшу будет соответствовать множество паролей. И в этом случае атака ничем не отличается от перебора паролей украденной базы хэшей с помощью программ типа 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, разрешение экрана и т.п.
Я веду к тому, что сгенерированая соль для хэша (salt) всё-равно может быть перехвачена, потому что отдается клиенту. Тоесть неважно чем мы будем пользоваться для перебора - важно что у нас всё для этого есть.
От перебора никто не застрахован, для сведения на нет этой возможности можно ввести критерий качества пароля (так чтобы отсутствовал в словарях) и его принудительная смена например раз в месяц.
Перебор он и в Африке будет перебором. Введение критериев избавит от прямого перебора, но не избавит от сути - всё перехватывается.
Хотя если SSL и пару js-трюков - думаю будет бессмысленно.
Хотя если SSL и пару js-трюков - думаю будет бессмысленно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аутентификация в Web