KV>>1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите
A>Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего: A>== A>
Здравствуйте, ...!
A>С большим удовольствием сообщаем,
A>что в основной ассортимент футболок добавлены 6 новых цветов!
A>...
A>Доступ в личный кабинет:
A>Имя пользователя: ...
A>Пароль: ...
A>== A>
Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте? Даже если они позволяют рассчитываться карточками, а не налом курьеру, то работают через какую-то платежку, а там все защищено. Узнать, сколько и каких футболок покупал юзер на лето? Инфа забавная, но абсолютно бесполезная.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, adontz, Вы писали:
KV>>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
A>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.
Кстати, Опера Мини так решала проблему на мобилках(там с рандомом туго): при установке просила юзера случайно потыкать клавиатуру телефона .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, Eugeny__, Вы писали:
E__>Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте?
Скорее всего он даст взлом еще кучи аккаунтов в аське, почте и прочих контактах с одноклассниками.
Re[3]: Разработчикам систем парольной аутентификации
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 не такие уж и жесткие. Мы прошли аудит менее чем за полгода и довольно легко, почти без отрыва от прочих дел(но у нас безопасник параноик изначально). Правила, оговоренный там, не являются особо параноидальными, просто не дают возможность использовать совсем уж дырявые каналы/алгоритмы(четсно, лично я эту огромную простыню не читал, говорю по впечатлению коллег). А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
E__>>Для магазина футболок, имхо, в этом нет ничего страшного. Защита Неуловимого Джо работает лучше всех криптографий. Что даст взлом акка на этом сайте? DOO>Скорее всего он даст взлом еще кучи аккаунтов в аське, почте и прочих контактах с одноклассниками.
Только есливыполняются:
1. Юзер на всех сайтах/ресурсах использует один и тот же пароль
2. Пароль на сайте футболок был введен пользователем, а не автоматом сгенерен.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, Eugeny__, Вы писали:
E__>Для магазина футболок, имхо, в этом нет ничего страшного.
1. В личном кабинете пользователя вероятнее всего есть его персональные данные и физические адреса доставки. Это информация подлежит обязательной защите в соответствии с действующим законодательством. Т.е. в случае взлома и обращения пользователя в соответствующие структуры, у магазина будут серьезные проблемы.
2. Футболки бывают разные. Мало кому из клиентов будет приятно узнать, что инфа о таких его заказах вышла за пределы магазина. Хотя геи и лесби наверное тоже бывают разные, не спорю
KV>>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427
К>>Поясни, в чём тут "пересечение"?
SH>
SH>Основную вину за кражу денег потерпевшие возложили на банк. "Альфа-банк допустил халатность при разработке системы безопасности для удаленной работы со счетами. Ну как можно обеспечить сохранность наших средств, если банк высылает постоянный пароль и пароли на операции по счетам с помощью SMS", — возмущается Андрей.
SH>Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.
А вот это уже бред, да.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, 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. Все пароли должны храниться и передаваться только в зашифрованном виде с использованием стойких криптографических алгоритмов.
которое также нарушалось, однако аудиторами этот факт также замечен не был.
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>Так вот двухфакторная аутентификация подразумевает передачу пользователю обоих ключей по различным каналам (в противном случае в ней просто нет смысла и она является не более чем способом осложнить жизнь рядовым пользователям).
Вполне логичное требование.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Eugeny__, Вы писали:
KV>>Рекомендую почитать, там не так уж и много. Паранойи нет, но стандарт достаточно сильный. E__>Эх, будет время...
Начать можно с этого: http://www.pcidss.ru/files/pub/pdf/pcidss_v1.2_russian.pdf В принципе, этим можно и закончить, если нет желания углубляться в детали и существующие практики.
E__>>>А случаи, когда мошенник знает данные карты, логин-пароль на вход в инет-банкинг, номер телефона, и не стремается явиться лично в салон с поддельной доверенностью... Это уже немного за пределами. Да и зацепка для ментов очень жирная получается. Исход, правда, зависит от желания "Альфы" заморачиваться, но это другое.
KV>>Тех парней так и не нашли. Это к вопросу о зацепках.
E__>См. выделенное.
Ну не знаю. Банк возместил все средства клиентам за свой счет (в этом плане АБ крайне заботится о своем лице. Когда их банкомат принял у меня 10 штук и, радостно хрюкнув, попрощался, а деньги на счет так и не перевел и чек не распечатал, мне их вернули на следующий день после оформления претензии).
По идее, желание заморочиться у АБ должно было возникнуть
KV>8.4. Все пароли должны храниться и передаваться только в зашифрованном виде с использованием стойких криптографических алгоритмов.
KV>которое также нарушалось, однако аудиторами этот факт также замечен не был.
Лично у меня есть подозрение, что пароли
а) хранятся на стороне АБ только в зашифрованном виде (если вообще) и
б) передача через SMS означает шифрование протоколом GSM, в котором вроде бы алгоритмы вполне себе стойкие и криптографические.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Sinclair, Вы писали:
S>б) передача через SMS означает шифрование протоколом GSM, в котором вроде бы алгоритмы вполне себе стойкие и криптографические.
Но скорее всего, они так и отмазались. Дескать используется канал операторов связи... его безопасность обеспечивается ими в соответствии с Законом о связи... вот договора...
Здравствуйте, kochetkov.vladimir, Вы писали:
k> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется
Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
Здравствуйте, Anton Batenev, Вы писали:
AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).
Опять же аутентификация в HTTPS на сертификатах — куда уж мощнее...
Можно самому реализовать любую схему Challenge/Response со взаимной аутентификацией (благо посчитать MD5 в JS не проблема) ну и т.п.
На вскидку только не нагуглил удачного обзора — если есть вопросы по конкретным схемам, могу поискать материал.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Anton Batenev, Вы писали:
AB>>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде? DOO>Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS). DOO>Опять же аутентификация в HTTPS на сертификатах — куда уж мощнее... DOO>Можно самому реализовать любую схему Challenge/Response со взаимной аутентификацией (благо посчитать MD5 в JS не проблема) ну и т.п. DOO>На вскидку только не нагуглил удачного обзора — если есть вопросы по конкретным схемам, могу поискать материал.
Кстати, не напомнишь ту ссылку, где ты бодался по поводу передачи пароля в открытом виде? Что-то не могу найти
KV>Кстати, не напомнишь ту ссылку, где ты бодался по поводу передачи пароля в открытом виде? Что-то не могу найти
Откопал-таки: http://rsdn.ru/forum/web/3611508.aspx
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Не в тему, но гугля наткнулся на довольно интересную идею: http://prpl.stanford.edu/papers/soups10j.pdf
Да уж... Действительно оригинально
.
http://eprint.iacr.org/2010/013
