А на этом «одном ноуте» Вы не выбирали другой регион на яндекс.поиске?
Мы как-то москву выбрали (не помним как, то ли по ссылке перешли. то ли результаты хотели по другому поискать), он запомнил регион и стал по москве по умолчанию карту показывать, раздражало жутко. yandex.ru/yandsearch?text=habrahabr&lr=2 — справа вверху смотрите «Регион:… » есть?
Разница в том, что вы сравниваете грамотный подход к хранению паролей с неграмотным хешированием, а надо сравнивать оба подхода с грамотной реализацией.
Еще раз повторим: сравниваем не мы, а автор топика (объясняли тут habrahabr.ru/post/146591/#comment_4936324 ), а мы лишь критикуем это его сравнение, не более того.
Ну а на счёт сферического среднестатестического сайта в вакууме… топик-то про озон.
Топик про хранение открытых паролей, озон лишь пример вообще-то. Однако — с удовольствием послушаем про реализацию системы хранения на озоне и ее преимущества/недостатки, если Вы хотите конкретизировать.
Вот не надо сравнивать ИТшников и простых пользователей.
Так мы не сравниваем, мы практически цитируем некоторых юзеров «господи, этот сайт хранит мой пароль в открытом виде, ужас, ведь я этот пароль еще много где использую» (с) К тем кто сам так не делает, а просто заботится о своем ближнем — вопросов нет.
Допустим есть риск человеческого фактора в большой компании: кто-то из инсайдеров может слить часть БД.
Давайте еще раз уточним — мы не отрицаем, что пароли лучше хэшировать (ясен пень что лучше), мы не более чем утверждаем, что грамотный подход к хранению паролей в открытом виде превосходит ту степень безопасности, что есть у среднестатического сайта в интернете, особенно если сайтовладелец, как и автор топик, а считает что хэширование это ключ ко всем проблемам, а "алгоритм шифрования старый, соль не используется и т.д. Это все мелочи. "(с) и хотя бы в меру этого имеет право на существование (особенно если сверху уже спущена задача хранить пароли в открытом виде и это не обсуждается).
Что касается инсайда… Тут уж из серии — а что если из банка сбежит кассир с деньгами. Да, может сбежать. Такие дела, there are no safety in this crazy world.
Глобально абсолютной защиты от инсайда нет, чем бы Вы там пароли не солили — один черт пострадаете (начиная с банального сниффера вкряченного на сервер).
Локально же этот вопрос частично решается хранением паролей в шифрованном виде, с тем что бы ключ был на сервере куда есть доступ у одной группы сотрудников, а зашифрованные пароли на другом сервере — куда доступа у этой группы сотрудников нет. Мы такое не реализовывали, т.к. это было уже overkill-ом, но в принципе — вполне рабочий вариант.
Санкт-Петербург, юзаем рамблер теперь, до этого яндекс.
Яндекс за последние полгода сильно разочаровал.
Сначала 2 раза подвел на кольцевой, нарисовал повороты там, где их не было, в результате +30 минут каждый раз и +7км.
Потом подвел в другом месте на кольцевой, «не знал» о наличии заезда в город там, где он уже до фига времени есть, опять же +40 выкинутых минут и километров 30.
И наконец добило то, что по нужному району огромное кол-во давно построенных домов с адресами показывается черти где (т.е. для тех домов, о существовании которых яндекс не знает) даже если на карте они отрисованы, а неслабое количество даже не отрисовано.
В общем актуальность и точность яндекса по СПб приводит к невозможности на него положиться.
Рамблер, наверное, тоже с недостатками, но мы их пока не нашли:)
Ну правильно, давайт сравним гипотетическую ситуацию с хорошей безопасностью с не менее гипотетической ситуацией с плохой безопасностью, и назовем это хорошим сравнением.
Так ведь именно это и делает автор топика! Которому мы возражаем… за что и огребаем.
Создатель топика как раз и сравнивает гипотетическую ситуацию хранения пароля ozon-ом в открытом виде заявляя что
Действующий пароль выслан в открытом виде
При этом называет мелочью следующие вещи
алгоритм шифрования старый, соль не используется и т.д. Это все мелочи.
А мы лишь попытались донести ту простую мысль, что хранение паролей в открытом виде само по себе не зло, и что с таким отношением автора топика к «мелочам», он создаст систему менее надежную, чем можно легко создать даже при условии открытых паролей.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Не хотелось бы выступать в роли К.О., но это просто грех при использовании простых языков/фреймворков — не озаботится хотя бы полным прочтением документации, хотя бы один раз. Просто что бы знать какие функции в принципе там есть.
Иногда в коде встречаются «новоизобретенные» велосипеды, созданные исключительно по причине не знания о наличии такой функции. И это расстраивает. Можно не знать как используется каждая функция (доки в конце концов под рукой), но хотя бы примерно иметь представление об имеющемся наборе функций — надо.
Юзабилити можно и проще улучшить, достаточно присылать сразу новый пароль (не отменяя до его активации старый), и давать в письме ссылку на страницу с формой, где будет достаточно нажать 1 кнопку, что бы сменить пароль и залогиниться под новым.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
А как вы судите о надежности? Chronopay, Linkedin и другие, также были уверены в достаточной надежности системы, ровно до момента, пока их не взломали.
Не вполне понятно, почему Вы считаете что линкедин и прочие были уверены в достаточной надежности. В надежности вообще нельзя быть уверенным, это лишь игра вероятностями, взломать можно всё.
В именно нашем случае надо не забывать о том, что возможности по обезопашиванию ограничивались постановкой задачи — необходимостью хранить где-то пароли в открытом виде. Мы ни в коем случае не заявляем о 100% надежности нашего метода, это просто лучшее решение из тех что мы смогли найти. И если Вы можете привести схему как этот вариант обходится и/или предложить лучший вариант — будем очень благодарны, т.к. вопрос безопасности в этом случае нас очень волнует.
Хранение паролей в открытом виде (особенно на фоне радужных таблиц и повсеместного хранения md5 хэшей, в т.ч. без соли) может быть реализовано (хотя и стоит этого избегать), относительно безопасно (при чем надо учесть, что если сервер взломан, то обычный троян на сервере выцыганит соразмерное кол-во паролей за непредсказуемое кол-во времени будучи незамеченным, а уж администратору сервера все эти трюки доступны всегда и легко).
Мы в одном из проектов делали такое достаточно банально. Основной сервер не хранил пароли вообще. Он лишь скармливал задачи связанные с паролем (проверка пароля, отсылка пароля, смена пароля, создание нового юзера/пароля и т.д.) на 2-ой сервер (на котором только БД и была). За этими задачами раз в секунду заходит третий сервер (к которому внешнего входящего доступа вообще нет кроме ssh по ключам), на котором и хранятся непосредственно данные связанные с инфой о юзере (почта, логин, пароль). Система как ни странно получилась достаточно простой и надежной.
Жаль, что на сайте нет колонки с теми пользователями Facebook, которые читают «Хабрахабр».
Думаете это было бы идеальным дополнением к спискам из следующего ряда?
1) список пользователей, которые «хотят, чтобы их уволили» с соответствующими цитатами из социальной сети; 2) список пользователей, которые находятся в похмелье с цитатами и фотографиями; 3) список тех, кто только что закурил марихуану или принял другой наркотик;
Винды.
Снизу т.к. привычнее.
Хотя понимаем что умнее сверху (т.к. кнопки расширения/закрытия/сворачивания окон там).
А оптимально сбоку (желательно справа по вышеназванной причине) в связи с экономией места по вертикали до кучи.
Немаловажно так же, что в бытовом секторе появились объемы достаточные для бытовых нужд. Когда речь шла о покупке ssd на 16-32Гб, то по любому приходилось брать винт «в нагрузку», т.е. вопрос шел о «ссд + винт» или «просто винт».
А вот когда в ширпотреб попали емкости 160-320Гб, которых вполне достаточно для решения всех бытовых задач на текущий момент (пара игр, пара фильмов, пара офисных прожек, фотошопик… а не файл-сервер и 3д студия рендеринга и видеозахвата), то во многих случаях вопрос уже встал как «ссд» или «винт»
А это уже совсем другой вопрос, т.к. «докупить ссд» это совсем не то что «купить ссд вместо хдд», в том числе и по цене… и в том числе по использованию в ноутах с одним хдд слотом… в том числе и по устойчивости к «ой уронил».
В общем ссд скоро заховают «бытовой» мир:)
Да навалом ее существует, гуглится легко. А рассчитывается по разному, в зависимости от того кто и для каких целей ее заказывает:)))
В любом случае, в своем примере мы говорили не о ситуации, когда оружие доступно в продаже так же свободно как кухонные ножи, т.е. по сути не имеет отдельно выделенной группы товаров вообще.
Эта байка на тему «любой гопник за 5 копеек в соседнем подвале купит гранатомет и будет его открыто носить» несколько не соответствует реальной ситуации, мягко говоря.
я как законопослушный гражданин
Вот Вы уже заговорили об ограничении на покупку оружия. Ставите во главу угла законопослушность. Хотя кухонный нож и сковородка доступны любому. Значит видите разницу.
не могу просто пойти и купить ствол для своей защиты.
А как же кухонный нож и сковородка? Парой сообщений выше нашими оппонентами они ставились в один ранг с оружием, а тут вдруг разница нашлась?:)
Конкретно тут речь о том, что создавая софт для взлома биржи ммвб — трудно отмазываться от злого умысла тем, что «да люди и микрософт-офисом могут компьютер поломать»:)
И спасибо за вашу не лень раздавать минусы в карму
Вашу бы уверенность в том, кто поставил Вам минус, да в здравое русло:)
Вам будет не станет ни капельки тяжелее, если завтра свободно кому угодно разрешат носить где угодно какое угодно оружие? Ведь пырнуть-то и обычным ножом можно!
Мы как-то москву выбрали (не помним как, то ли по ссылке перешли. то ли результаты хотели по другому поискать), он запомнил регион и стал по москве по умолчанию карту показывать, раздражало жутко. yandex.ru/yandsearch?text=habrahabr&lr=2 — справа вверху смотрите «Регион:… » есть?
Топик про хранение открытых паролей, озон лишь пример вообще-то. Однако — с удовольствием послушаем про реализацию системы хранения на озоне и ее преимущества/недостатки, если Вы хотите конкретизировать.
Давайте еще раз уточним — мы не отрицаем, что пароли лучше хэшировать (ясен пень что лучше), мы не более чем утверждаем, что грамотный подход к хранению паролей в открытом виде превосходит ту степень безопасности, что есть у среднестатического сайта в интернете, особенно если сайтовладелец, как и автор топик, а считает что хэширование это ключ ко всем проблемам, а "алгоритм шифрования старый, соль не используется и т.д. Это все мелочи. "(с) и хотя бы в меру этого имеет право на существование (особенно если сверху уже спущена задача хранить пароли в открытом виде и это не обсуждается).
Что касается инсайда… Тут уж из серии — а что если из банка сбежит кассир с деньгами. Да, может сбежать. Такие дела, there are no safety in this crazy world.
Глобально абсолютной защиты от инсайда нет, чем бы Вы там пароли не солили — один черт пострадаете (начиная с банального сниффера вкряченного на сервер).
Локально же этот вопрос частично решается хранением паролей в шифрованном виде, с тем что бы ключ был на сервере куда есть доступ у одной группы сотрудников, а зашифрованные пароли на другом сервере — куда доступа у этой группы сотрудников нет. Мы такое не реализовывали, т.к. это было уже overkill-ом, но в принципе — вполне рабочий вариант.
Яндекс за последние полгода сильно разочаровал.
Сначала 2 раза подвел на кольцевой, нарисовал повороты там, где их не было, в результате +30 минут каждый раз и +7км.
Потом подвел в другом месте на кольцевой, «не знал» о наличии заезда в город там, где он уже до фига времени есть, опять же +40 выкинутых минут и километров 30.
И наконец добило то, что по нужному району огромное кол-во давно построенных домов с адресами показывается черти где (т.е. для тех домов, о существовании которых яндекс не знает) даже если на карте они отрисованы, а неслабое количество даже не отрисовано.
В общем актуальность и точность яндекса по СПб приводит к невозможности на него положиться.
Рамблер, наверное, тоже с недостатками, но мы их пока не нашли:)
Создатель топика как раз и сравнивает гипотетическую ситуацию хранения пароля ozon-ом в открытом виде заявляя что
При этом называет мелочью следующие вещи
А мы лишь попытались донести ту простую мысль, что хранение паролей в открытом виде само по себе не зло, и что с таким отношением автора топика к «мелочам», он создаст систему менее надежную, чем можно легко создать даже при условии открытых паролей.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Иногда в коде встречаются «новоизобретенные» велосипеды, созданные исключительно по причине не знания о наличии такой функции. И это расстраивает. Можно не знать как используется каждая функция (доки в конце концов под рукой), но хотя бы примерно иметь представление об имеющемся наборе функций — надо.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
В именно нашем случае надо не забывать о том, что возможности по обезопашиванию ограничивались постановкой задачи — необходимостью хранить где-то пароли в открытом виде. Мы ни в коем случае не заявляем о 100% надежности нашего метода, это просто лучшее решение из тех что мы смогли найти. И если Вы можете привести схему как этот вариант обходится и/или предложить лучший вариант — будем очень благодарны, т.к. вопрос безопасности в этом случае нас очень волнует.
Мы в одном из проектов делали такое достаточно банально. Основной сервер не хранил пароли вообще. Он лишь скармливал задачи связанные с паролем (проверка пароля, отсылка пароля, смена пароля, создание нового юзера/пароля и т.д.) на 2-ой сервер (на котором только БД и была). За этими задачами раз в секунду заходит третий сервер (к которому внешнего входящего доступа вообще нет кроме ssh по ключам), на котором и хранятся непосредственно данные связанные с инфой о юзере (почта, логин, пароль). Система как ни странно получилась достаточно простой и надежной.
Думаете это было бы идеальным дополнением к спискам из следующего ряда?
Снизу т.к. привычнее.
Хотя понимаем что умнее сверху (т.к. кнопки расширения/закрытия/сворачивания окон там).
А оптимально сбоку (желательно справа по вышеназванной причине) в связи с экономией места по вертикали до кучи.
А вот когда в ширпотреб попали емкости 160-320Гб, которых вполне достаточно для решения всех бытовых задач на текущий момент (пара игр, пара фильмов, пара офисных прожек, фотошопик… а не файл-сервер и 3д студия рендеринга и видеозахвата), то во многих случаях вопрос уже встал как «ссд» или «винт»
А это уже совсем другой вопрос, т.к. «докупить ссд» это совсем не то что «купить ссд вместо хдд», в том числе и по цене… и в том числе по использованию в ноутах с одним хдд слотом… в том числе и по устойчивости к «ой уронил».
В общем ссд скоро заховают «бытовой» мир:)
Напрасно, кнут такая же мотивация, как и пряник.
В любом случае, в своем примере мы говорили не о ситуации, когда оружие доступно в продаже так же свободно как кухонные ножи, т.е. по сути не имеет отдельно выделенной группы товаров вообще.
Вот Вы уже заговорили об ограничении на покупку оружия. Ставите во главу угла законопослушность. Хотя кухонный нож и сковородка доступны любому. Значит видите разницу.
А как же кухонный нож и сковородка? Парой сообщений выше нашими оппонентами они ставились в один ранг с оружием, а тут вдруг разница нашлась?:)
Вашу бы уверенность в том, кто поставил Вам минус, да в здравое русло:)
Мотивировать надо уметь:)