Первое, ИМХО, несерьезно: генерация соли почти не требует ресурсов.
Со вторым согласен, но для этого нет никакой необходимости использовать логины: достаточно хранить соль отдельно от БД.
Извините, не соглашусь.)
Чем соль «1937569admin» лучше «193756984938»? Добавление имени пользователя только лишь уменьшает длину той «эффективной» части соли, которая формируется случайно. А если мы в любом случае генерируем соль, то зачем нам усложнять алгоритм и дописывать к ней логин пользователя, когда проще (и правильнее) саму соль увеличить на несколько байт?
Делаем отдельный сервер
ОК, сделали.)
Злоумышленник находит уязвимость, заливает на веб-сервер шелл, заходит под привелегированной учетной записью… После чего внимательно изучает, с какого там внешнего сервера приходит соль и к какому порту нужно подключаться, чтобы ее получить.
Другой вопрос уже, что многие злоумышленники могут посмотреть на эту навороченную конструкцию и просто слиться, ибо не хочется это все разматывать. Но если хакер решит заняться делом всерьез — внешний сервер ничем не поможет.
Я не специалист, но попробую высказать свои мысли.)
добавить логин юзера
Логины обычно довольно простые и часто повторяются (в смысле на разных сайтах люди используют один логин). Поэтому использовать логин в качестве соли вряд ли целесообразно — ее легко узнать, легко подобрать.
С другой стороны, использовать логин вместе с солью, по большому счету, бессмысленно (если соль хороша, то прибавление к ней логина мало что изменит)
хранить соль где-то отдельно
Это, ИМХО, нереализуемо в принципе: чтобы иметь возможность аутентифицировать пользователя, веб-приложение должно иметь возможность эту соль считать. При этом неважно, где она будет храниться: в БД, в файле на диске, на внешнем FTP-сервере — в любом случае при компрометации web-сервера злоумышленник получит доступ к этой соли.
Единственный повод хранить соль не в БД, а где-то еще — это некоторое снижение рисков утечки паролей в том случае, если злоумышленник получит только доступ к БД (например, через SQL-инъекцию), но не сможет получить доступ к файлам и шеллу. Но стоит ли игра свеч — сказать сложно.
Вообще было у меня в планах еще несколько статей — про динамические блоки, про пример взаимодействия с внешним приложением — но что-то времени стало не хватать катастрофически. Не знаю, когда теперь закончу и закончу ли вообще.
Честно говоря, я изрядно удивлен, что шесть-то смог написать.))
Круто!
Жаль, что я почти не умею в реверс-инжиниринг...(
А еще заинтересовала вот эта фраза:
Специалисты ESET оперативно связались с разработчиками этого ПО и сообщили им о найденной уязвимости. В течение 24 часов специалисты Ksoft исправили уязвимость и выпустили новую версию Uploader! v 3.6.
Как выглядит оповещение о уязвимости? У вас есть какой-то стандартный шаблон письма?
Со вторым согласен, но для этого нет никакой необходимости использовать логины: достаточно хранить соль отдельно от БД.
Чем соль «1937569admin» лучше «193756984938»? Добавление имени пользователя только лишь уменьшает длину той «эффективной» части соли, которая формируется случайно. А если мы в любом случае генерируем соль, то зачем нам усложнять алгоритм и дописывать к ней логин пользователя, когда проще (и правильнее) саму соль увеличить на несколько байт?
ОК, сделали.)
Злоумышленник находит уязвимость, заливает на веб-сервер шелл, заходит под привелегированной учетной записью… После чего внимательно изучает, с какого там внешнего сервера приходит соль и к какому порту нужно подключаться, чтобы ее получить.
Другой вопрос уже, что многие злоумышленники могут посмотреть на эту навороченную конструкцию и просто слиться, ибо не хочется это все разматывать. Но если хакер решит заняться делом всерьез — внешний сервер ничем не поможет.
Логины обычно довольно простые и часто повторяются (в смысле на разных сайтах люди используют один логин). Поэтому использовать логин в качестве соли вряд ли целесообразно — ее легко узнать, легко подобрать.
С другой стороны, использовать логин вместе с солью, по большому счету, бессмысленно (если соль хороша, то прибавление к ней логина мало что изменит)
Это, ИМХО, нереализуемо в принципе: чтобы иметь возможность аутентифицировать пользователя, веб-приложение должно иметь возможность эту соль считать. При этом неважно, где она будет храниться: в БД, в файле на диске, на внешнем FTP-сервере — в любом случае при компрометации web-сервера злоумышленник получит доступ к этой соли.
Единственный повод хранить соль не в БД, а где-то еще — это некоторое снижение рисков утечки паролей в том случае, если злоумышленник получит только доступ к БД (например, через SQL-инъекцию), но не сможет получить доступ к файлам и шеллу. Но стоит ли игра свеч — сказать сложно.
password_hash().А откуда
password_hash()возьмет соль и где будет ее хранить?Вообще было у меня в планах еще несколько статей — про динамические блоки, про пример взаимодействия с внешним приложением — но что-то времени стало не хватать катастрофически. Не знаю, когда теперь закончу и закончу ли вообще.
Честно говоря, я изрядно удивлен, что шесть-то смог написать.))
Никогда бы не подумал. Круто.)
А ссылки на источники можете привести? Хочу посмотреть — может, там еще картинок имеется.)
<irony>5 ГБ хватит всем
</irony>Интригует.)
Жаль, что я почти не умею в реверс-инжиниринг...(
А еще заинтересовала вот эта фраза:
Как выглядит оповещение о уязвимости? У вас есть какой-то стандартный шаблон письма?