Комментарии 29
НЛО прилетело и опубликовало эту надпись здесь
A: Да, но проблема в том, что это надо сделать одновременно.
Мне кажется что ребята лукавят: если у одного из клиентов сперли базу, не станут они менять ключи, так как при этом придется апдейтить хэши всем их клиентам. Так что утекшая таблица вполне может лежать и ждать компрометации ключей. Причем, если я правильно понял принцип работы, в случае компрометации ключей хэши даже перебирать не придется — они просто расшифровываются ключом. Разве нет?
PS Справедливости ради, для каждого клиента может быть свой комплект ключей. Тогда проблема решается достаточно просто. Правда, все равно клиент должен быть в курсе что его взломали.
Причем, если я правильно понял принцип работы, в случае компрометации ключей хэши даже перебирать не придется — они просто расшифровываются ключом. Разве нет?
Как я понимаю нет. Оно работает в одну сторону, т.е. имея пароль, данные из БД и приватные ключи бэкенда и сервиса можно понять, правильный ли пароль. Но имея данные из БД и приватные ключи бэкенда и сервиса пароль можно только подобрать.
PS Справедливости ради, для каждого клиента может быть свой комплект ключей. Тогда проблема решается достаточно просто.
Не могу сказать за докладчика, но думаю было бы вполне логично для каждого клиента, и даже для каждого приложения клиента иметь свой комплект ключей и в сервисе и на бекэнде.
Правда, все равно клиент должен быть в курсе что его взломали.
Согласен. Здесь наверное поможет профилактика — периодически полностью переустанавливать сервера и обновлять ключи.
Согласен. Здесь наверное поможет профилактика — периодически полностью переустанавливать сервера и обновлять ключи.
Я не выспался или получается что это практически равносильно вынести туже «соль» на отдельный сервис?
Если абстрагироваться от деталей, то это действительно похоже на то, что добавляется новая глобальная соль, которая находится на отдельном сервисе. В случае Facebook's password Onion, это было именно так.
Но не равносильно это потому что в случае Pythia и PHE ключ (который вы назвали солью) можно менять не зная ничего о пароле.
Соль поменять нельзя не имея пароля.
Но не равносильно это потому что в случае Pythia и PHE ключ (который вы назвали солью) можно менять не зная ничего о пароле.
Соль поменять нельзя не имея пароля.
Спасбо за конспект! Слайды тут, если интересно
www.dropbox.com/s/a4fctwy8nzlasao/Make.Passwords.Great.Again.Ermishkin.v3.pdf?dl=0
Можно было стукнуться в личку, я бы помог )
www.dropbox.com/s/a4fctwy8nzlasao/Make.Passwords.Great.Again.Ermishkin.v3.pdf?dl=0
Можно было стукнуться в личку, я бы помог )
НЛО прилетело и опубликовало эту надпись здесь
Вообще там скалярное умножение в группе точек эллиптической кривой, но я для простоты решил заменить на возведение в степень по модулю. Вот реализация, можете посмотреть gist.github.com/Scratch-net/37ae11e589ea3d17fe104a2630306042
Кстати, вот видос выступления, можно добавить
www.youtube.com/watch?v=y1MQyl13ssc
www.youtube.com/watch?v=y1MQyl13ssc
В докладе почему-то не упомянут SCRAM (RFC5802 etc.) Он работает на любых стандартных хэшах, без всяких там открытых/закрытых ключей, пароль пользователя никогда не покидает приложение/браузер. Идеологически ближе к Argon2, но долгий расчёт идёт на фронте, бэк делает только минимальные преобразования и ходит в базу. И клиент и сервер друг друга аутенифицируют.
Я не упоминал протоколы, которые требуют работы на клиенте, потому что ну, они требуют работы на клиенте. Если всякие PAKE в приложения еще можно встроить, то в вебе этого никто делать не будет
Года три с лишним назад самолично внедрил SCRAM-аутентификацию сначала в мобильном приложении, а потом коллеги сделали то же самое на сайте одной большой организации. До этого там передавались пароли по HTTPS почти в открытом виде, они же хранились в базе данных. Протокол SCRAM немного модернизировали так, что клиенты вообще не заметили миграции со старой схемы на новую.
Странно, что на слайде 7 упор делается на то, что длительные/прожорливые функции выполняются на сервере. Чтобы не грузить бэки все долгие расчёты должны быть на клиенте, благо сейчас они все достаточно мощные по памяти и процессорам.
И главное, что нет PKI, которую надо обслуживать.
Странно, что на слайде 7 упор делается на то, что длительные/прожорливые функции выполняются на сервере. Чтобы не грузить бэки все долгие расчёты должны быть на клиенте, благо сейчас они все достаточно мощные по памяти и процессорам.
И главное, что нет PKI, которую надо обслуживать.
Что значит «почти в открытом виде»? Насколько мне известно, TLS пока не взломан.
Так же при SCRAM сервер отправляет клиенту соль, позволяя выполнить precomputation атаку в случае, если злоумышленник её получит.
Современные решения не страдают этими болячками, но их надо имплементить и на клиентской и на серверной стороне, а делать этого никто не хочет
Так же при SCRAM сервер отправляет клиенту соль, позволяя выполнить precomputation атаку в случае, если злоумышленник её получит.
Современные решения не страдают этими болячками, но их надо имплементить и на клиентской и на серверной стороне, а делать этого никто не хочет
Что значит «почти в открытом виде»?
Они передавали MD5(password), считая это защищённым решением. Эти же данные хранили в базе без всяких солей и нонсов. Как их не взломали за несколько лет работы сайта я не знаю ;)
TLS пока не взломан
Я тоже так думал, пока мне антивирус не написал в отправляемом через gmail.com письме, что оно проверено, вирусов нет. Без пининга сертификата TLS бесполезен, хотя и работает в большинстве случаев. А пининг — это та ещё головная боль.
позволяя выполнить precomputation атаку
Насколько я помню, там с двух сторон передаются случайные нонсы, они помогут от такой атаки?
делать этого никто не хочет
Странное заявление. Если строится продукт (сайт, приложение, а то и всё сразу), то написать 200 строчек кода протокола с его модульными тестами и сколько-то строк доступа к базе данных на бэке — это не большая проблема по сравнению с медиаповодом в стиле «очередная утечка паролей у <тех, кто не хочет>». Хотя да, в большинстве своём архитекторы-аналитики в основном решают бизнес-задачи, им на реальную безопасность компании и клиентов глубоко фиолетово. И начинают шевелится только тогда, когда очередные пенетраторы им показывают список найденного ;)
Это кол-во информации, которая содержится в данных
Так говорить нельзя. Скорее, наоборот — больше энтропия, меньше информации. То есть, чем более случайный пароль (меньше информации), тем больше будет его энтропия (например, в битах).
В WikipediA:
Энтропия — это количество информации, приходящейся на одно элементарное сообщение источника, вырабатывающего статистически независимые сообщения.
Насколько я понимаю, сервис можно использовать чисто для экспериментов? Потому как отсутствуют какие-либо гарантии (SLA) и уверенность в том что он вдруг резко не станет очень платным и не прекратит существование.
Честно говоря, аутсорсить проверку паролей кому-то совершенно чужому — как-то очень стрёмно, ибо если что — то сервис превращается в тыкву, ничего не работает, пользователи негодуют и всё такое.
В Letsencrypt много кто заинтересован, посему шансы что он умрёт уж очень малы (несмотря на бесплатность), да и альтернативы есть, но тут совсем другое дело.
Честно говоря, аутсорсить проверку паролей кому-то совершенно чужому — как-то очень стрёмно, ибо если что — то сервис превращается в тыкву, ничего не работает, пользователи негодуют и всё такое.
В Letsencrypt много кто заинтересован, посему шансы что он умрёт уж очень малы (несмотря на бесплатность), да и альтернативы есть, но тут совсем другое дело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HL 2018. Конспект доклада «Make passwords great again! Как победить брутфорс и оставить хакеров ни с чем»