Что в этом хорошего? Цензура, цели которых декларируются как защиту населения от тупых фильмов, в итоге добрается до умных. Кто определяет тупость и художественную ценность фильма?
Суровой кары недостаточно. Нужна неотвратимая. Или условно-неотвратимая, чтобы хотя бы более половины взяточников реально были наказаны. А так — пусть хоть сожжение на медленном огне сделают, их все равно никто ловить не будет.
> Нет, не совсем правильно: лучше неизвестные взломшику биты в хэшируемой последовательности (именно пароль а не соль) расположить ближе к концу, т.к. они (биты) как раз оказывают наиболее сильное воздействие на результат хэширования.
Не очень понял фразу. Почему биты ближе к концу оказывают наиболее сильное воздействие на результат кеширования? Мне казало, что все биты в «правильном» хеше оказывают равное воздействие на результат
Как Вы получите циклический xor с новым паролем, не зная старого пароля? Если у Вас есть новый пароль и его xor со старым паролем, Вам не составит труда получить старый пароль, ничего не меняя напрямую. :)
Но — самое главное — как Вы измените соль, не меняя ничего в БД? :) Если Вы можете изменить соль в БД, Вы с тем же успехом можете изменить и сам пароль.
Соль является составной частью хеша пароля. :) Теперь Ваша задача — подменить соль (и, как следствие, хеш пароля на сервера). Если Вы это можете сделать, с тем же успехом можете подменить хеш, сделанный конкатенацией. Кроме того, в Вашей формуле есть пароль1. Если Вы его уже знаете, то заменить пароли можно штатными средствами. :)
Скорость работы scrypt вполне удовлетворительна — порядка сотен логинов в секунду. Потребление памяти ровно на это время. Достаточно для аутентифицирования легальных пользователей, плохо для брутфорса.
Если у Вас ценность сайти и информации на нем высока, Вы раскошелитесь на дорогое и надежное решение, верно?
На том scrypt, в частности, основан. Плюс потребление памяти. Чем более ресурсоемко (неоптимизируемо ресурсоемко) вычисление хеша, тем труднее его сломать брутфорсом.
Профит от такой «защиты» совершенно минимальный. Ну да, стальная дверь с системой засовов, подпертая тростинкой, защищена лучше, чем просто стальная дверь с системой засовов, я тут даже спорить не буду.
Это как можно поменять? :) Если у Вас хеш пароля представляет из себя конкатенацию соль + разделитель + хеш-функция(соль циклический_xor пароль), как тут заменить пароль, не меняя хеша? И уязвимость в Телеграмме не имеет никакого отношения к данному способу «соления».
Но принцип Керкгофса позволяет предположить, что исходники Вашей системы не менее доступны, чем содержимое БД. С большой вероятностью они известны как минимум разработчикам, и увольнению любого из них сразу компрометирует систему. Неужели Вы заставите пользователей менять пароли каждый раз, когда происходит замена в коменде разработчиков?
scrypt основан на PBKDF2 и использует его, его защищенность как минимум не меньшая, чем PBKDF2. Правда, это и не значит, что превосходит :) Вы правы в том, что PBKDF2 оттестирован качественнее, чем bcrypt и scrypt
Пользователь аутентифицируется в системе сравнительно редко, так что такого уж бурного роста пожирания ресурсов из-за алгоритма хеширования, скорее всего, не случится. С железом — понятно, VDS уже не хватит, но на большом проекте уже можно и на приличную железку раскошелиться. А вот чем это поднимет стоимость разработки, мне непонятно.
Злоумышленник по определению пытается параллелиться. И параллелиться очень помногу на современных видеокартах. И вот тут масштаб параллелилзации грубо пресекается объемом необходимой памяти.
Если веб-сервер работает на VDS, то, скорее всего, такие требования к безопасности паролей на нем лишние.
А почему бы попросту не ксорить пароль солью перцем (хотя я считаю, что перец — мера бесполезная)? Тогда вопрос «куда добавлять приправы — в начало или конец» отпадет сам собой.
Не очень понял фразу. Почему биты ближе к концу оказывают наиболее сильное воздействие на результат кеширования? Мне казало, что все биты в «правильном» хеше оказывают равное воздействие на результат
Но — самое главное — как Вы измените соль, не меняя ничего в БД? :) Если Вы можете изменить соль в БД, Вы с тем же успехом можете изменить и сам пароль.
Если у Вас ценность сайти и информации на нем высока, Вы раскошелитесь на дорогое и надежное решение, верно?
Ветку я видел, но мне кажется, что увод паролей неактивных пользователей — тоже вполне себе бедствие.
Если веб-сервер работает на VDS, то, скорее всего, такие требования к безопасности паролей на нем лишние.