Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
А в чём проблема? Пароль высылается же на ваш ящик, а если вы профукаете пароль от своего ящика, то это в любом случае чревато плохими последствиями.
Если злоумышленник украдет базу, то ему кроме как ввести логин и пароль — ничего не надо. Это не говоря о том, что многие используют 1 и тот же пароль на куче сайтов/почте. Я даже думаю у вас самого 1-2 пароля типа «мой мобильничек» и супер секретный «имя собаки соседа» и вы их используете примерно везде.
Нет, у меня как раз таки, на каждый сайт свой пароль, и если сайт позволяет, то длинной больше чем 20-25 символов, где встречаются и буквы (маленькие, большие) и цифры. А так же я использую маску. Но своим комментарием я подразумевал, что на многих сайтах так и сделано (присылают на почту пароль). Так что прошу не делать поспешные выводы о том какой я. А про то что если взломают ящик, то что бы сайт не присылал на почту, у злоумышленника появится полный доступ к вашему паролю почти на любом сайте. А если пароли хранятся в md5, ну сейчас их довольно просто расшифровывают. А вы сразу все минусовать, вот беда. Спасибо.
Проблема открытого хранения паролей не в том, что их посылают по почте, а в том, что взломав один раз базу человек может получить доступ ко всем аккаунтам сразу, плюс с большой вероятность к аккаунтам на других сервисах.
Да я понял это, и это очевидно. Я вам пытаюсь донести мысль, что потеряв пароль от ящика, ваши пароли моментально станут доступны взломщику, какой бы защита не была на сайтах, так как всё присылается на почту (пароль или ссылка на смену пароля). Детский сад, ей богу.
Шифрование или хэширование паролей это прежде всего защита ваших остальных аккаунтов, а не защита этого аккаунта. Чтобы получив доступ к базе и исходникам, человек не мог получить доступ к той же почте, если вдруг пароли совпадают или, скажем, легко получаются из имени сайта.
Зачем мне объяснять, что я и сам понимаю? А если вы используете пароли, по которым легко понять что вы используете на других сайтах, то это уже недостаток ваших паролей. Зачем вообще спорить на эту тему, ведь всё и так ясно. Наверно мы просто не поняли друг друга, кто что хотел сказать. Так что извиняюсь. Теперь я понимаю что на хабре, любое противоречие обществу, влечёт гнев сообщества :(
Из вашего коммента («А в чём проблема?») получается, что вы не видите проблемы в том, что пароли хранятся в открытом или восстановимом виде. Остальные видят.
Да, теперь понял ошибку. Я всего лишь хотел сказать этим, что если ящик взломали, но какая разница как сайт будет присылать. Приношу извинения перед всеми, кто заходя сюда, видит 1-ый глупый комментарий.
Да не о почтовом ящике же речь в статье идет. Вам пытаются объяснить, что при взломе базы озона можно будет спокойно получить доступ ко всем аккаунтам на этом сайте. Помимо этого, у многих пользователей везде один пароль, поэтому так же спокойно злоумышленник получает доступ к остальным сервисам, таким как почта, социальные сети и т.д.
Да я знал это с самого начала, или вам нравится по 100 раз повторять одно и то же? Заминусовали как последние сволочи. Я вам пытался говорить другое, а вы меня зачем-то в свой огород тянете, короче тут одни подсосы, да и только. Нет что бы разобраться, кто о чём говорит, сразу ножом тыкают. Фу такими быть. И повторюсь я понял про что вы, я понял это ещё из статьи, но выразился не о том, так что прекращайте отвечать мне одно и тоже. Спасибо.
Дата рождения: 26 марта 1993
Ваш К.О.
Ваш К.О.
> «Если ящик взломали, но какая разница как сайт будет присылать»
Так нельзя ставить вопрос. А если сосуля на голову упадет, а если бешеная собака укусит? А если ядерная война? Все может случиться, только глупо приводить это как аргументы в пользу наплевательского отношения к безопасности, после того как столько сайтов было взломано.
Я считаю, если сайт имеет дело с деньгами или личной перепиской, то хранение паролей в открытом виде должно расцениваться как служебная халатность (с лишением свободы на срок до 3 лет).
Позволяет хеширование паролей лучше защитить пользователей? Позволяет, что тут спорить.
Так нельзя ставить вопрос. А если сосуля на голову упадет, а если бешеная собака укусит? А если ядерная война? Все может случиться, только глупо приводить это как аргументы в пользу наплевательского отношения к безопасности, после того как столько сайтов было взломано.
Я считаю, если сайт имеет дело с деньгами или личной перепиской, то хранение паролей в открытом виде должно расцениваться как служебная халатность (с лишением свободы на срок до 3 лет).
Позволяет хеширование паролей лучше защитить пользователей? Позволяет, что тут спорить.
Сложность пароля не важна, если он хранится в открытом виде.
Такое встречается чуть-ли не на каждом 5м сайте. Некоторые оправдывают это «улучшением в юзабилити», мол пользователям действительно просто напоминают их пароль, и им не надо копипастить новый сгенереный код, логинится с ним на сайт, искать форму замены паролей, вводить текущий, два новых, а потом еще и ждать подтверждения на тот же емеил.
Юзабилити можно и проще улучшить, достаточно присылать сразу новый пароль (не отменяя до его активации старый), и давать в письме ссылку на страницу с формой, где будет достаточно нажать 1 кнопку, что бы сменить пароль и залогиниться под новым.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
Хранение паролей в открытом виде (особенно на фоне радужных таблиц и повсеместного хранения md5 хэшей, в т.ч. без соли) может быть реализовано (хотя и стоит этого избегать), относительно безопасно (при чем надо учесть, что если сервер взломан, то обычный троян на сервере выцыганит соразмерное кол-во паролей за непредсказуемое кол-во времени будучи незамеченным, а уж администратору сервера все эти трюки доступны всегда и легко).
Мы в одном из проектов делали такое достаточно банально. Основной сервер не хранил пароли вообще. Он лишь скармливал задачи связанные с паролем (проверка пароля, отсылка пароля, смена пароля, создание нового юзера/пароля и т.д.) на 2-ой сервер (на котором только БД и была). За этими задачами раз в секунду заходит третий сервер (к которому внешнего входящего доступа вообще нет кроме ssh по ключам), на котором и хранятся непосредственно данные связанные с инфой о юзере (почта, логин, пароль). Система как ни странно получилась достаточно простой и надежной.
Мы в одном из проектов делали такое достаточно банально. Основной сервер не хранил пароли вообще. Он лишь скармливал задачи связанные с паролем (проверка пароля, отсылка пароля, смена пароля, создание нового юзера/пароля и т.д.) на 2-ой сервер (на котором только БД и была). За этими задачами раз в секунду заходит третий сервер (к которому внешнего входящего доступа вообще нет кроме ssh по ключам), на котором и хранятся непосредственно данные связанные с инфой о юзере (почта, логин, пароль). Система как ни странно получилась достаточно простой и надежной.
получилась достаточно простой и надежной.
А как вы судите о надежности? Chronopay, Linkedin и другие, также были уверены в достаточной надежности системы, ровно до момента, пока их не взломали.
А как вы судите о надежности? Chronopay, Linkedin и другие, также были уверены в достаточной надежности системы, ровно до момента, пока их не взломали.Не вполне понятно, почему Вы считаете что линкедин и прочие были уверены в достаточной надежности. В надежности вообще нельзя быть уверенным, это лишь игра вероятностями, взломать можно всё.
В именно нашем случае надо не забывать о том, что возможности по обезопашиванию ограничивались постановкой задачи — необходимостью хранить где-то пароли в открытом виде. Мы ни в коем случае не заявляем о 100% надежности нашего метода, это просто лучшее решение из тех что мы смогли найти. И если Вы можете привести схему как этот вариант обходится и/или предложить лучший вариант — будем очень благодарны, т.к. вопрос безопасности в этом случае нас очень волнует.
Вы не являетесь администратором sql.ru, где такая же фигня?
При том, что www.sql.ru/forum/actualthread.aspx?tid=947629
На текущий момент, защита является вполне адекватной, относительно ценности хранимых данных. (пароли зашифрованы, алгоритм и база на разных серверах)
При том, что www.sql.ru/forum/actualthread.aspx?tid=947629
Нет, sql.ru не администрируем.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Ну правильно, давайт сравним гипотетическую ситуацию с хорошей безопасностью с не менее гипотетической ситуацией с плохой безопасностью, и назовем это хорошим сравнением.
Для меня достаточно следующего:
Для меня достаточно следующего:
Что-то я мало доверяю «адекватной защите» и «не самопальной штуке» на фоне уязвимости, существующей с 2003-го года, и простейшему xss
Ну правильно, давайт сравним гипотетическую ситуацию с хорошей безопасностью с не менее гипотетической ситуацией с плохой безопасностью, и назовем это хорошим сравнением.Так ведь именно это и делает автор топика! Которому мы возражаем… за что и огребаем.
Создатель топика как раз и сравнивает гипотетическую ситуацию хранения пароля ozon-ом в открытом виде заявляя что
Действующий пароль выслан в открытом виде
При этом называет мелочью следующие вещи
алгоритм шифрования старый, соль не используется и т.д. Это все мелочи.
А мы лишь попытались донести ту простую мысль, что хранение паролей в открытом виде само по себе не зло, и что с таким отношением автора топика к «мелочам», он создаст систему менее надежную, чем можно легко создать даже при условии открытых паролей.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.Вот не надо сравнивать ИТшников и простых пользователей. Если первые это понимают и применяют, то вторые (коих 99%) всё-равно не будут следовать всем правилам безопасности.
Допустим есть риск человеческого фактора в большой компании: кто-то из инсайдеров может слить часть БД.
1) В ситуации с открытыми паролями (либо зашифрованными, но зная алгоритм...) — есть защита от этого?
2) В ситуации с грамотно хешированными паролями (PBKDF2, bcrypt/scrypt) — что будете делать с хешами? — брутить?
Вот не надо сравнивать ИТшников и простых пользователей.Так мы не сравниваем, мы практически цитируем некоторых юзеров «господи, этот сайт хранит мой пароль в открытом виде, ужас, ведь я этот пароль еще много где использую» (с) К тем кто сам так не делает, а просто заботится о своем ближнем — вопросов нет.
Допустим есть риск человеческого фактора в большой компании: кто-то из инсайдеров может слить часть БД.Давайте еще раз уточним — мы не отрицаем, что пароли лучше хэшировать (ясен пень что лучше), мы не более чем утверждаем, что грамотный подход к хранению паролей в открытом виде превосходит ту степень безопасности, что есть у среднестатического сайта в интернете, особенно если сайтовладелец, как и автор топик, а считает что хэширование это ключ ко всем проблемам, а "алгоритм шифрования старый, соль не используется и т.д. Это все мелочи. "(с) и хотя бы в меру этого имеет право на существование (особенно если сверху уже спущена задача хранить пароли в открытом виде и это не обсуждается).
Что касается инсайда… Тут уж из серии — а что если из банка сбежит кассир с деньгами. Да, может сбежать. Такие дела, there are no safety in this crazy world.
Глобально абсолютной защиты от инсайда нет, чем бы Вы там пароли не солили — один черт пострадаете (начиная с банального сниффера вкряченного на сервер).
Локально же этот вопрос частично решается хранением паролей в шифрованном виде, с тем что бы ключ был на сервере куда есть доступ у одной группы сотрудников, а зашифрованные пароли на другом сервере — куда доступа у этой группы сотрудников нет. Мы такое не реализовывали, т.к. это было уже overkill-ом, но в принципе — вполне рабочий вариант.
Разница в том, что вы сравниваете грамотный подход к хранению паролей с неграмотным хешированием, а надо сравнивать оба подхода с грамотной реализацией.
Ну а на счёт сферического среднестатестического сайта в вакууме… топик-то про озон.
Ну а на счёт сферического среднестатестического сайта в вакууме… топик-то про озон.
Разница в том, что вы сравниваете грамотный подход к хранению паролей с неграмотным хешированием, а надо сравнивать оба подхода с грамотной реализацией.Еще раз повторим: сравниваем не мы, а автор топика (объясняли тут habrahabr.ru/post/146591/#comment_4936324 ), а мы лишь критикуем это его сравнение, не более того.
Ну а на счёт сферического среднестатестического сайта в вакууме… топик-то про озон.Топик про хранение открытых паролей, озон лишь пример вообще-то. Однако — с удовольствием послушаем про реализацию системы хранения на озоне и ее преимущества/недостатки, если Вы хотите конкретизировать.
надёжной такая система не будет никогда. Раз доступ к серверу в принципе есть (локальная сеть, физический доступ) — его можно взломать, и получить пароли.
Что помешает одному из сотрудников, обслуживающих сервера, слить базу данных?
Что помешает одному из сотрудников, обслуживающих сервера системы, где православно хранятся только круто солёно-перчёные хеши самой большой длины самого стойкого алгоритма, заменить все эти хеши на один от известного пароля? (это, конечно, сразу заметят, но мало ли какая была задумана атака, для некоторых целей вполне пойдёт) Или встроить бэкдор в систему. Его заметят далеко не сразу. И там и там — одна-две строчки…
Конечно, свой человек, обслуживающий систему, на которую нацелена атака, даёт большие возможности для злоумышленника. Но я имел совсем другую ситуацию.
В вышеописанном случае недобросовестному админу даже делать ничего не надо, у него в руках база нехэшированных паролей, которая представляет значительно большую ценность, нежели логин-хэш-соль.
При грамотном использовании её утечку вообще невозможно отследить, в отличие от бэкдоров.
А главное, полученную информацию можно использовать не только на этом ресурсе, т.к. добрая часть паролей подойдёт и к другим, возможно, более важным ресурсам.
В вышеописанном случае недобросовестному админу даже делать ничего не надо, у него в руках база нехэшированных паролей, которая представляет значительно большую ценность, нежели логин-хэш-соль.
При грамотном использовании её утечку вообще невозможно отследить, в отличие от бэкдоров.
А главное, полученную информацию можно использовать не только на этом ресурсе, т.к. добрая часть паролей подойдёт и к другим, возможно, более важным ресурсам.
Это диагноз, но он лечится — взломом и публикацией базы логинов: паролей.
Обычно хватает одного раза.
Обычно хватает одного раза.
Ещё ВКонтакте долгое время пароли так же восстанавливались.
Всё равно, данные передаются в открытом виде по HTTP. Видимо, задача обеспечить криптографическую защиту информации не ставится. А хэширование паролей относится именно к ней.
И вообще, это просто Ня! Все дружно вопят про хэширование, пишут статьи пачками как правильно солить пароли, и смешивают с грязью тех, кто посмел не хэшировать. Не иначе, очередной стереотип. Никто ведь не кричит про необходимость внедрять HTTPS, хотя это куда более насущная проблема.
Зы. А я даже знаю, откуда взялся этот стереотип. В школе/на первом курсе вам показали пхп и функцию md5 (а то и sha1), и дали установку всегда её применять. Вот вам это и въелось.
И вообще, это просто Ня! Все дружно вопят про хэширование, пишут статьи пачками как правильно солить пароли, и смешивают с грязью тех, кто посмел не хэшировать. Не иначе, очередной стереотип. Никто ведь не кричит про необходимость внедрять HTTPS, хотя это куда более насущная проблема.
Зы. А я даже знаю, откуда взялся этот стереотип. В школе/на первом курсе вам показали пхп и функцию md5 (а то и sha1), и дали установку всегда её применять. Вот вам это и въелось.
Что за бред, причём тут стереотипы? Есть простые правила безопасности пользовательских данных.
Чем больше будут писать и «кричать» про хеширование — тем больше новичков будут правильно делать.
Хранить пароли в открытом виде вообще не допустимо — большинство юзеров используют один пароль на всех сервисах. А про HTTPS стоило бы почаще напоминать.
Чем больше будут писать и «кричать» про хеширование — тем больше новичков будут правильно делать.
Хранить пароли в открытом виде вообще не допустимо — большинство юзеров используют один пароль на всех сервисах. А про HTTPS стоило бы почаще напоминать.
В школе/на первом курсе вам показали пхп и функцию md5 (а то и sha1), и дали установку всегда её применять. Вот вам это и въелось.Ну 10+ лет назад многократно md5-хешированный пароль может и сносно было, но на современном железе эти алгоритмы слишком быстры и поэтому не должны использоваться для хеширования паролей. Use bcrypt, Luke.
Все кишки сайта в 99% случаев лежат в public_html, один пользователь владеет всеми базами данных и т.п. и никто не объявляет всё это смертными грехами, лишь хэширование — Святая Обязанность.
MD5 тоже все обсирают, но реальной атаки никто не может показать.
MD5 тоже все обсирают, но реальной атаки никто не может показать.
Вроде большую часть паролей Linkedin вскрыли. Включая мой :)
Научитесь если не пользоваться Google, то хотя бы открывать статью в Википедии.
Ох не верится мне:
В контексте озона предлагаю всем, кому не по душе, что их пароли хранятся в открытом виде, написать им в поддержку, что так делать не стоит и надо бы одуматься. Может прислушаются.
тем больше новичков будут правильно делатьВ каждом подобном посте вылазят люди с разговорами типа «а зачем хешировать», «и так все работает», «а давайте подключим 100500 серверов в цепочку и будем с самого последнего пароли вытягивать». А всего-то нужно bcrypt подключить и дать возможность спать спокойно и себе и своим пользователям.
В контексте озона предлагаю всем, кому не по душе, что их пароли хранятся в открытом виде, написать им в поддержку, что так делать не стоит и надо бы одуматься. Может прислушаются.
Не меньше бесит, когда после регистрации на сайте (не знаю как на ozon, но примеров масса) приходит письмо вида «Поздравляем, вы зарегистрировались на блаблабла! Ваш логин: ххх, Ваш пароль: ууу!». После этого начинается приступ паранойи — приходится удалять письмо и чистить корзину. После чего надеяться, что удаленные письма не восстановить.
2. Используется «левый» алгоритм шифрования (без использования хэшей), который позволяет восстановить пароль зная сам алгоритм и зашифрованный пароль.
Не путайте шифрование и хэширование. Смысл шифрования как раз заключается в том, что можно легко восстановить исходное сообщение, а хэширования в том что нет. Но для восстановления нужно знать алгоритм, зашифрованный пароль и ключ для расшифровки.
Видимо разработчики Озона считают, что достаточно надежно защитили ключ,, например прочитать его можно только с рутовыми правами, и что алгоритм достаточно надёжен. Да, безопасность (угроза компрометации) пользовательских паролей (особенно сложных) ниже чем при хэшировании (особенно с уникальной длинной индивидуальной солью), но юзабилити выше. Но имея доступ к базе иисходникам исполняемому коду их можно считать равнозначными (если, конечно, ключ не хранится в базе или коде).
Не путайте шифрование и хэширование. Смысл шифрования как раз заключается в том, что можно легко восстановить исходное сообщение, а хэширования в том что нет. Но для восстановления нужно знать алгоритм, зашифрованный пароль и ключ для расшифровки.
Видимо разработчики Озона считают, что достаточно надежно защитили ключ,, например прочитать его можно только с рутовыми правами, и что алгоритм достаточно надёжен. Да, безопасность (угроза компрометации) пользовательских паролей (особенно сложных) ниже чем при хэшировании (особенно с уникальной длинной индивидуальной солью), но юзабилити выше. Но имея доступ к базе и
Я им писал в Twitter по этому поводу в прошлом году. Сначала был странный вопрос: «Добрый день. Поясните, пожалуйста, о каких паролях идет речь?», а потом более странный ответ: «Мы серьезно относимся к сохранности предоставленной клиентами информации, поэтому все данные хранятся зашифрованными. Спасибо».
Почему ответ странный? Зашифрованные пароли компромисс между безопасностью (менее безопасно чем хранить в хэшированном виде с солью, но более чем в открытом) и удобством (удобнее получить свой забытый пароль, а не придумывать новый).
> и удобством (удобнее получить свой забытый пароль, а не придумывать новый).
Если пользователь не смог запомнить пароль — то напоминание ничем не поможет, всё равно забудет точно так же.
Так что «удобнее получить свой забытый пароль» — спорное удобство
Если пользователь не смог запомнить пароль — то напоминание ничем не поможет, всё равно забудет точно так же.
Так что «удобнее получить свой забытый пароль» — спорное удобство
Пускай забудет, но чтобы войти здесь и сейчас ему не нужно будет переходить по ссылкам, придумывать новый пароль и т. п.
Необходимость задания нового пароля опционально. Лично я всегда реализовываю ссылку, по переходу на которую пользователь уже прошёл аутентификацию. А менять или нет пароль — дело пользователя. И это гораздо проще, чем возвращаться на сайт и вколачивать логин + только что напомненный пароль в форму авторизации.
Всё зашифровано по ГОСТу!
Тоже писал им в Twitter об этом в начале этого года.
В ответ получил:
«Понимаем Вас. О конфиденциальности и защите персональной информации на OZON.ru Вы можете прочитать на странице www.ozon.ru/context/detail/id/2787791/#2797266 (п.9). Каждый покупатель OZON.ru соглашается с этими условиями. OZON.ru уделяет много внимания защите персональных данных клиентов. С уважением.»
twitter.com/ozon_books/status/163876218964418560
twitter.com/ozon_books/status/163876604374818817
twitter.com/ozon_books/status/163876707072356353
В итоге, сменил пароль на qwerty-подобный и пользуюсь другим интернет-магазином.
В ответ получил:
«Понимаем Вас. О конфиденциальности и защите персональной информации на OZON.ru Вы можете прочитать на странице www.ozon.ru/context/detail/id/2787791/#2797266 (п.9). Каждый покупатель OZON.ru соглашается с этими условиями. OZON.ru уделяет много внимания защите персональных данных клиентов. С уважением.»
twitter.com/ozon_books/status/163876218964418560
twitter.com/ozon_books/status/163876604374818817
twitter.com/ozon_books/status/163876707072356353
В итоге, сменил пароль на qwerty-подобный и пользуюсь другим интернет-магазином.
Недавно восстанавливал пароль на sports.ru — то же самое, пока Навоша там рулит от бардака не избавятся…
Есть специальный блог, где постят сайты использующие plain-text пароли: http://plaintextoffenders.com
На большей части скриншотов — мейлы с подтверждением регистрации. Которые никаким образом не подтверждают, что сайт сохранил пароль в плейнтексте.
А те, кто действительно готовы выслать пароль — молодцы. Многие замучались придумывать и запоминать пароли, при этом выполняя дибильные требования на минимальную длину пароля, на необходимость использования разных классов символов и т.д. А некоторым извращенцам и этих издевательств мало, даёшь двухфакторные авторизации! Особо упоротые маньяки требуют периодической смены пароля. Биореактор — подходящее место для таких ТруЪ Ъкспертов по информационной безопасности. >_<
Зы. Огромное спасибо таким сайтам, как loginz.org/, вот это — по-настоящему светлая идея (в отличии от всяких там bcrypt'ов и многофакторных авторизаций).
А те, кто действительно готовы выслать пароль — молодцы. Многие замучались придумывать и запоминать пароли, при этом выполняя дибильные требования на минимальную длину пароля, на необходимость использования разных классов символов и т.д. А некоторым извращенцам и этих издевательств мало, даёшь двухфакторные авторизации! Особо упоротые маньяки требуют периодической смены пароля. Биореактор — подходящее место для таких ТруЪ Ъкспертов по информационной безопасности. >_<
Зы. Огромное спасибо таким сайтам, как loginz.org/, вот это — по-настоящему светлая идея (в отличии от всяких там bcrypt'ов и многофакторных авторизаций).
Мой личный фаворит в этой олимпиаде — Fring.
Во-первых они также возвращают пароль на почту. Но самое крутое — его никак нельзя поменять без удаления аккаунта.
Где-то ещё встречал советы отправить новый пароль по email в поддержку и попросить его установить.
Во-первых они также возвращают пароль на почту. Но самое крутое — его никак нельзя поменять без удаления аккаунта.
Где-то ещё встречал советы отправить новый пароль по email в поддержку и попросить его установить.
Юзабилити на грани фантастики просто…
А как вам такая процедура, установленная у одного ростовского провайдера?
При заключении договора выделяется почтовый ящик. Желаемый email и пароль нужно указать в заявлении. А девочка-менеджер потом с бумаги этот пароль перепечатает.
А если вы хотите его поменять — приезжайте в офис и пишите заявление: «Прошу изменить пароль на такой-то».
Так было года два-три назад. Сейчас, надеюсь, все лучше.
При заключении договора выделяется почтовый ящик. Желаемый email и пароль нужно указать в заявлении. А девочка-менеджер потом с бумаги этот пароль перепечатает.
А если вы хотите его поменять — приезжайте в офис и пишите заявление: «Прошу изменить пароль на такой-то».
Так было года два-три назад. Сейчас, надеюсь, все лучше.
Извините, Вы не можете использовать указанный пароль. Такой пароль уже использует пользователь Misha. Пожалуйста, придумайте другой пароль.© bash.im/quote/399755
tut.by раньше хранил пароли по такой же схеме, незнаю поменялось ли что-то сейчас.
*для справки tut.by в байнете считается одним из самых посещаемых порталов
*для справки tut.by в байнете считается одним из самых посещаемых порталов
Некоторые мало того, что не шифруют пароли, так еще и до сих пор передают их по незащищенному соединению (т.е. не делают перенаправления на https для авторизации).
Возможно не все так плохо. Я не берусь утверждать на 100% (надо проверять), но возможно при запросе пароля он генерируется случайным образом и отправляется в письме клиенту, а в БД при этом хранится его подсоленный хэш. Другими словами и в открытом виде пароли есть только в почте.
В базе Ozon настолько много всякого интересного помимо паролей, что уже в принципе не особо важно, последуют ли за этим радужные таблицы, или брутфорс, или что еще. Утечка базы = катастрофа, в любом случае.
Почему никто не удивляется, что PayPal или Amazon хранят номера кредитных карт в открытом виде, а не в виде хешей? И при повторных покупках не просит вводить данные карты заново? Ведь любой хакер, украв базу, сможет снимать деньги! Это ведь поважнее, чем пароль для доступа к сайту!
Почему никто не удивляется, что PayPal или Amazon хранят номера кредитных карт в открытом виде, а не в виде хешей? И при повторных покупках не просит вводить данные карты заново? Ведь любой хакер, украв базу, сможет снимать деньги! Это ведь поважнее, чем пароль для доступа к сайту!
Такой вариант хранения пароля годится (и действительно удобен) когда:
1. Пароль генерит сам сайт (не будет ситуации когда у юзера этот же пароль на 10 других сайтах)
2. Взлом пароля к сайту не грозит юзеру коммерческими или репутационными рисками.
К Озону, насколько я понимаю, это не относится.
1. Пароль генерит сам сайт (не будет ситуации когда у юзера этот же пароль на 10 других сайтах)
2. Взлом пароля к сайту не грозит юзеру коммерческими или репутационными рисками.
К Озону, насколько я понимаю, это не относится.
Kiborg777, спасибо за то, что вы подняли тему. Продолжу её в несколько ином контексте. То, что пароль высылается в открытом виде — не единственная проблема портала. Дело в том, что:
1. Система регистрации позволяет зарегистрировать аккаунт на любого владельца e-mail'а. Владелец почтового адреса не может подтвердить, что именно он регистрировался на Ozon.ru. Отакзаться от регистрации через письмо о подтверждении также невозможно.
2. При регистрации пользователь автоматически подписан на рекламные рассылки компании. Естественно, если кто-то без вас зарегистрировал аккаунт на ваш e-mail, вы будете получать спам, от которого не так просто корректно отписаться.
Я столкнулся с такой проблемой, и вопрос до сих пор в процессе приемлемого для меня решения.
Я отправил в связи с двумя указанными выше проблемами запрос через форму (http://www.ozon.ru/default.aspx?context=mailmaster) с просьбой добавить в письма рассылки или иным способом возможность: а) отменить регистрацию аккаунта без авторизациии на портале и принятия каких-либо соглашений (раз меня «зарегистрировали» таким способом, то и удаление аккаунта должно происходить аналогично); б) отменить рекламную рассылку без авторизациии на портале и принятия каких-либо соглашений (причины аналогичны п. а).
Ответили следующим образом:
"Такие недоразумения происходят, когда клиент, регитрируясь на сайте ошибается в вводе своего электронного адеса. Допустив ошибку при написании в один знак, электронный адрес приобретает другого адресата.
Укажите, пожалуйста, Ваш электронный адрес и он будет заблокирован."
В ответном письме я попробовал уточнить, что именно подразумевает «блокировка» электронного адреса (смогу ли я в будущем зарегистрироваться сам через этот адрес?), но ответа не последовало. Впрочем, недавно в рассылку была добавлена ссылка на отписку, которая не требует авторизации, но такая отписка не работает должным образом — не смотря на сообщение об успешной отписке спам от магазина всё равно периодически приходит.
1. Система регистрации позволяет зарегистрировать аккаунт на любого владельца e-mail'а. Владелец почтового адреса не может подтвердить, что именно он регистрировался на Ozon.ru. Отакзаться от регистрации через письмо о подтверждении также невозможно.
2. При регистрации пользователь автоматически подписан на рекламные рассылки компании. Естественно, если кто-то без вас зарегистрировал аккаунт на ваш e-mail, вы будете получать спам, от которого не так просто корректно отписаться.
Я столкнулся с такой проблемой, и вопрос до сих пор в процессе приемлемого для меня решения.
Я отправил в связи с двумя указанными выше проблемами запрос через форму (http://www.ozon.ru/default.aspx?context=mailmaster) с просьбой добавить в письма рассылки или иным способом возможность: а) отменить регистрацию аккаунта без авторизациии на портале и принятия каких-либо соглашений (раз меня «зарегистрировали» таким способом, то и удаление аккаунта должно происходить аналогично); б) отменить рекламную рассылку без авторизациии на портале и принятия каких-либо соглашений (причины аналогичны п. а).
Ответили следующим образом:
"Такие недоразумения происходят, когда клиент, регитрируясь на сайте ошибается в вводе своего электронного адеса. Допустив ошибку при написании в один знак, электронный адрес приобретает другого адресата.
Укажите, пожалуйста, Ваш электронный адрес и он будет заблокирован."
В ответном письме я попробовал уточнить, что именно подразумевает «блокировка» электронного адреса (смогу ли я в будущем зарегистрироваться сам через этот адрес?), но ответа не последовало. Впрочем, недавно в рассылку была добавлена ссылка на отписку, которая не требует авторизации, но такая отписка не работает должным образом — не смотря на сообщение об успешной отписке спам от магазина всё равно периодически приходит.
После длительной переписки с поддержкой меня отписали, при этом на окончательную отписку у саппорта ушло (намеренно или специально) 3 попытки в течении 4 месяцев.
Кстати, возможности отписаться через соответствующую ссылку в письмах рассылки без авторизации на сайте (и, соответственно, принятия соглашения сайта) уже нет. И, похоже, владельцы OZON.ru создают такую ситуацию сознательно и намеренно — как оказалось, есть полностью аналогичные моему случаи: getaid.net/web/ozon_ru-spam
Также есть подтверждения того, что кого угодно на рассылку OZON.ru может подписать не только владелец сайта, но и любой его пользователь: www.bad-good.ru/2012/july/ozon-shit.html
Кстати, возможности отписаться через соответствующую ссылку в письмах рассылки без авторизации на сайте (и, соответственно, принятия соглашения сайта) уже нет. И, похоже, владельцы OZON.ru создают такую ситуацию сознательно и намеренно — как оказалось, есть полностью аналогичные моему случаи: getaid.net/web/ozon_ru-spam
Также есть подтверждения того, что кого угодно на рассылку OZON.ru может подписать не только владелец сайта, но и любой его пользователь: www.bad-good.ru/2012/july/ozon-shit.html
Один раз рутрекер прислал письмо, мол вы давно не заходили, может вы логин пароль не помните, а вот они какие у вас. Сразу побежал и поставил какую-то легкотню вместо используемого.
Магазины можно условно разделить на две категории:
1. «Удобство» — те, что хранят незначительные данные (например, историю заказов) для удобства пользователя.
2. «Безопасность» — те, что помимо «незначительных», хранят и более существенные (например, привязывают кредитку к аккаунту для быстрых и удобных покупок без пароля).
Какова ценность данных — такова и ценность пароля к аккаунту.
Например, если нужно что-то купить в интернете (найденное по ссылке из поисковика) — и путь к покупке преграждает необходимость регистрации — нет проблем! Указываем в качестве email «мусорный» ящик, предназначенный как раз для таких одноразовых регистраций. Такой же «универсальный» логи и пароль.
Украдут и скомпрометируют? Ну и хрен с ним! Зато я с чистой совестью могу ставить галочку «запомнить пароль» в браузере; а также в будущем — если вдруг снова набреду на тот же сайт — не вспоминать мучительно и не рыться в пассворд-кипере, а просто ввести единый для всех этих «однодневок» логин и пароль.
Озон как раз относится к этой первой категории. В аккаунте не хранится никаких существенных данных (кроме, пожалуй, личной информации — но её существенность — отдельная тема). Более того — раньше (а возможно и сейчас) у Озона были «серебряные» и «золотые» пользователи. Которым высылалась пластиковая карта с 16-значным цифровым кодом. Этот код (открыто напечатанный на карте) можно использовать для входа в магазин вместо пароля, либо для восстановления доступа.
С другой стороны, для доступа к «прародителю» Озона — Amazon — я предпочитаю уникальный и сложный пароль. Потому что у этого магазина к аккаунту привязана банковская карта. Хотя даже в случае компрометации последнего всё не так плохо, поскольку магазин не стесняется спрашивать, если вдруг очередная покупка оформляется не на «привычный» адрес доставки, а на какой-нибудь новый.
1. «Удобство» — те, что хранят незначительные данные (например, историю заказов) для удобства пользователя.
2. «Безопасность» — те, что помимо «незначительных», хранят и более существенные (например, привязывают кредитку к аккаунту для быстрых и удобных покупок без пароля).
Какова ценность данных — такова и ценность пароля к аккаунту.
Например, если нужно что-то купить в интернете (найденное по ссылке из поисковика) — и путь к покупке преграждает необходимость регистрации — нет проблем! Указываем в качестве email «мусорный» ящик, предназначенный как раз для таких одноразовых регистраций. Такой же «универсальный» логи и пароль.
Украдут и скомпрометируют? Ну и хрен с ним! Зато я с чистой совестью могу ставить галочку «запомнить пароль» в браузере; а также в будущем — если вдруг снова набреду на тот же сайт — не вспоминать мучительно и не рыться в пассворд-кипере, а просто ввести единый для всех этих «однодневок» логин и пароль.
Озон как раз относится к этой первой категории. В аккаунте не хранится никаких существенных данных (кроме, пожалуй, личной информации — но её существенность — отдельная тема). Более того — раньше (а возможно и сейчас) у Озона были «серебряные» и «золотые» пользователи. Которым высылалась пластиковая карта с 16-значным цифровым кодом. Этот код (открыто напечатанный на карте) можно использовать для входа в магазин вместо пароля, либо для восстановления доступа.
С другой стороны, для доступа к «прародителю» Озона — Amazon — я предпочитаю уникальный и сложный пароль. Потому что у этого магазина к аккаунту привязана банковская карта. Хотя даже в случае компрометации последнего всё не так плохо, поскольку магазин не стесняется спрашивать, если вдруг очередная покупка оформляется не на «привычный» адрес доставки, а на какой-нибудь новый.
к сожалению, накладывается «наследие» старых систем авторизации, поиска и т.п.
Недавно получил такое письмо:
Привет, %usarname%!
Вы давно не появлялись на forum.ixbt.com (Конференция iXBT.com),
и согласно Правилам, через 7 дней ваш аккаунт будет удален.
Чтобы этого не произошло, достаточно авторизироваться на ресурсе.
Напоминаем вашу регистрационную информацию:
Ваше имя участника: %usarname%
Ваш пароль: мой оригинальный пароль
Спасибо!
Многие крупные ресурсы страдают этой болезнью =(
Привет, %usarname%!
Вы давно не появлялись на forum.ixbt.com (Конференция iXBT.com),
и согласно Правилам, через 7 дней ваш аккаунт будет удален.
Чтобы этого не произошло, достаточно авторизироваться на ресурсе.
Напоминаем вашу регистрационную информацию:
Ваше имя участника: %usarname%
Ваш пароль: мой оригинальный пароль
Спасибо!
Многие крупные ресурсы страдают этой болезнью =(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хранение паролей в Ozon.ru