Comments 23
имея доступ к резюме соискателей через их аккаунт на портале, злоумышленники могут получить достаточно чувствительную информацию о бывших работодателях, что дает возможность подмены резюме или вакансий определенной компании для нанесения ущерба ее деловой репутации.

это как?
вот известно, что человек работал в фирме, и как это может повредить той фирме?

Позвонят, представятся HR/Бкхгалтер/Расчетчик со старого места работы, скажут что чего то недоплатили, давайте кинем на карту, только дайте данные карты — это как один из примеров.
(Это не призыв к действию. Просто пример)

Речь идет о том, что имея на руках резюме сотрудника можно как-то навредить бывшему месту работы. Серьезно, не понимаю, вот известно что человек работал в ООО «Ромашка». Как зная эту информацию можно навредить ООО «Ромашка»?
… выгрузка с утечкой данных содержала логины (адреса электронной почты пользователей) и пароли к аккаунтам (в открытом текстовом виде)

Знаете… Если честно я не верю в такую наивность разработчиков системы.
Правило Не хранить пароли в открытом виде, а только хэшированные лет 10 обсасывается на всех обучающих ресурсах.
По-моему только умышленно можно хранить пароли в открытом виде для своих не очень благонамеренных нужд. Так же, ни для кого не секрет, что много людей используют везде один и тот же пароль… Вот для чего могут собираться пароли в открытом виде.
И точно не сообщается, что за базу взломали. Никто не вникает, а может это была вот такая серая база, не для работы сайта нужная, а для вышеописанного.
не верю в такую наивность разработчиков
Ну, не знаю, за несколько лет мне два раза ставили задачу по переходу с одного алгоритма хэширования на другой. При этом указывали, что нужно всем-всем сбросить пароли и промежуточно хранить их в plaintext. Оба раза приходилось разжёвывать, что так делать нехорошо, нельзя и, вообще, можно даже не сбрасывая пароли обновить алгоритм хэширования. Во втором случае моё решение отвергли, т.к. не поняли.
Как, к слову, не сбрасывая пароли поменять алгоритм? Хотим от md5 отказаться в пользу чего-то другого.

Хэшировать уже данные хэши :)?
А новые пароли просто с новым хэшем

Нормальная практика, если старый алгоритм хэширования был прост и быстр, например,
$old_hash = md5($salt.$password);
Новый можно сделать:
$new_hash = md5(md5($salt.$password));
Т. е.
$new_hash = md5($old_hash);

Как вариант, можно при успешной авторизации хешировать пришедший пароль новым алгоритмом, а рядом хранить информацию о том, менялся ли алгоритм для этого пользователя.

Либо при логине перехешировать (когда известен plaintext), либо брать хеш от хеша, других вариантов вроде нет.

Хранить тип алгоритма как часть самого хеша.

Пример на php:

$dbRecord = 'somehash:1';
list($hash, $algType) = explode(':', $dbRecord);
Теперь, зная тип алгоритма мы можем аутентифицировать пользователя, сравнив его ввод с хешом.
Если аутентификация успешна, генерим новый хеш и добавляем в конец :2 и все последущие разы используем новый алгоритм.
Добавляем поле признак алгоритма хэша, по умолчанию 0 — текущий (md5)
При входе — если признак 0, то проверяем правильность старым хешем, если совпал, то хешируем пароль новым, обновляем хэш, ставим признак нового — 1. Если же признак уже = 1, то просто проверяем новым хэшем.
Ну, несколько лет назад тот же Superjob имел восхитительную привычку при смене пароля отправлять его на почту открытым текстом. В формате «Вы поменяли свои учетные данные, вот они, логин username@email.org, пароль qwerty». Причем я тогда так и не нашел, как это отключить. Сейчас, похоже, исправили.
Такая логина реализована в Amazon Cognito, при регистрации нового пользователя ему на почту приходит временный пароль, который он сменит при первом входе. Чем плоха такая тактика? По сути нет разницы между временным паролем и ссылкой, по которой можно выставить новый пароль.
Не временный. Именно после ручной смены приходит сообщение, «Вы изменили пароль, ваши данные для входа: логин такой-то, пароль такой-то». Ну вернее приходило в 2016 году, сейчас не приходит, поправили.
Да. И по ссылке тоже не скачать без телеги, просто не качается и всё.
Но речь о том, что утечка была не сейчас, а ещё почти два месяца назад. Поэтому фраза «Дамп с утекшей базой данных портала работы был датирован 23-им ноября 2019 года.» как минимум ошибочна, утечка была ранее 11 октября. Кто именно ступил — Коммерсант или denis-19 — решайте сами. Журналистика любит факт-чекинг, которого здесь не было.
Only those users with full accounts are able to leave comments. Log in, please.