Pull to refresh

Comments 54

А то ли самое (концептуально) делает ssh?
UFO just landed and posted this here
Нет, именно ssh. Ну там его первая фаза проверки. Никак не могу найти быстро подробности, давно читал.
ssh делает нечто похожее на ssl.
перед тем как передавать какие-либо данные устаканивается зашифрованный канал.
SSH поддерживает много разных способов аутентификации. Обычно используется аутентификация на основе криптографии с открытым ключом, но в принципе там есть и аутентификация по паролю, где наверное реализовано что-то подобное.

Основное в моем посте не методика аутентификации - она в принципе стандартная, а ее применение в Web. Цель этого не передавать пароль в открытом виде, что может быть полезно при работе в web через шлюзы третьих лиц - http прокси на работе, небольшие домашние сети и т.п.
А если имелся в виду не SSH, а https, тогда нет - в этом случае http трафик просто инкапсулируется в SSL туннель, а для аутентификации используются шифры с открытым ключом.
Для полного щастя все последующие операции должны подобным же образом защищаться. Но проще SSL настроить если вы не в Китае...
Как настроить SSL если есть
1. третий сервер, не поддерживающий https, например habrahabr.ru
2. мой комп, например на работе, с которого я имею доступ в инет через локальный прокси и с которого я хочу залогиниться на habrahabr.ru и при этом не засветить пароль сисадмину, который рулит всем компьютерно-серверным хозяйством на работе
Куда здесь SSL приткнуть? А описанный способ
1. реализуется не мной а разработчиком сайта (мне не надо суетиться - все уже сделано)
2. универсален и будет работать во всех современных браузерах
3. достаточно прост в реализации
1. Если у вас не с дуба рухнувший админ запретивший всё на свете включая mail.ru и gmail.com, то SSL-запросы proxy пропускает не обрабатывая.
2. Если админ рулит всем хозяйством то он может рулить и вашим браузером - так что все пароли будут аккуратно записаны в файл ещё до отправки их на сервер.

В общем перед тем, как начинать борьбу - поймите с чем именно вы боретесь, а то так и будете с ветряными мельницами воевать...
1. куда я буду отправлять "SSL запросы" если на сервере нет поддержки SSL?
2. установленный кейлоггер переводит проблему совсем в другую плоскость spyware/malware, в которой существуют свои способы обнаружения и противодействия, к описанным в моем посте отношения не имеющие.
если у вас есть только http-прокся на 80-м порту - то никакие ухищрения не помогут - все ваши пароли (впрочем, не только) через проксю легко проглядываются.

При ssl-содениении _ни_один_ узел между вашим браузером и конечным сервером не способен разпотрошить трафик.

http-протокол сам по себе - это передача открытого текста по дебрям инета. Даже без прокси, а просто разглядывая пакеты между вами и конечным узлом (а делатьь это можно на любой точке между вами и сайтом - коих будет с полдесятка) можно и пароли выдрать и все остальное.
да я в курсе вообще то :) к чему был этот пост?
А куда вы будете посылать свои хешированые пароли, если на сервере нет их поддержки? И ваше решение и SSL требуют работ на сервере и не требуют работ на клиенте. Первое - разработчика, второе - админа. Вот и вся разница.
пользуйтесь http://vidalia-project.net/
Что-то я не пойму... SSL тоже:
1. Реализуется не вами, а разработчиком сайта.
2. Универсален и будет работать во всех современных браузерах.
3. Достаточно прост в реализации (вообще не надо писать кода, только получить/сгенерить сертификат и настроить сервер).
давно уже использую подобный алгоритм, но у меня псевдослучайное число хранится в сессии а не в бд. конечно, ssl надежнее, но если нет возможности заюзать его, такой вариант лучше, чем ничего.
я вот что то не понял чего ж в этом безопасного? И идентификатор и все пароли и все хеши - всё передаётся по сети открытым текстом. Собственно нужно только просёрфить траф в момент логина пользователя (бляха, а когда ж ещё?).

глупости короче.

в ssh наиболее безопасный метод авторизации - с открытым ключом. Авторизация по паролю там работает несколько иным способом:

1) сначала устанавливается зашифрованный канал связи
2) потом уже пересылается хеш от пароля

ssh очень похож на ssl в этом плане.
Если я правильно понял, то тут предлагается передавать hash(nonce:pass) вместо пароля. Вариация на тему DIGEST, но там чуть иначе.
Мне только не понятно, предполагается ли хранить пароль в базе в открытую?
тьфу да пусть хоть во что угодно превращается пароль перед передачей - превращаться-то он будет яваскриптом. Что мешает проглядеть алгоритм?

глупости короче. (:
Ну, а чем поможет просмотр алгоритма? Все алгоритмы и так известны.
оО

если знать чего нужно передать серваку, чтобы тот посчитал, мол ты взял пароль, применил к нему непонятночто на яваскрипте и выдал - какой смысл вообще узнавать пароль если нужен только хеш?

И, поверьте, мой алгоритм вам не известен.
Посмотрите внимательней: хеш пароля не нужен. Нужен хеш от нонса и пароля, а его без пароля не узнать.
(Но это так, справедливости ради. Идея страдает примерно так же, как и DIGEST, плюс ещё недостатки, упоминаемые самим автором).
>И, поверьте, мой алгоритм вам не известен.
И что это даёт? Защита на основе "неизвестного алгоритма" считается слабой и нигде не используется, кроме как в поделках начинающих кулхацкеров не догадавшихся прочесть ни одной книжки по теме :).
Да всё, разобрались уже :)
это была просто придирка к словам.

хотя защита на основе закрытия алгоритма - используется в 99% случаев проверки лицензионных ключей (: Не очень удачно, правда.

Но все равно это была придирка к словам и ничего более (: Я не хочу об этом спорить! ))))
RTFM хэш функции

Передается хэш от пароля и псевдослучайного числа известного серверу. Это число применяется для того, что при перехвате хэша нельзя было бы его использовать повторно для аутентификации. А как хранятся пароли в БД это дело десятое, для простоты описан лишь общий принцип.
Как хранятся пароли важно потому, что этот метод не позволяет хранить пароли в необратимом виде, вне зависимости от реализации.
тоже подумал это сказать

но вприниципе можно делать хеш пароля на стороне клиента, а потом уж делать хеш и хеша и секретного числа. И отправлять эту только эту штуку серверу.
Да, но тогда как раз см. ваш же комментарий выше: для аутентификации нет обязательно знать пароль, достаточно хеша :)
hash(pass, rand_num ) заменяется на hash( hash(pass), rand_num ). сервер, получив данные, берет хэш пароля из БД, число, а затем высчитывает хэш от всего этого и сравнивает с полученным.
Ещё раз. В этом случае исчезает необходимость похищать пароль. Достаточно похитить его хеш, и тогда возникает проблема хранения уже хеша в открытую ;)
ага точно :) не пройдет такой трюк.
действительно, это будет решением.
Да, конкретно в описанном случае, не получится хранить на сервере хэш пароля вместо самого пароля. Но алгоритм можно модифицировать. Например использовать ассиметричный шифр - передавать вместо псевдослучайного числа открытый ключ, высчитывать хэш от введенного пароля, затем зашифровывать хэш + N любых псевдослучайных бит этим ключом и передавать на сервер. Там он расшифровывается при помощи закрытого ключа, удаляется N последних бит и полученный хэш сравнивается с хэшом в БД. Реализация например RSA также есть уже готовая на JS. Число бит открытого и закрытого ключа и периодичность их перегенерации на сервере нужно обдумать с точки зрения стойкость/производительность.
А потом тот, кто слушает трафик тупо возьмет куки сеанса и привет. :)
А ещё возможность подмены ключа через MITM (он же ничем не заверен). Можно много чего придумать, наверное, и в результате мы придём к реализации SSL на JS :)
Давайте воспользуемся бритвой Оккама: если есть чего защищать, то SSL. Если нет средств на SSL - нечего защищать.
Про куки сеанса не совсем понял, имеется в виду что в них сохранятся эти самые N бит? В принципе можно генерить новую связку ключей для каждой аутентификации.
про MITM это да, но думаю защиты от пассивной атаки достаточно для задачи аутентификации на веб ресурсах типа форумов, блогов и т.п. Когда за SSL платить как-то неохото да и смысла в нем нет для таких ресурсов, а как-то решить проблему хочется. Естествено для защиты от реальных угроз только SSL.
После того, как введут и проверят пароль, будет сессия передаваться в куках. Заполучить её, конечно, несколько хуже, чем пароль, но тоже сойдёт.
Короче, в технической части мы, вроде, сошлись, а все уступки в безопасности, как Шнайер говорит, субъективны.
Понял. Но сессия может (должна !? :)) иметь срок жизни и привязку к IP. Вообще решение, предложенное в топике, должно было обеспечить невозможность того, чтобы любой имеющий доступ к логам прокси сервера, через который я ползаю по вебу, мог посмотреть мои пароли к веб сервисам (форумы, блоги, почта и т.п.), которыми я пользуюсь. И ничего более.

Но думаю мы друг друга поняли и смысла спорить нет.
чего толку спорить, если все равно об этом уже тысячу раз говорили на протяжении последних лет 10.

ssl и точка. Остальное - глупости.
А пароль в БД хранится в открытом виде?
воооооот!
вот это самые большие глупости из всех глупостей в этой идее.
Это не обязательно. В БД можно хранить md5 (или ещё чего) от пароля. При этом на стороне клиента нужно будет сначала склеить md5 от введённого пароля и проверочный ключ, а результат ещё раз захешить.
Можно шифровать саму БД. Например, Transparent Data Encryption в Oracle.
можно поспорить только в том случае, если пароли в БД уже лежат в хэше. Тогда выполнение любого хэша на стороне клиента - бессмысленно.

С другой стороны, перехватив значимую часть параметров, передаваемых в функцию хэша, и результат хэша - перебором получают остальные параметры хэша. Тоесть борьба низачто.

Грамотнее будет выдавать сессию на логин на основе косвенных факторов - тоесть 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 это тоже касается - теоретически можно подобрать сессионный ключ или или закрытый ключ RSA. Вопрос только в вычислительных ресурсах.
Теорию пока оставим - будем реалистами))
ок, но подбор например SHA-1 хэша это тоже задача не домашних вычислительных мощностей :)
http://ru.wikipedia.org/wiki/Полный_перебор
классные циферки:
1505614 лет, 11 месяцев, 30 дней, 1 час, 11 минут, 45 секунд
Sign up to leave a comment.

Articles