Single Sign On with Nginx

Mikhail Fursov mike.fursov на gmail.com
Пт Фев 26 15:58:32 MSK 2010


Я со многим из того что вы говорите согласен. Но тут нужно понять одно: надо
дать возможноть разработчику самому принимать решения и отвечать за них,  а
не ограничивать его только чем-то одним. Варианты использования инфы
неисповедимы.

2010/2/26 Andrew Kopeyko <kaa на zvuki.ru>

> Mikhail Fursov wrote:
>
>> 2010/2/26 Andrew Kopeyko <kaa на zvuki.ru <mailto:kaa на zvuki.ru>>
>>
>>
>>    Mikhail Fursov wrote:
>>
>>
>>        2) Должна быть указан URL страницы на которую переходить при
>>        ошибке аутентификации. Тут важно передать странице с ошибкой
>>        полную информацию об аутентификации - логин, пароль, тип ошибки
>>        (если возможно). В Apache этого нет, поэтому когда происходит
>>        ошибка аутентификации и пользователя требуют заново ввести
>>        пароль совсем непонятно по какой причине: его аккаунт
>>        заблокирован, задан неправильный пароль etc. Это очень неудобно.
>>
>>
>>    Зато правильно с точки зрения безопасности - при отказе в доступе не
>>    происходит раскрытия информации. Удивительно, что вы не знаете таких
>>    базовых вещей.
>>
>>    А ваш "дружественный" интерфейс будет подыгрывать взломщику,
>>    позволяя ему последовательно подобрать логин, а затем пароль.
>>
>>    Вы ведь не ограничиваете кол-во неудачных попыток авторизации?
>>
>>
>> Я не гуру в разработке веб-серверов но не вижу тут никакого раскрытия
>> информации. На error-document шли бы те же данные, что ввел сам
>> пользователь.  Что из них ожно раскрыть?
>>
>
> Если вы не будете разжёвывать пользователю что именно он ввёл неправильно,
> а просто скажете "не попал" - тогда раскрытия не будет.
>
> А вот если вы будете ему сообщать (условно) "неправильный логин", "логин
>  заблокирован", "логин верный, неверен пароль" - это уже раскрытие
> информации. Ведь до момента успешной авторизации вы знать не знаете кто
> сидит на другой стороне - валидный пользователь, или злоумышленник.
> Собственно, для того вы аутентификацию и делаете - дабы отличить одного от
> другого.
>
> Посмотрите вокруг - в подавляюшем большинстве информационных систем при
> неудачной аутентификации говорится что-то типа "доступ запрещён" не уточняя
> по какой именно причине. Windows в этом месте - сделан исключительно
> правильно.
>
> Но вы, если я правильно вас понял, хотите облегчить пользователю жизнь, и
> подсказывать бедолаге в чём именно он ошибся, в логине или в пароле.
>
> Т.е. в дилемме "удобство vs. безопасность" вы выбираете "удобство", тем
> самым снижая безопасность вашей системы.
>
> Безопасность будет снижаться, потому что злоумышленнику не нужно будет
> подбирать всю пару логин-пароль - он сможет, пользуясь подсказками вашего
> дружественного интерфейса, отдельно подобрать незаблокированный логин
> (передавая, к примеру "" в качестве пароля), и затем подобрать верный пароль
> к этому логину. Поскольку длина отдельно логина существенно меньше длины
> пары логин-пароль, времени на такой подбор потребуется существенно меньше.
>
>
> Решать, разумеется, вам - но настоятельно советую отказаться от вашей затеи
> "с удобствами", и наружу выдавать только сообщение "доступ запрещён", без
> подробностей.
>
>
>
> --
> Best regards,
> Andrew A. Kopeyko <kaa на zvuki.ru>
> http://www.zvuki.ru/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>



-- 
Mikhail Fursov
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100226/116955ac/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru