Насчет безопасности парольчиков и пустопорожней болтовни...

[Shade]

Тут в уютненькой Тундрочке выложили интересный новостной апдейт:

http://warthunder.ru/ru/news/666/current/

Это подвигло меня к размышлениям на уже полузабытую тему, которую я когда-то подымал. Безопасность. Одно дело, когда маленький коллектив единомышленников ваяет Самый Правильный Сим для 3.5 анонимов, другое -- когда пытаются сделать Возрождение Легенды. Размер аудитории и, соответственно, нездоровый интерес к проекту совершенно разный.

Что такое соль и зачем ею надо солить зашифрованные алгоритмом одностороннего шифрования пароли, можно посмотреть, например, в этом кратком обзоре:

https://crackstation.net/hashing-security.htm

Я же поведу речь немного о другом.

 

Собственно, что можно извлечь из улиточной новости? 

а) Появились слухи о небезопасности базы пользователей

б) Начал подыматься шум

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

г) Таки да, пользователь, прочитавший сообщение, со спокойной душой отдаст свой парольчик улиткам на хранение.

 

На самом деле даже небольшая (дез)информация, оставленная без внимания, начинает жить своей жизнью в умах пользователей, нанося (в нашем случае) ущерб репутации разработчика. Контролировать информационное пространство Сети одна компания не в состоянии -- но она способна предоставить информацию, которая будет развеивать заблуждения. Например, как пост Хана в "Дневниках" про "Тундранесимулятор!", или как Петрович сделал в официальном стриме насчет ШВ. Когда дело просто в неграмотных вирпилах (что явление постоянное и естественное) или плохо ориентирующихся в сабже людях -- дело решается довольно легко. А вот как быть, когда опасения не напрасны, а информация -- гарантированно верна? 

 

Для справки, 777 до сих пор хранит пароли к РОФ в открытом виде:

 

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

 

Дискасс?

Изменено 27 января 2014 пользователем Shade

[NobbyNobbs]

а логин и пароль, просто напросто записанные в конфиге вас не смущают? 

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

[Shade]

а логин и пароль, просто напросто записанные в конфиге вас не смущают? 

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

Если не шифрованные -- разумеется, смущали бы еще больше. А где сейчас такое есть?

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

[NobbyNobbs]

IL-2 Sturmovik Battle of Stalingrad\data\startup.cfg

 

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

[Shade]

IL-2 Sturmovik Battle of Stalingrad\data\startup.cfg

 

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

Да, с логином и паролем в конфиге красиво вышло  

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

[Top]

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

[Shade]

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

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

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

Изменено 28 января 2014 пользователем Shade

[Top]

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

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

[Shade]

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

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

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

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

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

 

О попытке взлома, которая "могла иметь последствия", при легко вскрываемых паролях (ну а тем более, когда они лежат открытым текстом) оповещать будет в любом случае поздно. Скорее всего, во всех сервисах, где Вы имели то же мыло/пароль, Вы к тому моменту уже потеряете все, что можно потерять. И работа с сообществом тут никак не поможет. Этот случай -- как раз из разряда, когда легче предотвратить, чем разбираться с последствиями. 

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

[Shade]

Интересно, сделано ли что-нибудь в направлении безопасности с тех давних пор, когда проходила сия дискуссия? 

[Serval]

Интересно, сделано ли что-нибудь в направлении безопасности с тех давних пор, когда проходила сия дискуссия? 

Смысла нет, обеспичиваешь безопасность ОС и главное, почтового ящика и все будет тип-топ.

[Shade]

Смысла нет, обеспичиваешь безопасность ОС и главное, почтового ящика и все будет тип-топ.

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

[taleks]

> но при должном уровне надежности смысла в этом будет крайне мало из-за продолжительности расшифровки.

Для нужд авторизации пароль если он передается, то передается не в виде хэша, хотя и по защищенному соединению. Иначе это профанация под видом безопасности.

 

Хранить хэш локально - это ерунда, тот же открытый пароль вид сбоку.

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

 

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

 

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

К слову сказать, необязательно доступность пароля в открытом виде означает то, что слив базы даст вам пароль. Хотя мне все равно больше нравится только хэши хранить.

 

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

[dead0k]

то есть обратимое восстановление всегда существует и существует ключ для расшифровки.

Что мешает использовать асимметричное шифрование и выкинуть приватный ключ?

Хранить хэш локально - это ерунда, тот же открытый пароль вид сбоку.

Храните локально не хеш пароля, а токен, сгенерированный сервером (читай cookie). Пароль в безопасности (с условием, что при начальной аутентификации машина клиента не скомпрометирована), увести акк - нельзя (из клиента игры управления акком нет, для сайта токен не действителен)

[Shade]

> но при должном уровне надежности смысла в этом будет крайне мало из-за продолжительности расшифровки.

Для нужд авторизации пароль если он передается, то передается не в виде хэша, хотя и по защищенному соединению. Иначе это профанация под видом безопасности.

 

Хранить хэш локально - это ерунда, тот же открытый пароль вид сбоку.

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

 

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

 

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

К слову сказать, необязательно доступность пароля в открытом виде означает то, что слив базы даст вам пароль. Хотя мне все равно больше нравится только хэши хранить.

 

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

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

 

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

 

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

 

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

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

 

Насчет уведенной почты -- опять же, если присылать по запросу юзеру его пароль, тут уже очевидно, к чему это ведет. Но я тут проверил то же действие с РоФовским аккаунтом (это на тему того, что было сделано):

Вы получили это сообщение, потому что вы (или кто-то другой, выдающий себя за вас) запросили восстановления пароля к учетной записи на сайте http://riseofflight.com. Если вы не хотите сбросить текущий пароль, просто игнорируйте данное сообщение.

 

Чтобы восстановить пароль, пожалуйста, используйте ссылку ниже или скопируйте ее и вставьте в адресную строку браузера:

http://riseofflight.com/ru/profile/NewPassword?changeCode=*****

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

 

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

[2BAG_Miron]

 

 

с условием, что при начальной аутентификации машина клиента не скомпрометирована

 

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

[taleks]

Что мешает использовать асимметричное шифрование и выкинуть приватный ключ?

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

 

 

 

Но вот как хранение локально того же соленого хэша поможет восстановить по нему пароль, при отсутствии соли

Локально - значит можно отловить и отладить, а значит и соль известна, она ж не с потолка берётся, она каким-то уникальным для пользователя образом создается, а значит код для этого есть на стороне пользователя.

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

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

 

 

 

Далее, очень странно читать про всегда существующее обратимое восстановление/расшифровку.

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

Это к вопросу упомянутого dead0k'ом выкинутого закрытого ключа, кстати говоря, тоже относится.

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

 

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

 

 

 

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

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

[Graphite]

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

[dead0k]

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

Выкинув приватный ключ мы получили хеш-функцию, которая виртуально необратима (виртуально, т.к. P=NP пока не опровергнуто).

 

Если его невозможно достать из хранилища, то зачем такое хранилище?

Для хранения хеша. Конечно, идентичность хеша введенного пароля и хеша хранимого в базе пароля не означает идентичность паролей т.к.

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

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

Допустим сервер солит (21-ый век на дворе, пора уже) пароли и хеширует их в строку из 64 16-ричных цифер. Тогда вероятность того, что случайный пароль даст тот же хеш, очевидно, 16^-64.

Невольно напрашивается цитата из Праттчета: "шанс один на миллион выпадает в 9 случаях из 10"

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

 

Далее, по поводу:

рэйнбоу таблицы доступны в интернетах

Полная табличка для вышеописанной хеш функции будет занимать не много ни мало 64 * 16⁶⁴байт = 2²⁶⁰байт ~ 10⁷⁷байт

Для сравнения, число атомов в наблюдаемой вселенной (по словам тети Вики) ~ 10⁸¹...

А поскольку мы солим пароли, то составитель радужных табличек не может как-либо сократить это число.

 

Без соли, да, паролю "11111" всегда соответствует один и тот же хеш. А вот с солью все пользователи могут иметь пароль "11111", но хеши у всех будут разными.

 

 

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

По этой же причине не стоит хранить хеш у пользователя.

[taleks]

 

 

Выкинув приватный ключ мы получили хеш-функцию, которая виртуально необратима (виртуально, т.к. P=NP пока не опровергнуто).  Для хранения хеша. 

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

Перед объяснением вообразите меня невообразимо тупым, чтобы объяснение получилось более подробным.

 

 

 

Допустим сервер солит

В предложениях выше, как я понял, солит не сервер, а результат клиент хранит локально в виде [посоленного] хэша.

 

 

 

Полная табличка для вышеописанной хеш функции

Основные используемые в паролях символы и средняя длина пароля сокращают домен поиска во много раз. Там даже не 7бит на символ в среднем.

Ну и ещё раз: если вы храните хэш, а не пароль на клиенте, значит клиент должен использовать для авторизации хэш, поскольку пароль ему неизвестен. Поэтому все абстрактные построения с кучей степеней верны только для хранения хэшей на сервере. А в треде предложено посолить, и сохранить локально, уничтожив преимущества соли.

 

PS:

Я не знаю, как все хранится в БзС, поэтому обсуждаю только то, что в этом треде написано.

[dead0k]

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

Чтобы усложнить задачу извлечения пароля.

Открытый пароль < обратимо шифрованый (при условии, что код шифрования спрятан) << криптографический хеш.

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

В предложениях выше, как я понял, солит не сервер, а результат клиент хранит локально в виде [посоленного] хэша.

Хорошо, что это не мои предложения . Я предлагаю хранить локально только токен. Уведут токен - ничего страшного (стату, правда, могут испортить). Токен можно привязать к конкретной машине, что еще немного усилит защиту.

Основные используемые в паролях символы и средняя длина пароля сокращают домен поиска во много раз. Там даже не 7бит на символ в среднем.

Только для брутфорса. Соль гарантирует неприменимость радужных таблиц.

сохранить локально, уничтожив преимущества соли.

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

[fghfgh]

Обратите внимание, что если получить доступ к почте какого-либо пилота, можно легко забрать себе его БзС. Нужно нажать "Забыли пароль", на почту придет форма, ввести туда два раза новый пароль и БзС ваш. Так что, граждане пилоты, заботьтесь о безопасности вашего почтового ящика.

Изменено 24 октября 2014 пользователем Buyvol