Разработчикам систем парольной аутентификации - Информационная безопасность

Уважаемые сабжы!

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

Собственно, просьбы:

1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите

2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.

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

4. Если же такой придурок таки-нашелся, не отчаивайтесь! Вы можете существенно облегчить жизнь пользователям, если разрешите им менять свой пароль на точно такой же, или использованный в прошлый раз. Мелочь, а того придурка на место поставите.

5. И вообще, запомните: идиота, выставляющего какие-либо требования к парольной защите вы просто обязаны наобмануть по полной программе! Ведь именно из-за него у вас вообще возникла необходимость в этой самой парольной защите

6. Разумеется, ваши сервера не халявная рапидшара и нехрен позволять пользователям засорять место на жестких дисках своими ублюдскими 20-символьными паролями. 8 символов хватит всем! Это в конце 90-ых всем доступно объяснил Microsoft, если кто не помнит.

7. И вообще, в задницу все ограничения на сложность паролей! Ваши пользователи — свободные люди и было бы жесточайшим ущемлением их прав навязывать им необходимость использования каких-либо групп символов в обязаловку. И, если убежденный расист хочет иметь пароль "fuckingniggas", то кто вы такой, чтобы запрещать ему это?!

8. Но если вдруг, вы реализуете какие-либо ограничения, то ни в коем случае ни раскрывайте их пользователю заранее и одной пачкой! Выдавайте информацию постепенно. Во-первых, в этом случае злой хакерюга не сможет сразу вдуплить вашу парольную политику и оставит попытки получить доступ, а во-вторых, нет ничего забавнее, чем потом наблюдать в логах, как пользователь трахался, пытаясь понять: какие еще ограничения он не учел?

9. Да-да, обязательно отражайте в логах все вводимые пароли. Потом, если внезапно рухнет база, ее можно будет легко по ним восстановить.

10. Ни в коем разе не используйте идентификаторы сессий! Вы сами-то хоть подумали, сколько кода вам придется для этого написать? Да и аутентифицироваться заново на каждую операцию безопаснее. А серверы — выдержат, мы же в п.3 их мощность сэкономили.

11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

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

13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.

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

15. И никогда, ни под каким предлогом, не передавайте аутентификационные данные по защищенному каналу: затрахаетесь потом это отлаживать

P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

22.12.10 01:06: Перенесено модератором из 'Философия программирования' — kochetkov.vladimir

Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.

AAV>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?

Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

Самое забавное было в этой истории то, что незадолго до начала хищений, Альфа-банк сертифицировался на соответствие PCI DSS (http://www.itsec.ru/newstext.php?news_id=53489). Но пересечение каналов передачи основного и сеансового пароля почему-то в ходе сертификации выявлено не было

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите

Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего:
==

Здравствуйте, ...!

С большим удовольствием сообщаем,
что в основной ассортимент футболок добавлены 6 новых цветов!

...

Доступ в личный кабинет:
Имя пользователя: ...
Пароль: ...

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Собственно, просьбы:
O>Собственно из личного юзерского опыта — чем параноидальнее сайт, тем чаще пароли приходится записывать на бумажке и вешать на монитор

Однажды Сисадмин пожаловался Учителю:

– Мы выдали всем нашим пользователям индивидуальные пароли, а они не желают хранить их в тайне. Записывают на листочках и приклеивают к мониторам. Что нам делать? Как заставить их?

Инь Фу Во спросил:

– Сначала скажи, почему они это делают.

Сисадмин подумал и ответил:

– Может быть, они не считают пароль ценным?

– А разве пароль сам по себе ценный?

– Не сам по себе. Ценна информация, которая под паролем.

– Для кого она ценна?

– Для нашего предприятия.

– А для пользователей?

– Для пользователей, видимо, нет.

– Так и есть, – сказал Учитель. – Под паролем нет ничего ценного для наших работников. Надо, чтоб было.

– Что для них ценно? – спросил Сисадмин.

– Догадайся с трёх раз, – рассмеялся Учитель.

Сисадмин ушёл просветлённый и сделал на корпоративном портале персональные странички для всех работников. И на тех страничках был указан размер зарплаты. Узнав об этом, все пользователи забеспокоились о своих паролях. На другой день в курилке обсуждали размер зарплаты Главбуха. На третий день ни у кого не было видно листочков с паролями.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, kochetkov.vladimir, Вы писали:

SH>>>Ещё посолить неплохо бы.

KV>>И растянуть

SH>Я не знаю, что это значит

SH>Объясни?

http://www.rsdn.ru/article/crypto/StorageOfSecrets.xml#ESC

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

"Параноидальнее" — не очень правильная оценка. Если сайт предоставляет пользователю какие-либо сервисы и при этом особо не обещает каких-либо мер, направленных на защиту пользовательского аккаунта, то излишнее закручивание гаек в плане требований к паролю там будет вряд ли уместно. Если пользователь захочет — он сам обеспечит себе определенную степень защиты, используя стойкий пароль. Если нет, то его можно предупредить об этом, но не более того.

Если же сайт берет на себя определенные обязательства, как в случае с Альфа-банком, либо безопасность сайта находится в некоторой зависимости от безопасности аккаунта пользователя (так тоже бывает), то и обязательные требования к паролям должны быть жестче, чтобы сайт имел возможность эти требования выполнить либо обеспечить свою безопасность.

Кроме того, я считаю, что проблема "пользователи не могут запоминать стойкие пароли" несколько надумана. Правильнее было бы говорить о проблеме "пользователи не хотят запоминать стойкие пароли". Пароль, который я использую на этом сайте выглядит примерно так: ~rM@0%s_jR4q| при этом он довольно стойкий (энтропия около 80 бит), учитывая его периодическую замену, т.к. безопасность моего аккаунта кореллирует с безопасностью всего сайта. Но на его запоминание у меня ушло от силы полчаса. Не думаю, что мои мнемонические навыки развиты как-то сильно особенно по сравнению со всеми остальными.

Для некоторых других сайтов и систем я использую менее стойкие, но легко запоминающиеся пароли, для некоторых (типа ибанкинга, админских аккаунтов на VDS и т.п.) — гораздо более сложнее приведенного. Но у меня ни разу не возникало проблем с их запоминанием, даже с учетом их регулярной замены в случае с некоторыми сайтами или системами

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?

Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

Можно комментарий?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

Чем гуид не угодил? Слабый алгоритм генерации случайного числа? А что вместо него, если криптостойкий генератор в конкретной платформе недоступен?

KV>14. Капча — зло.

Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Курилка, Вы писали:

KV>>>Я не силен в java... это оговорено в стандарте?

К>>JDK поддерживает версии 3 и 4 UUID

KV>Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?

JSR как-то очень "расплывчато" говорит об этом :

This feature is to add UUID functionality to the J2SE platform by the addition of a UUID class for ma-
nipulating Leach-Salz variants.
The uuid (Universal Unique Identifier) is an XOPEN standard
for creating a globally unique id.
...

В TCK сомневаюсь, что включена проверка "рандомности" (ну и не очень представляю как её можно относительно дёшево сделать).
По идее, конечно есть ISO/IEC 11578:1996 и ISO/IEC 9834-8:2005, но в джавных спеках, кажется, нет гвоздями прибитой связи randomUUID с версией 4 (хотя есть в javadoc)

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Кстати, не напомнишь ту ссылку, где ты бодался по поводу передачи пароля в открытом виде? Что-то не могу найти

Откопал-таки: http://rsdn.ru/forum/web/3611508.aspx. Я подозревал, что словосочетание "парольный эквивалент" не часто встречается на rsdn

Основную вину за кражу денег потерпевшие возложили на банк. "Альфа-банк допустил халатность при разработке системы безопасности для удаленной работы со счетами. Ну как можно обеспечить сохранность наших средств, если банк высылает постоянный пароль и пароли на операции по счетам с помощью SMS", — возмущается Андрей.

Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.

Здравствуйте, kochetkov.vladimir, Вы писали:

k> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется

OpenID?

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
Зависит от типа GUID'а. Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.

Здравствуйте, Курилка, Вы писали:

К>JUG, кажись, позволяет генерить UUID и через MAC, только через JNI-вызовы вроде как.
К>Ну и товарищи из редмонда в методе Guid.NewGuid небось не забили на MAC-адрес (в MSDN ни строчки не нашёл про стандарты), а мелкомягкие технологии имеют довольно неплохую массу инерции

Guid.NewGuid() = {2d587ad2-a380-4d10-9ee8-1e904c6f4cbf}

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS

Ну для этого и капча и ограничения per IP и все такое...

Здравствуйте, Mamut, Вы писали:

AB>>OpenID?
M>Сразу вспоминается http://rsdn.ru/forum/web/3880202.aspx

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

A>>>Ну если идентификатор чужой?

KV>>Если идентификатор чужой, то как он оказался у тебя?

A>Троян, например.

А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет

Здравствуйте, Mamut, Вы писали:

M> AB>OpenID?
M> Сразу вспоминается http://rsdn.ru/forum/web/3880202.aspx

Ага. Но я, например, вообще переложил проверку подписи на OpenID провайдера — он прислал ответ, так пусть он же его и валидирует. Но жаль, что OpenID практически невозможно использовать вне веб (например, для авторизации svn).

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.

Ещё посолить неплохо бы.

Здравствуйте, kochetkov.vladimir, Вы писали:

A>>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.
KV>Я на выходных обычно впадаю в туплячку... А что это нам даст?

Даже при условии предсказуемости, теперь надо предсказать поведение сразу двух компьютеров в фиксированные моменты времени. Причём о клиентском информации нет.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, DOOM, Вы писали:

DOO>>

DOO>>- код или пароль, предъявленный при неуспешной попытке;

KV>Я писал все больше про успешные. А с отказами — тут палка о двух концах. С одной стороны — куда более качественная доказательная база из логов получается, случись вдруг что. С другой стороны, любой, кто имеет доступ к логам получит возможность существенно сузить количество перебираемых вариантов за счет анализа неуспешных попыток легальных пользователей. В принципе, можно шифровать все неправильные пароли ассиметрией, но это уже может вызвать вопросы у других умников

Мое мнение здесь однозначное — если распределенная система способна определить "код или пароль, предъявленный при неуспешной попытке", то у нее уже кривая схема аутентификации (правда здесь я бы не понят с такой точкой зрения

Здравствуйте, AndrewVK, Вы писали:

KV>>14. Капча — зло.

AVK>Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.

Зло, зло. Простые капчи обходятся запросто (достаточно вспомнить кучу статей на хабре), а сложные по стоимости сопостовимы с затратами по обычной обработке роботных действий — причём и по стоимости создания, и по стоимости сопровождения (число жалоб на спам не сильно больше числа жалоб на сработавшую капчу).
А наличие на рынке тысяч китайцев по цене 10 баксов за тысячу капч вообще делает все поползновения бессмысленными

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, DOOM, Вы писали:

DOO>>Дело в том, что целенаправленно блокировать аккаунты — это какое-то странное занятие. Профит где?
KV>Это тот же DoS, вид с боку. Какой профит от DoS'а? Шантаж, борьба с конкурентами и т.п.
Это какой-то сложный DoS. Гораздо проще ломануться ботнетом на произвольную страничку ресруса и повалить его этим

Стоимость такого DDoS'а настолько смешна, что выдумывать что-то другое профита уж точно нет...

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>И растянуть

SH>>Я не знаю, что это значит

SH>>Объясни?

KV>http://www.rsdn.ru/article/crypto/StorageOfSecrets.xml#ESC

А, я знал, я знал

Только названия не знал. Спасибо.

Здравствуйте, Anton Batenev, Вы писали:

AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).
Опять же аутентификация в HTTPS на сертификатах — куда уж мощнее...
Можно самому реализовать любую схему Challenge/Response со взаимной аутентификацией (благо посчитать MD5 в JS не проблема) ну и т.п.
На вскидку только не нагуглил удачного обзора — если есть вопросы по конкретным схемам, могу поискать материал.

Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Кстати, не напомнишь ту ссылку, где ты бодался по поводу передачи пароля в открытом виде? Что-то не могу найти

DOO>Откопал-таки: http://rsdn.ru/forum/web/3611508.aspx. Я подозревал, что словосочетание "парольный эквивалент" не часто встречается на rsdn

Еще раз почитал...

— Жуткий город – девок нет, в карты никто не играет. Вчера в трактире спер серебряную ложку, никто даже не заметил – посчитали, что ее вообще не было.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.
Так и делаем. В соответствие с OWASP Secure Coding Practices:

Enforce account disabling after an established number of invalid logon attempts (e.g., five attempts is
common).

Правда там ниже:

The account must be disabled for a period of time sufficient to discourage brute force
guessing of credentials.

А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить.

Здравствуйте, adontz, Вы писали:

KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

A>Можно комментарий?

Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

A>Можно комментарий?

http://www.gotdotnet.ru/blogs/denish/1965/

в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Mazay, Вы писали:

KV>>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

A>>Можно комментарий?

M>Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.

Да не, я вот читал сей незабываемый труд
http://www.gotdotnet.ru/blogs/denish/1965/

Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. В таком случае привязываются к IP. То есть я не очень понимаю почему угадывание идентификатора сессии по известному идентификатору принципиально страшнее использования известного идентификатора как есть.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.
M>Так и делаем. В соответствие с OWASP Secure Coding Practices:
M>

M>Enforce account disabling after an established number of invalid logon attempts (e.g., five attempts is
M>common).

M>Правда там ниже:
M>

M>The account must be disabled for a period of time sufficient to discourage brute force
M>guessing of credentials.

Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS

M>А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить.

Сомневаясь насчет выделенного, все же соглашусь

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, adontz, Вы писали:

A>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.

Для доступа в чужую сесиию?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

A>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.
KV>Для доступа в чужую сесиию?

Ну если идентификатор чужой?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Уважаемые сабжы!

Злобненько. Хоть и справедливо

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

A>>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.
KV>>Для доступа в чужую сесиию?

A>Ну если идентификатор чужой?

Если идентификатор чужой, то как он оказался у тебя?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, kochetkov.vladimir, Вы писали:

k>> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется

AB>OpenID?

Далеко не всегда применимо и есть свои тараканы. Но направление — верное, да.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
C>Зависит от типа GUID'а.

Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.

C>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.

Я не силен в java... это оговорено в стандарте?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
C>>Зависит от типа GUID'а.

KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.

C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.

KV>Я не силен в java... это оговорено в стандарте?

JDK поддерживает версии 3 и 4 UUID

Здравствуйте, Курилка, Вы писали:

KV>>Я не силен в java... это оговорено в стандарте?

К>JDK поддерживает версии 3 и 4 UUID

Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
C>>Зависит от типа GUID'а.
KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.
Если в описании библиотеки написано, что генерация из secure random — не вижу проблем.

C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
KV>Я не силен в java... это оговорено в стандарте?
На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kochetkov.vladimir, Вы писали:

C>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
KV>>Я не силен в java... это оговорено в стандарте?
C>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.

JUG, кажись, позволяет генерить UUID и через MAC, только через JNI-вызовы вроде как.
Ну и товарищи из редмонда в методе Guid.NewGuid небось не забили на MAC-адрес (в MSDN ни строчки не нашёл про стандарты), а мелкомягкие технологии имеют довольно неплохую массу инерции

Здравствуйте, Cyberax, Вы писали:

C>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
KV>>Я не силен в java... это оговорено в стандарте?
C>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.

Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

C>>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
KV>>>Я не силен в java... это оговорено в стандарте?
C>>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.
KV>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
В существующих реализациях JDK — всё ОК. В теории, конечно, возможно — на эти библиотеки нет официального стандарта.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>9. Да-да, обязательно отражайте в логах все вводимые пароли. Потом, если внезапно рухнет база, ее можно будет легко по ним восстановить.

Ну по этому вопросу надо другим умникам обращение писать:

Подсистема регистрации и учета:

должна осуществляться регистрация входа (выхода) субъектов доступа в систему (из системы), либо регистрация загрузки и инициализации операционной системы и ее программного останова. Регистрация выхода из системы или останова не проводится в моменты аппаратурного отключения АС. В параметрах регистрации указываются:
— дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы;
— результат попытки входа: успешная или неуспешная — несанкционированная;
— идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа;
— код или пароль, предъявленный при неуспешной попытке;

Здравствуйте, kochetkov.vladimir, Вы писали:

A>>Ну если идентификатор чужой?

KV>Если идентификатор чужой, то как он оказался у тебя?

Успешный XSS, например. Мало ли способов.
Вообще это распространенная проблема, когда удержание сессии возможно потенциально бесконечное — что ты ни делай, хоть пароль меняй, хоть пользователя блокируй.

AB>OpenID?

Сразу вспоминается http://rsdn.ru/forum/web/3880202.aspx

Здравствуйте, kochetkov.vladimir, Вы писали:

A>>Ну если идентификатор чужой?

KV>Если идентификатор чужой, то как он оказался у тебя?

Троян, например.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет

только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью.

Вот мне почему-то кажется, что такие рассуждения применимы лишь в двух случаях:
— в некотором идеальном сферическом мире победивших роботов, где стоимость физического криминала на несколько порядков выше информационного, который за счёт цивилизованных действий всех сторон превращается в некое интеллектуальное состязание;
— в случае миллионов вконтактовских хомячков, где реальный ущерб от действий злоумышленников для каждого конкретного хомячка минимален, и все действия окупаются только за счёт массовости.

В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство. Но на первом месте — административный метод, сводящий всю криптостойкость к нулю за счёт "добровольного" раскрытия контента. Про blackberry ты же нам тут и рассказывал.

Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме) пример происходит сейчас в прямом эфире на roem.ru. Там разгорелся невиданный доселе огнесрач (отголоски которого можно наблюдать и здесь в разделах "о работе" и "предложения от прямых работодателей") нынешних и бывших сотрудников компании Infowatch (что это за компания, что они производят, думаю, объяснять тебе не надо — предполагается, что знания в технической, теоретической и правовой составляющих ИБ среднего сотрудника этой компании на порядок выше среднего по больнице). Как и на многих ресурсах, на роеме существует возможность писать сообщения анонимно, что многие и делают. Так вот, этот огнесрач очень быстро перешёл в стадию личных оскорблений. И вот в какой-то момент я вижу пост от одного из участников "дискуссии", активно защищающего руководство компании и являющегося сотрудником отдела внедрения компаннии (что-то средее между сейлзом и аналитиком), и (что очень важно) не являющегося сотрудником отдела внутренней ИБ:

2 Alter Ego Я отписался Вам на корпоративную почту. Жду Вас Только не нужно тут писать, что боитесь замараться. Вы это уже сделали 2 раза, теперь докажите, что не даром в штанах.

2 Саша которой удовлетворитель Честно удивлен, что это оказался именно ты

Т.е. внезапно он узнал личности собеседников. Вот интересный вопрос, как он смог это сделать. Ну да, вроде как они писали с рабочих компов, можно на шлюзе отследить все пакетики с dst=roem.ru && port=80. Но, ещё раз, это сотрудники компании, создающие решения для ИБ. Неужели они настолько тупы, чтобы писать гадости про руководство с рабочего компа, не шифруя траффик и т.д.? Разумеется, нет. Вряд ли даже, что они использовали внешние http/socks proxy. Как кто-то там предположил, у них, вероятно, поднят vpn до какого-то подконтрольного им сервера снаружи, откуда они и писали.
Как их можно вычислить? Ну, можно посмотреть всех, у кого наружу торчит поднятый vpn/ssh. Это значительно сузит круг подозреваемых, а потом пытаться анализировать содержимое записей, их стиль, соотносить число отправленных пакетов с временем постов и т.д. Вероятно, всё так и было. Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?! Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему?
Это реалии нашей жизни.

Так что шифруй, не шифруй — всё равно получишь практически одно и то же.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

A>>>Ну если идентификатор чужой?

KV>>Если идентификатор чужой, то как он оказался у тебя?

DOO>Успешный XSS, например. Мало ли способов.

Так а зачем нам XSS, если в данном случае, мы может просто подбирать все (почти все) идентификаторы, которые будут выданы после нас?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, frogkiller, Вы писали:

F>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет

только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью.
F>В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство.

С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны. Во-вторых, для того, чтобы воспользоваться этим средством, необходимо твое физическое присутствие рядом с атакуемым. Или не тебя. Но это уже куда дороже. В третьих, куда менее рискованно совершить преступление по 272ой или 273ей, находясь за сотни или тысячи километров от жертвы, нежели подписываться под вполне конкретные статьи УК, розыскная и судебная практика по которым значительно обширнее, чем по хайтековским статьям.

F>Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме)

Обсуждаемая тема — парольная аутентификация, если что.

F>Т.е. внезапно он узнал личности собеседников.

Или сделал вид, что узнал, между прочим. Вообще, чтение той темы оставило на мой, дилетантский взгляд, ощущение значительного превосходства количества ников над количеством реально отписывающихся там людей.

F>Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?!

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

F>Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему?

Нет конечно, по целому ряду причин. Но я — это я, а сотрудники ИВ — это сотрудники ИВ. Там может быть все, что угодно.

F>Так что шифруй, не шифруй — всё равно получишь практически одно и то же.

Отлаживай, не отлаживай — все равно каждый баг будет предпоследним

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?

A>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.

Я на выходных обычно впадаю в туплячку... А что это нам даст?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>

DOO>- код или пароль, предъявленный при неуспешной попытке;

Я писал все больше про успешные. А с отказами — тут палка о двух концах. С одной стороны — куда более качественная доказательная база из логов получается, случись вдруг что. С другой стороны, любой, кто имеет доступ к логам получит возможность существенно сузить количество перебираемых вариантов за счет анализа неуспешных попыток легальных пользователей. В принципе, можно шифровать все неправильные пароли ассиметрией, но это уже может вызвать вопросы у других умников

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.

SH>Ещё посолить неплохо бы.

И растянуть

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

SH>>Ещё посолить неплохо бы.

KV>И растянуть

Я не знаю, что это значит

Объясни?

Здравствуйте, frogkiller, Вы писали:

f> Т.е. внезапно он узнал личности собеседников. Вот интересный вопрос, как он смог это сделать.

Обычно на тонущем корабле никто и не шифруется особо ху-из-ху.

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет

только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью.
F>>В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство.

KV>С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны.

Ты, вероятно, имел ввиду ПД атакуемого.
Выше я приводил 2 случая применимости твоих рассуждений. Да, в случае "вконтактовского хомячка" персональные данные можно считать весьма условными, как и в случае с разными автоматическими вирусами/троянами, для которых раскрытие ПД жертвы — следствие их работы. Но, ещё раз, последствия таких атак для хомячка обычно очень небольшие.

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

Э... не обязательно с атакуемым. Цепочка, по которой проходят запросы от жертвы до сервера, обычно достаточно длинная. В некоторых случаях это может снизить цену физического присутствия в несколько раз.
И опять хочу подчеркнуть, что в основном рассматриваю существенные преступления — типа хищения миллиона баксов со счёта в банке, вскрытие базы данных центральной избирательной комиссии, перехват почты с обсуждением газовых контрактов и т.д. По сравнению с ними цена физических действий сильно ниже.
А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то

KV>В третьих, куда менее рискованно совершить преступление по 272ой или 273ей, находясь за сотни или тысячи километров от жертвы, нежели подписываться под вполне конкретные статьи УК, розыскная и судебная практика по которым значительно обширнее, чем по хайтековским статьям.

Насколько я знаю, "хайтековские статьи" не являются основными, а идут в довесок к тем самым вполне конкретным статьям УК. Небольшая практика по ним, скорее, следствие низкой социальной опасности. (Я уверен, что если вдруг действия злоумышленников реально затронут интересы властей, то и розыскные и судебные мероприятия будут молниеносными)

F>>Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме)
KV>

Обсуждаемая тема — парольная аутентификация, если что.

Ну, во-первых, я указал на полуоффтопичность

А. во-вторых, так я хотел продемонстрировать, как наличие административной составляющей сводит на нет все криптографические усилия.

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

F>>Т.е. внезапно он узнал личности собеседников.

KV>Или сделал вид, что узнал, между прочим. Вообще, чтение той темы оставило на мой, дилетантский взгляд, ощущение значительного превосходства количества ников над количеством реально отписывающихся там людей.

Ну да. Часть сообщений под авторизованными никами, часть под "Alter Egо" — это такая модная замена здешнего слова "Anonim". Там при посылке поста есть галочка "опубликовать анонимно", тогда ник заменяется этим словом — для всех.

F>>Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?!
KV>Даже если фишка с последующим разоблачением правда, то она могла попасть к нему кучей способов. Слишком мало информации, чтобы предметно фантазировать на эту тему

Вот у меня не получается придумать _хороших_ способов

F>>Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему?
KV>Нет конечно, по целому ряду причин. Но я — это я, а сотрудники ИВ — это сотрудники ИВ. Там может быть все, что угодно.

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

F>>Так что шифруй, не шифруй — всё равно получишь практически одно и то же.
KV>Отлаживай, не отлаживай — все равно каждый баг будет предпоследним

Далеко не предпоследним

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

Здравствуйте, DOOM, Вы писали:

KV>>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS

DOO>Ну для этого и капча и ограничения per IP и все такое...

Публичные прокси и антикапча. Ваш ход.

Здравствуйте, tlp, Вы писали:

DOO>>Ну для этого и капча и ограничения per IP и все такое...

tlp>Публичные прокси и антикапча. Ваш ход.

Блокировать прокси по тем же листам

Использовать WAF'ы с динамической блокировкой по IP и т.п.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.

2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, tlp, Вы писали:

DOO>>>Ну для этого и капча и ограничения per IP и все такое...

tlp>>Публичные прокси и антикапча. Ваш ход.

DOO>Блокировать прокси по тем же листам

по каким? "публичные прокси" — это не "прокси из публичных прокси-листов", а "прокси, которые позволяют себя использовать всем, без исключения". Ищутся/покупаются/делаются легко, списков не существует.
(http://www.google.ru/search?hl=ru&newwindow=1&client=opera&hs=Uk0&rls=en-GB&&sa=X&ei=qeyDTOmnLMKZOP2voLUO&ved=0CCIQBSgA&q=%D0%BA%D1%83%D0%BF%D0%BB%D1%8E+%D1%81%D0%BE%D0%BA%D1%81%D1%8B&spell=1)

DOO>Использовать WAF'ы с динамической блокировкой по IP и т.п.
Как именно это поможет в случае с со списокм из 10к проксей?

Здравствуйте, tlp, Вы писали:

tlp>(http://www.google.ru/search?hl=ru&newwindow=1&client=opera&hs=Uk0&rls=en-GB&&sa=X&ei=qeyDTOmnLMKZOP2voLUO&ved=0CCIQBSgA&q=%D0%BA%D1%83%D0%BF%D0%BB%D1%8E+%D1%81%D0%BE%D0%BA%D1%81%D1%8B&spell=1)
Банятся они также легко

DOO>>Использовать WAF'ы с динамической блокировкой по IP и т.п.
tlp>Как именно это поможет в случае с со списокм из 10к проксей?
А ему какая разница сколько IPшников блокировать?
И еще надо один момент понимать — много чести для банального брутфорса заморачиваться с такими сложностями. Кто так заморочится — сможет найти более действенный вариант увода чужого пароля.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, tlp, Вы писали:

tlp>>(http://www.google.ru/search?hl=ru&newwindow=1&client=opera&hs=Uk0&rls=en-GB&&sa=X&ei=qeyDTOmnLMKZOP2voLUO&ved=0CCIQBSgA&q=%D0%BA%D1%83%D0%BF%D0%BB%D1%8E+%D1%81%D0%BE%D0%BA%D1%81%D1%8B&spell=1)
DOO>Банятся они также легко

DOO>>>Использовать WAF'ы с динамической блокировкой по IP и т.п.
tlp>>Как именно это поможет в случае с со списокм из 10к проксей?
DOO>А ему какая разница сколько IPшников блокировать?
DOO>И еще надо один момент понимать — много чести для банального брутфорса заморачиваться с такими сложностями. Кто так заморочится — сможет найти более действенный вариант увода чужого пароля.

Причем тут брутфорс?

Разговор идет про DoS с блокированием аккаунтов юзерам, вы предложили решение, оно не работает в случае проксей и антикапчи.

KV>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS

Здравствуйте, tlp, Вы писали:

tlp>Причем тут брутфорс?
tlp>Разговор идет про DoS с блокированием аккаунтов юзерам, вы предложили решение, оно не работает в случае проксей и антикапчи.

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

Здравствуйте, ArhAngelVezel, Вы писали:

KV>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.

AAV>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?

Отжимаем у жертвы телефон. Если жертва этого не заметит и запросит OTP на теперь уже наш телефон — profit, мы в системе. Если заметит, но не сразу побежит блокировать sim’ку — у нас есть окно, в течение которого мы можем запросить восстановление основного пароля, и снова profit. В любом случае, мы заDoSили жертву до момента получения новой sim’ки.

Кроме того, мы можем заранее заразить комп юзера кейлоггером/сниффером/BHO, или же устроить man-in-the-middle на канал между компом юзера и сервером, или же заспуфить сервер и заманить юзера на подделку, и спереть его пароль. В этом случае мы можем попасть в систему, даже если восстановление основного пароля на телефон не предусмотрено, пока юзер блокирует и меняет sim’ку.

Здравствуйте, Centaur, Вы писали:

AAV>>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?

C>Отжимаем у жертвы телефон. Если жертва этого не заметит и запросит OTP на теперь уже наш телефон — profit, мы в системе. Если заметит, но не сразу побежит блокировать sim’ку — у нас есть окно, в течение которого мы можем запросить восстановление основного пароля, и снова profit. В любом случае, мы заDoSили жертву до момента получения новой sim’ки.

1. В хорошей системе OTP приходит с мобильного номера зашифрованное в несколько несвязных друг с другом слов. Понять что это за слова сложно.
2. Маска, темный переулок и горячий паяльник работают в разы эффективней. В данной же схеме мы видим больше социальную инженерию, чем кибер-атаку..

C>Кроме того, мы можем заранее заразить комп юзера кейлоггером/сниффером/BHO, или же устроить man-in-the-middle на канал между компом юзера и сервером, или же заспуфить сервер и заманить юзера на подделку, и спереть его пароль. В этом случае мы можем попасть в систему, даже если восстановление основного пароля на телефон не предусмотрено, пока юзер блокирует и меняет sim’ку.

Это делается и в случае с "постоянным паролем". С OTP через сим мы гарантируем, что вход юзвера будет единичным.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

AVK>Чем гуид не угодил? Слабый алгоритм генерации случайного числа?

Ага

AVK>А что вместо него, если криптостойкий генератор в конкретной платформе недоступен?

Берешь нестойкий GUID и sha-512-ишь его случайное число раз. Проверяешь, нет ли уже сессии с таким айдишником (мало-ли, свойство уникальности в этом случае может и нарушаться) и, если нет, то выдаешь в качестве айдишника. Если есть, то еще несколько раз sha-512-тишь и, см. выше.

KV>>14. Капча — зло.

AVK>Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.

Там где нет рисков, связанных с автоматическими регистрациями, там и капча не нужна. Там где есть, альтернатив ей особо пока и нет

Мы — хороший тому пример

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>Мое мнение здесь однозначное — если распределенная система способна определить "код или пароль, предъявленный при неуспешной попытке", то у нее уже кривая схема аутентификации (правда здесь я бы не понят с такой точкой зрения

).

Да брось, тебя я в той теме поддерживал и еще несколько участников, так что все ок

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>Дело в том, что целенаправленно блокировать аккаунты — это какое-то странное занятие. Профит где?

Это тот же DoS, вид с боку. Какой профит от DoS'а? Шантаж, борьба с конкурентами и т.п.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, frogkiller, Вы писали:

KV>>С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны.

F>Ты, вероятно, имел ввиду ПД атакуемого.

Да, конечно

F>Выше я приводил 2 случая применимости твоих рассуждений. Да, в случае "вконтактовского хомячка" персональные данные можно считать весьма условными, как и в случае с разными автоматическими вирусами/троянами, для которых раскрытие ПД жертвы — следствие их работы. Но, ещё раз, последствия таких атак для хомячка обычно очень небольшие.

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

F>Э... не обязательно с атакуемым. Цепочка, по которой проходят запросы от жертвы до сервера, обычно достаточно длинная. В некоторых случаях это может снизить цену физического присутствия в несколько раз.
F>И опять хочу подчеркнуть, что в основном рассматриваю существенные преступления — типа хищения миллиона баксов со счёта в банке,

Чуть выше, я привел ссылку, где описывается атака отнюдь не на хомячков и где наличия ПДн и дырки в парольной защите банка оказалось достаточно, чтобы успешно ее провести. Физического присутствия рядом с атакуемымии не потребовалось, что характерно. Не миллион баксов, конечно, но тем не менее. Впрочем, и миллионы тоже были (вспоминаем ситибанк и сколько из похищенного ему удалось вернуть).

Тех парней (поимевших Альфа-банк), кстати, так и не нашли, AFAIK. Но и их тела тоже, если что.

F>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то

Либо разломают через него Альфа банк...

F>Насколько я знаю, "хайтековские статьи" не являются основными, а идут в довесок к тем самым вполне конкретным статьям УК.

Нет, это не так. Если совершается мошенничество с применением вредоносного ПО, то осуждают по 159-ой, а в довесок цепляют 273-ью. Если был осуществлен неправомерный доступ к информации через мошенничество, то осуждают по 272-ой, а в довесок идет 159-ая. Зависит только от того, на что был направлен умысел совершившего преступление.

F>Небольшая практика по ним, скорее, следствие низкой социальной опасности. (Я уверен, что если вдруг действия злоумышленников реально затронут интересы властей, то и розыскные и судебные мероприятия будут молниеносными)

Интересами властей в области хайтека у нас занимается ведомство, несколько отличающееся от БСТМ. Хотя бы тем, что у них аббревиатура чуть короче

F>Ну, во-первых, я указал на полуоффтопичность

А. во-вторых, так я хотел продемонстрировать, как наличие административной составляющей сводит на нет все криптографические усилия.

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

F>Вот у меня не получается придумать _хороших_ способов

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

F>Тут очень тонкий момент, достойный отдельного обсуждения. С такой просьбой может прийти не простой сотрудник, а "большая шишка". И аргументация просьбы может быть очень разная, например, что в этих постах раскрыта важная информация, покрываемая NDA.

Большая шишка не может подойти ко мне с такой просьбой. Только мой непосредственный шеф (специфика управления ИБ в нашей конторе). Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что

F>>>Так что шифруй, не шифруй — всё равно получишь практически одно и то же.
KV>>Отлаживай, не отлаживай — все равно каждый баг будет предпоследним

F>Далеко не предпоследним

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

Хочешь сказать, что эти 15 пунктов (даже 14, т.к. один там просто про отношение к безопасникам) попахивают паранойей? И это при том, что еще про 12 я решил не писать?!

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

A>>>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.
KV>>Я на выходных обычно впадаю в туплячку... А что это нам даст?

A>Даже при условии предсказуемости, теперь надо предсказать поведение сразу двух компьютеров в фиксированные моменты времени. Причём о клиентском информации нет.

Пока на всякий случай согласился, но еще подумаю над этим предметнее

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, ArhAngelVezel, Вы писали:

AAV>>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.

AAV>>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?

KV>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

Поясни, в чём тут "пересечение"?

Здравствуйте, kochetkov.vladimir, Вы писали:

F>>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то

KV>Либо разломают через него Альфа банк...

Использовать для таких вещей ботнеты из позользовательских машин — довольно рискованное занятие, в любой момент может отключиться. Уж лучше через тот же gprs с телефона, зарегистриованного на какого-нибудь бомжа. И то, что через день место звонка будут обследовать куча людей с собаками — фигня, а быстрее с нуля без предварительной разработки вряд ли можно отреагировать, какие бы крутые спецслужбы не были.

KV>Та тема вообще ничего не доказывает. Повторюсь, она может быть как целиком и полностью фантазией двух-трех человек, захотевшись развести черный пиар в адрес ИВ, так и частично, с той же целью

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

Не-не-не. Административная составляющая в данном случае зло не потому, что плохо организована. А в силу самих предоставляемых возможностей. И я хотел показать, что это не обязательно исходит от государства (как в примере с blackberry), это может быть на всех уровнях.
Наличие возможности "специально обученным людям" иметь доступ к части системы в обход общей защиты автоматически означает, что на первое место выходит человеческий фактор, и, как следствие, основная угроза — в виде ли паяльника, неуставных отношений, подкупа или социальной инженерии — не важно, — идёт оттуда.

F>>Тут очень тонкий момент, достойный отдельного обсуждения. С такой просьбой может прийти не простой сотрудник, а "большая шишка". И аргументация просьбы может быть очень разная, например, что в этих постах раскрыта важная информация, покрываемая NDA.
KV>Большая шишка не может подойти ко мне с такой просьбой. Только мой непосредственный шеф (специфика управления ИБ в нашей конторе).

Очень рад за вашу контору.

KV>Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что

А с какой целью он их просит? Что если большая шишка пришёл к нему

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

KV>Хочешь сказать, что эти 15 пунктов (даже 14, т.к. один там просто про отношение к безопасникам) попахивают паранойей? И это при том, что еще про 12 я решил не писать?!

Угу. Уровень технической безопасности, имхо, должне соотвтетствовать уровню человеческого фактора. Сначала людям нужно привить культуру обращения с информацией, причём всем людям, а не отдельным высокоморальным личностям, а потом только подгонять средства защиты. В противном случае никакого реального профита от крутой криптографии и сложных многоуровневых систем аутентификации не будет. А будет просто лишний геморрой разработчикам, которым в условиях жёстких проектных сроков придёт делать существенно больший объём работ — "для галочки".

Здравствуйте, SergH, Вы писали:

SH>Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.

А, там ещё и основной можно (было) узнать разве? Это "весело", конечно...

Здравствуйте, Курилка, Вы писали:

К>А, там ещё и основной можно (было) узнать разве? Это "весело", конечно...

Я кусочек статьи процитировал, там пострадавший как раз на эту тему возмущается. Он говорит, что да, можно. А больше я ничего про Альфа-банк не знаю

Здравствуйте, frogkiller, Вы писали:

F>Здравствуйте, kochetkov.vladimir, Вы писали:

F>>>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то

KV>>Либо разломают через него Альфа банк...

F>Использовать для таких вещей ботнеты из позользовательских машин — довольно рискованное занятие, в любой момент может отключиться.

Весь ботнет разом? И если таки-да, в чем риск-то?

F>Уж лучше через тот же gprs с телефона, зарегистриованного на какого-нибудь бомжа. И то, что через день место звонка будут обследовать куча людей с собаками — фигня, а быстрее с нуля без предварительной разработки вряд ли можно отреагировать, какие бы крутые спецслужбы не были.

Меня всегда улыбали подобные рассуждения, больше характерные для технарей. Ну переведешь ты со обчищаемого счета нужное тебе количество денежных средств (кстати, куда переведешь-то?). Выводить как будешь? А обналичивать? А тратить?

Я это к тому, что если на "разломают Альфа-банк" смотреть не как на "получат доступ к чужому счету, покрутятся и уйдут" (нафига оно кому-то нужно?), а как на "завладеют денежными средствами клиентов Альфа-банка", то резко появляется огромное количество мест, где могут остаться следы по которым тебя смогут взять за известное место.

F>Наличие возможности "специально обученным людям" иметь доступ к части системы в обход общей защиты автоматически означает, что на первое место выходит человеческий фактор,

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

F> и, как следствие, основная угроза — в виде ли паяльника, неуставных отношений, подкупа или социальной инженерии — не важно, — идёт оттуда.

И?

KV>>Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что

F>А с какой целью он их просит? Что если большая шишка пришёл к нему

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

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

F>Уровень технической безопасности, имхо, должне соотвтетствовать уровню человеческого фактора. Сначала людям нужно привить культуру обращения с информацией, причём всем людям, а не отдельным высокоморальным личностям, а потом только подгонять средства защиты.

Я не совсем понимаю, о чем ты пытаешься спорить? Культуру безусловно прививать нужно, но разве это задача разработчиков систем? Думаю что нет. А вот приблизительный список того, что требуется от разработчиков (и только от них) я и озвучил

F>В противном случае никакого реального профита от крутой криптографии и сложных многоуровневых систем аутентификации не будет. А будет просто лишний геморрой разработчикам, которым в условиях жёстких проектных сроков придёт делать существенно больший объём работ — "для галочки".

"Каждый пользователь ИС должен быть успешно идентифицирован и аутентифицирован на основании введенного им пароля до разрешения любого действия в системе."

Знакомая строчка из ТЗ? Вот список из исходного сообщения и есть необходимый (но не всегда достаточный) перечень того, что нужно учесть при реализации процитированного требования. Невыполнение одного из этих 14 пунктов сведет на нет всю работу по реализации системы аутентификации по одной простой причине: в этом случае она (аутентификации) не будет успешной, что будет доказано на первом же тесте на проникновение. Вот и все, не более, но и не менее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>Гораздо проще ломануться ботнетом на произвольную страничку ресруса и повалить его этим

DOO>Стоимость такого DDoS'а настолько смешна, что выдумывать что-то другое профита уж точно нет...

Если этой страничкой будет форма аутентификации, на которую ноды ботнета будут слать POST-запросы с левыми паролями, перебирая при этом все возможные логины, то ущерб от такой атаки будет на порядок существеннее из-за того, что помимо отказа в обслуживании на уровне канала передачи данных и/или сервера приложений, будет также иметь место отказ в обслуживании на уровне подсистемы аутентификации.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Курилка, Вы писали:

KV>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

К>Поясни, в чём тут "пересечение"?

Выше уже пояснили. Раньше (как сейчас — увы не знаю, давно свои пароли не забывал) когда клиент Альфа-банка забывал пароль на https://click.alfabank.ru, то его восстанавливали по звонку, отправкой нового пароля SMS'ом на телефон клиента. Т.е. тем же самым способом, что и сеансовый.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Собственно, просьбы:
Собственно из личного юзерского опыта — чем параноидальнее сайт, тем чаще пароли приходится записывать на бумажке и вешать на монитор

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>"Параноидальнее" — не очень правильная оценка. Если сайт предоставляет пользователю какие-либо сервисы и при этом особо не обещает каких-либо мер, направленных на защиту пользовательского аккаунта, то излишнее закручивание гаек в плане требований к паролю там будет вряд ли уместно. Если пользователь захочет — он сам обеспечит себе определенную степень защиты, используя стойкий пароль. Если нет, то его можно предупредить об этом, но не более того.
KV>Если же сайт берет на себя определенные обязательства, как в случае с Альфа-банком, либо безопасность сайта находится в некоторой зависимости от безопасности аккаунта пользователя (так тоже бывает), то и обязательные требования к паролям должны быть жестче, чтобы сайт имел возможность эти требования выполнить либо обеспечить свою безопасность.
KV>Кроме того, я считаю, что проблема "пользователи не могут запоминать стойкие пароли" несколько надумана. Правильнее было бы говорить о проблеме "пользователи не хотят запоминать стойкие пароли". Пароль, который я использую на этом сайте выглядит примерно так: ~rM@0%s_jR4q| при этом он довольно стойкий (энтропия около 80 бит), учитывая его периодическую замену, т.к. безопасность моего аккаунта кореллирует с безопасностью всего сайта. Но на его запоминание у меня ушло от силы полчаса. Не думаю, что мои мнемонические навыки развиты как-то сильно особенно по сравнению со всеми остальными.
KV>Для некоторых других сайтов и систем я использую менее стойкие, но легко запоминающиеся пароли, для некоторых (типа ибанкинга, админских аккаунтов на VDS и т.п.) — гораздо более сложнее приведенного. Но у меня ни разу не возникало проблем с их запоминанием, даже с учетом их регулярной замены в случае с некоторыми сайтами или системами

А вот мой юзерский экспиренс несколько иной.
Возьмем интернет банки. Пару-тройку лет назад у меня была следующая ситуация: я держал свой основной счет в одном банке, а зарплатный проект у меня был в другом банке.
И тот и другой обладали интернет банками (кстати, оба неплохие, а во втором банке это был лучший в России интернет банк по версии какого-то там конкурса).
В общем на тот момент первый банк я использовал для выплаты ипотечного взноса. В общем-то только по той причине, что на нем я консолидировал основные средства, а на зарплатный счет тогда мне поступало недостаточно средств для выплаты взноса (шла только официальная часть з/п, которая у меня тогда была порядка половины от всей з/п).
И вот я пользовался интернет банком того первого банка ровно раз в месяц — для выплаты ипотечного взноса. При этом там система логин/пароль + одноразовые ключи. Пароль надо менять раз в 3 месяца. К паролю предъявляются определенные требования сложности (по-моему не менее 6-ти символов, обязательное наличие цифры или спецсимвола). Пароли не могут повторяться никогда.
Один раз это привело к тому, что я забыл пароль напрочь. Потому что это невозможно — использовать пароль 3 раза (причем с перерывом в месяц) а потом выдумать новый. Забыв пароль я добился своей блокировки в системе (сначала на 2 часа, потом на 4, а потом на какое-то нереальное время). Пошел в представительство, меня разблокировали — заплатил. Однако, это заставило меня сильно побегать (был риск просрочки ипотечного платежа).

Во втором же интернет банке все было проще — у меня была флешка с сертификатом, закрытым ключом (зашифрованным) + софтом для доступа к интернет банку (интер-про).
Никаких одноразовых ключей, постоянных смен пароля и т.п. При этом общая защищенность второй системы даже выше (кстати, сейчас тот первый банк купил интернет банк того второго банка, который был уничтожен альфой в конце 2008, которые оказались полными м..ками и выкинули на ~~помойку~~ продажу лучшие в России интернет и SMS банки. После покупки они доработали этот интернет банк и теперь там, вроде, можно использовать USB токены вместо флешек и, вроде бы, еще и с аппаратной реализацией гостового алгоритма — т.е. ключ носитель не покидает никогда).

Вывод: пароли вообще не стоит применять там, где нужна шибко непробиваемая защита. Есть много других методов аутентификации, которые уже давно стали более, чем доступны по цене (я уж молчу, что сертифицированный в ФСБ токен с родной криптографией удовлетворяет закону об ЭЦП, в отличие от).

Здравствуйте, DOOM, Вы писали:

DOO>это невозможно — использовать пароль 3 раза (причем с перерывом в месяц) а потом выдумать новый.

Невозможно. Если только при конструировании пароля тобой не используется какая-нибудь функция, скажем от периода действия пароля. Ну например:

fG)4)5)6!0Pe+3 пароль на апрель, май и июнь
fG)7)8)9!0Pe+3 он же на июль, август и сентябрь

но все равно муторно, согласен. Фишка в том, что помнить целесообразно (и легко) только часто используемые пароли. Остальные — помнить не нужно, да и не очень реально.

DOO>кстати, сейчас тот первый банк купил интернет банк того второго банка, который был уничтожен альфой в конце 2008, которые оказались полными м..ками и выкинули на ~~помойку~~ продажу лучшие в России интернет и SMS банки. После покупки они доработали этот интернет банк и теперь там, вроде, можно использовать USB токены вместо флешек и, вроде бы, еще и с аппаратной реализацией гостового алгоритма — т.е. ключ носитель не покидает никогда).

Нифига не понял, кто кого купил и выкинул, но последнюю фразу одобряю

DOO>Вывод: пароли вообще не стоит применять там, где нужна шибко непробиваемая защита. Есть много других методов аутентификации, которые уже давно стали более, чем доступны по цене (я уж молчу, что сертифицированный в ФСБ токен с родной криптографией удовлетворяет закону об ЭЦП, в отличие от).

С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что. А это (по личному опыту) далеко не всегда легко и дешево.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что.
Нет такой лицензии. Получать заставят лицензию на тех. обслуживание (хотя и тут есть способы отъехать). Не сказал бы, что это сложно.

KV>А это (по личному опыту) далеко не всегда легко и дешево.
Ну значит у вас УФСБ какое-то зверское. У нас это достаточно просто.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что.
DOO>Нет такой лицензии. Получать заставят лицензию на тех. обслуживание (хотя и тут есть способы отъехать). Не сказал бы, что это сложно.

Я имел ввиду, пакет лицензий, связанных с эксплуатацией шифросредств, т.к. в описываемом тобой случае совершенно точно понадобятся лицензиии на:

а) распространение шифросредств (т.к. ключи будут являться неотъемлемой частью поставляемого продукта / сервиса);
б) их же техобслуживание (и как с этого съехать, учитывая что это в т.ч. "работы по обслуживанию шифровальных (криптографических) средств, предусмотренные технической и эксплуатационной документацией на эти средства" я хз. Допускаю, что можно, буду рад узнать как).
в) на предоставление услуг в области шифрования, в том случае, если ключи для клиентов будут генерироваться не поставщиком криптосредств, а в результате его эксплуатации сотрудниками компании.

KV>>А это (по личному опыту) далеко не всегда легко и дешево.
DOO>Ну значит у вас УФСБ какое-то зверское. У нас это достаточно просто.

Если выполнены требования, предъявляемые к соискателю — у нас тоже. Если нет, то их выполнение может влететь в копеечку. Хотя, конечно, для компании уровня банка, она так копеечкой и останется.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, andy1618, Вы писали:

KV>>1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите

A>Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего:
A>==
A>

Здравствуйте, ...!

A>С большим удовольствием сообщаем,
A>что в основной ассортимент футболок добавлены 6 новых цветов!

A>...

A>Доступ в личный кабинет:
A>Имя пользователя: ...
A>Пароль: ...

A>==
A>

Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте? Даже если они позволяют рассчитываться карточками, а не налом курьеру, то работают через какую-то платежку, а там все защищено. Узнать, сколько и каких футболок покупал юзер на лето? Инфа забавная, но абсолютно бесполезная.

Здравствуйте, adontz, Вы писали:

KV>>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?

A>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.

Кстати, Опера Мини так решала проблему на мобилках(там с рандомом туго): при установке просила юзера случайно потыкать клавиатуру телефона

Здравствуйте, Eugeny__, Вы писали:

E__>Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте?
Скорее всего он даст взлом еще кучи аккаунтов в аське, почте и прочих контактах с одноклассниками.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

А где там пересечение вне банка?
Описанный случай — не электронное мошенничество. Я полагаю, инсайд + подделка документов.

KV>Самое забавное было в этой истории то, что незадолго до начала хищений, Альфа-банк сертифицировался на соответствие PCI DSS (http://www.itsec.ru/newstext.php?news_id=53489). Но пересечение каналов передачи основного и сеансового пароля почему-то в ходе сертификации выявлено не было

Ну, во-первых, правила PCI DSS не такие уж и жесткие. Мы прошли аудит менее чем за полгода и довольно легко, почти без отрыва от прочих дел(но у нас безопасник параноик изначально). Правила, оговоренный там, не являются особо параноидальными, просто не дают возможность использовать совсем уж дырявые каналы/алгоритмы(четсно, лично я эту огромную простыню не читал, говорю по впечатлению коллег). А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.

Здравствуйте, DOOM, Вы писали:

E__>>Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте?
DOO>Скорее всего он даст взлом еще кучи аккаунтов в аське, почте и прочих контактах с одноклассниками.

Только есливыполняются:
1. Юзер на всех сайтах/ресурсах использует один и тот же пароль
2. Пароль на сайте футболок был введен пользователем, а не автоматом сгенерен.

Здравствуйте, Eugeny__, Вы писали:

E__>Для магазина футболок, имхо, в этом нет ничего страшного.

1. В личном кабинете пользователя вероятнее всего есть его персональные данные и физические адреса доставки. Это информация подлежит обязательной защите в соответствии с действующим законодательством. Т.е. в случае взлома и обращения пользователя в соответствующие структуры, у магазина будут серьезные проблемы.

2. Футболки бывают разные. Мало кому из клиентов будет приятно узнать, что инфа о таких его заказах вышла за пределы магазина. Хотя геи и лесби наверное тоже бывают разные, не спорю

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, SergH, Вы писали:

KV>>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

К>>Поясни, в чём тут "пересечение"?

SH>

SH>Основную вину за кражу денег потерпевшие возложили на банк. "Альфа-банк допустил халатность при разработке системы безопасности для удаленной работы со счетами. Ну как можно обеспечить сохранность наших средств, если банк высылает постоянный пароль и пароли на операции по счетам с помощью SMS", — возмущается Андрей.

SH>Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.

А вот это уже бред, да.

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

E__>А где там пересечение вне банка?

Я выше пояснял.

E__>Описанный случай — не электронное мошенничество. Я полагаю, инсайд + подделка документов.

Инсайд там не был нужен. Разве что только для того, чтобы выбрать тех, кто имеет достаточные суммы на счетах. Но эту инфу и без инсайда вполне могли достать. Если бы основной пароль не отправлялся при восстановлении через SMS, то и кража подобным способом была бы невозможной.

KV>>Самое забавное было в этой истории то, что незадолго до начала хищений, Альфа-банк сертифицировался на соответствие PCI DSS (http://www.itsec.ru/newstext.php?news_id=53489). Но пересечение каналов передачи основного и сеансового пароля почему-то в ходе сертификации выявлено не было

E__>Ну, во-первых, правила PCI DSS не такие уж и жесткие. Мы прошли аудит менее чем за полгода и довольно легко, почти без отрыва от прочих дел(но у нас безопасник параноик изначально). Правила, оговоренный там, не являются особо параноидальными, просто не дают возможность использовать совсем уж дырявые каналы/алгоритмы(четсно, лично я эту огромную простыню не читал, говорю по впечатлению коллег).

Рекомендую почитать, там не так уж и много. Паранойи нет, но стандарт достаточно сильный.

E__>А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.

Тех парней так и не нашли. Это к вопросу о зацепках. Что же касается стандарта, то там есть четкое требование:

8.2 Помимо идентификатора, должен применяться хотя бы один из следующих методов для аутентификации всех пользователей:
— Пароль.
— Двухфакторная аутентификация (ключи, смарт-карты, биометрические параметры, открытые ключи).

Так вот двухфакторная аутентификация подразумевает передачу пользователю обоих ключей по различным каналам (в противном случае в ней просто нет смысла и она является не более чем способом осложнить жизнь рядовым пользователям). Кстати, там же есть еще одно требование:

8.4. Все пароли должны храниться и передаваться только в зашифрованном виде с использованием стойких криптографических алгоритмов.

которое также нарушалось, однако аудиторами этот факт также замечен не был.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427

E__>>А где там пересечение вне банка?

KV>Я выше пояснял.

E__>>Описанный случай — не электронное мошенничество. Я полагаю, инсайд + подделка документов.

KV>Инсайд там не был нужен. Разве что только для того, чтобы выбрать тех, кто имеет достаточные суммы на счетах. Но эту инфу и без инсайда вполне могли достать. Если бы основной пароль не отправлялся при восстановлении через SMS, то и кража подобным способом была бы невозможной.

Ну это они отожгли, да. Я просто и не подумал, что основной пароль может отправляться через СМС, через который же и получаешь одноразовый. Так что тут согласен.

KV>>>Самое забавное было в этой истории то, что незадолго до начала хищений, Альфа-банк сертифицировался на соответствие PCI DSS (http://www.itsec.ru/newstext.php?news_id=53489). Но пересечение каналов передачи основного и сеансового пароля почему-то в ходе сертификации выявлено не было

E__>>Ну, во-первых, правила PCI DSS не такие уж и жесткие. Мы прошли аудит менее чем за полгода и довольно легко, почти без отрыва от прочих дел(но у нас безопасник параноик изначально). Правила, оговоренный там, не являются особо параноидальными, просто не дают возможность использовать совсем уж дырявые каналы/алгоритмы(четсно, лично я эту огромную простыню не читал, говорю по впечатлению коллег).

KV>Рекомендую почитать, там не так уж и много. Паранойи нет, но стандарт достаточно сильный.

Эх, будет время...

E__>>А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.

KV>Тех парней так и не нашли. Это к вопросу о зацепках.

См. выделенное.

KV>Что же касается стандарта, то там есть четкое требование:

KV>

KV>8.2 Помимо идентификатора, должен применяться хотя бы один из следующих методов для аутентификации всех пользователей:
KV>- Пароль.
KV>- Двухфакторная аутентификация (ключи, смарт-карты, биометрические параметры, открытые ключи).

KV>Так вот двухфакторная аутентификация подразумевает передачу пользователю обоих ключей по различным каналам (в противном случае в ней просто нет смысла и она является не более чем способом осложнить жизнь рядовым пользователям).

Вполне логичное требование.

Здравствуйте, Eugeny__, Вы писали:

KV>>Рекомендую почитать, там не так уж и много. Паранойи нет, но стандарт достаточно сильный.
E__>Эх, будет время...

Начать можно с этого: http://www.pcidss.ru/files/pub/pdf/pcidss_v1.2_russian.pdf В принципе, этим можно и закончить, если нет желания углубляться в детали и существующие практики.

E__>>>А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.

KV>>Тех парней так и не нашли. Это к вопросу о зацепках.

E__>См. выделенное.

Ну не знаю. Банк возместил все средства клиентам за свой счет (в этом плане АБ крайне заботится о своем лице. Когда их банкомат принял у меня 10 штук и, радостно хрюкнув, попрощался, а деньги на счет так и не перевел и чек не распечатал, мне их вернули на следующий день после оформления претензии).

По идее, желание заморочиться у АБ должно было возникнуть

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>А вот мой юзерский экспиренс несколько иной.

Буду потихоньку делиться своим:Политика управления персональными паролями

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Буду потихоньку делиться своим:Политика управления персональными паролями

Спасибо по...читал.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>

KV>8.4. Все пароли должны храниться и передаваться только в зашифрованном виде с использованием стойких криптографических алгоритмов.

KV>которое также нарушалось, однако аудиторами этот факт также замечен не был.
Лично у меня есть подозрение, что пароли
а) хранятся на стороне АБ только в зашифрованном виде (если вообще) и
б) передача через SMS означает шифрование протоколом GSM, в котором вроде бы алгоритмы вполне себе стойкие и криптографические.

Здравствуйте, Sinclair, Вы писали:

S>б) передача через SMS означает шифрование протоколом GSM, в котором вроде бы алгоритмы вполне себе стойкие и криптографические.

Это семейство A5 стойкое?

http://eprint.iacr.org/2010/013

Но скорее всего, они так и отмазались. Дескать используется канал операторов связи... его безопасность обеспечивается ими в соответствии с Законом о связи... вот договора...

Если вообще этот вопрос возникал, конечно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Anton Batenev, Вы писали:

AB>>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
DOO>Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).
DOO>Опять же аутентификация в HTTPS на сертификатах — куда уж мощнее...
DOO>Можно самому реализовать любую схему Challenge/Response со взаимной аутентификацией (благо посчитать MD5 в JS не проблема) ну и т.п.
DOO>На вскидку только не нагуглил удачного обзора — если есть вопросы по конкретным схемам, могу поискать материал.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>На вскидку только не нагуглил удачного обзора — если есть вопросы по конкретным схемам, могу поискать материал.

Не в тему, но гугля наткнулся на довольно интересную идею: http://prpl.stanford.edu/papers/soups10j.pdf

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Не в тему, но гугля наткнулся на довольно интересную идею: http://prpl.stanford.edu/papers/soups10j.pdf
Да уж... Действительно оригинально

Здравствуйте, DOOM, Вы писали:

DOO> AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
DOO> Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).

Это я понимаю. Я про веб-сервис RSDN говорил, к работе которого Владимир имеет непосредственное отношение

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, andy1618, Вы писали:

A>С большим удовольствием сообщаем,
A>что в основной ассортимент футболок добавлены 6 новых цветов!

Эх если бы только производители футболок это делали... Вырезка из письма от www.superjob.ru (самого цитируемого соц.исследователя рунета) и одного из ведущих HR "агентств":

Здравствуйте, XXX!

Вы разместили свое резюме *** в базе данных сайта Superjob. Последний раз Вы редактировали это резюме ***.

...
Ваши регистрационные данные:
Логин: xxx@yyy.zz
Пароль: @#$%@$
...

Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Эх если бы только производители футболок это делали... Вырезка из письма от www.superjob.ru (самого цитируемого соц.исследователя рунета) и одного из ведущих HR "агентств":

AAV>

AAV>Здравствуйте, XXX!

AAV>Вы разместили свое резюме *** в базе данных сайта Superjob. Последний раз Вы редактировали это резюме ***.

AAV>...
AAV>Ваши регистрационные данные:
AAV>Логин: xxx@yyy.zz
AAV>Пароль: @#$%@$
AAV>...

AAV>

Вот-вот, именно!
Раньше обычно отправлял в ответ стандартное письмо с эпитетами в адрес разработчиков и просьбой больше так не делать.
Теперь же, спасибо автору топика, можно будет отвечать более объёмным и доходчивым текстом ))

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, DOOM, Вы писали:

DOO>> AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
DOO>> Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).

AB>Это я понимаю. Я про веб-сервис RSDN говорил, к работе которого Владимир имеет непосредственное отношение

Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.

Проблема в только в том, что на это нужно время

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.
Э-э-э-э... А ведь на RSDN точно была поддержка OpenID — сейчас нет что ли?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.

Хотя, учитывая текущую конфигурацию сервера и реализацию сайта и сервиса, oauth будет предпочтительнее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.
DOO>Э-э-э-э... А ведь на RSDN точно была поддержка OpenID — сейчас нет что ли?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, kochetkov.vladimir, Вы писали:

k> Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

SSL не обязательно. ИМХО, достаточно хэша. При чем ломать ничего не надо будет если длина хэша заранее известна и больше максимальной длины пароля. К тому же на клиенте будет правильнее хранить именно хэш, а не открытый пароль. Т.е. без фанатизма.

avalon 1.0rc3 rev 361, zlib 1.2.3

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, kochetkov.vladimir, Вы писали:

k>> Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

AB>К тому же на клиенте будет правильнее хранить именно хэш, а не открытый пароль. Т.е. без фанатизма.

На клиенте он не совсем в открытом виде хранится, а в криптосторе. Ибо без фанатизма

AB>AB>SSL не обязательно. ИМХО, достаточно хэша. При чем ломать ничего не надо будет если длина хэша заранее известна и больше максимальной длины пароля.

Ну вот. DO-o-o-o-o-OM! А, они опять...

Понимаешь, тут какое дело... Либо я, либо DOOM (DOOM уже говорил, ссылка есть выше), сейчас скажем, что в этом случае хэш будет являться парольным эквивалентом и ничего существенного в плане безопасности это не даст. Подожди, не отвечай, пока

Ты возмутишься, мол как это не даст, когда пароль будет ходить уже не в открытом виде. Мы возразим, что поскольку для аутентификации достаточно хэша, то передача хэша в открытом виде будет полностью эквивалентна передаче пароля в нем же. Ты попросишь привести пример конкретной атаки. Мы будем объяснять, что и в том, и в другом случае будут возможны атаки спуфинга на систему. Тут выяснится, что ты имел ввиду атаки не на систему, а на пользователя. Мы объясним, что предложенная схема снимает ровно одну угрозу: раскрытие содержимого пользовательского пароля, которая актуальна тогда (и только тогда), когда пользователем будет нарушено общеизвестное правило о недопустимости использования одинаковых паролей для тех систем, чья безопасность критична с т.з. пользователя. Во всех остальных случаях, для пользователя это будет абсолютно параллельно, т.о. не совсем понятно, что мешает пользователю прямо сейчас использовать в качестве пароля md5 от какой-нибудь строки. Ты возразишь, что не пользовательское это дело, md5 высчитывать (умалчивая при этом, что все пользователи оффлайн клиентов, в общем-то не очень домохозяйки). Мы пободаемся еще немного и разойдемся до следующего раза.

Правда, мило поговорили?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	03.09.10 15:11
Оценка:	124 (9) +2
#Имя:	FAQ.philosophy.security.harmful.advice

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	06.09.10 07:48
Оценка:	38 (6)

	От:	andy1618
	Дата:	03.09.10 19:29
	Оценка:	11 (1) +2

	От:	tlp
	Дата:	08.09.10 15:58
	Оценка:	1 (1) +1

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	06.09.10 07:48
Оценка:	24 (3)

От:	adontz	http://adontz.wordpress.com/
Дата:	03.09.10 20:45
Оценка:	14 (2)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	05.09.10 13:01
Оценка:	+2

От:	Курилка	http://kirya.narod.ru/
Дата:	03.09.10 20:13
Оценка:	22 (1)

От:	Anton Batenev	https://github.com/abbat
Дата:	03.09.10 17:01
Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	04.09.10 09:47
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	11.09.10 15:00
Оценка:

	От:	SergH
	Дата:	07.09.10 20:20
	Оценка: