Что означаете «утекла база»?

Question

[Rustam Azizov]

Берясь за написание бэкэнда, каждый раз занимаюсь вопросом хеширования паролей — стандартные меры. И хоть мне приблизительно понятно для каких сценариев это делается, мне не понятно как это может помочь защитить данные от несанкционированного изменения. Если взломщик получает достаточный доступ, чтоб «стырить» её с сервера, то не может ли он изменить данные по своему усмотрению напрямую? На что идёт упор, на то, что взломщик запутается в бизнес-логике? Или его каким-то образом в действиях ограничивает конфигурация сервера (если это так, то почему она допускает его к чтению базы)? Или у него нет доступа к самой базе, только возможность получить её дамп? В общем, если у вас есть опыт, прошу описать вкратце возможный процесс взлома и как хеширование помогает в данном случае — буду благодарен. Гугл ничего полезного не выдал, поэтому обращаюсь к вам.

Answer 1

[АртемЪ]

Что означаете «утекла база»?

Это значит что данные содержащиеся в базе получил тот кому они не предназначались.

прошу описать вкратце возможный процесс взлома и как хеширование помогает в данном случае

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

Поэтому пароли в базе данных хранить нельзя! И все нормальные сервисы вроде Тостера не хранят пароли в базе.
Но сервису то нужно как-то аутентифицировать пользователя.
Если в базе хранится пароль - все просто. Пользователь отправил Тостеру пароль, тот проверил, что он совпадает с хранящимся в базе, и все - пользователь подтвержден.
А если пароли хранить нельзя?
Для этого используется хэширование.
В базе данных Тостера хранится не пароль, а хэш пароля - например пользователь Вася создал пароль qwerty, Тостер вычисляет хэш этого пароля -d8578edf8458ce06fbc5bb76a58c5ca4 и сохраняет его в базу данных.
Для того чтобы зайти на Тостер Вася отправляет ему свой пароль - qwerty, Тостер вычисляет его хэш и сравнивает хэш с тем что хранится в базе данных. Если они совпадают - пользователь подтвержден.

В итоге пароли в базе не хранятся, и если злоумышленник скопирует базу себе ( база утекла) он не будет знать паролей пользователя. И не сможет под именем Васи зайти на тТостер.
Все что знает злоумышленник это хэш - d8578edf8458ce06fbc5bb76a58c5ca4

Ну вот примерно так если коротко, и очень упрощенно.

Хэширование никак не защищает содержимое базы и не мешает утечке базы - оно защищает от утечки паролей и только.

Answer 2

[Сергей Горностаев]

Предположим, что БД Тостера хранит пароли в открытом виде. Предположим, что недобросовестный сотрудник унёс с работы дамп и продал на хакерском форуме. Теперь у покупателя есть имена пользователей, адреса их электронной почты и пароли. Для 90% пользователей пароль к Тостеру будет совпадать как с паролем к почтовому ящику, так и ко всем остальным ресурсам, зарегистрированным на ту же почту или тот же никнейм, вплоть до интернет-банкинга. А значит покупатель получит к ним ко всем доступ. Вот это и называется "утекла база".

Comments

[Rustam Azizov]

Я так понял из ваших слов, что «утечка базы» — это именно случай с «угоном» дампа базы, а не получение доступа к консольной утилитке, типа psql, верно?

[Rustam Azizov]

Хотя, в принципе, тут и думать нечего. Я просто усложнял себе вопрос, который на деле достаточно прост. Вы прояснили картинку, спасибо.

[Сергей Горностаев]

Rustam Azizov, просто угон дампа случается чаще, чем несанкционированный доступ к СУБД. Но и такое тоже бывает. Сколько я по молодости данных стянул через дырявые сайты - подумать страшно.

[SagePtr]

Rustam Azizov, это случай, когда содержимое базы данных стало известно третьим лицам. А как именно оно к ним попало - через недобросовестного сотрудника, через скопированный файл дампа, через дырку в похапе или через консольную утилиту - это уже роли не играет.

Answer 3

[CityCat4]

и как хеширование помогает в данном случае

Все очень просто.

Вы стырили чей-то кейс с документами. Открываете его, перебираете бумаги и среди них находите металлическую коробочку, в которой что-то шуршит, но ключей к ней у Вас нет. Как ее открыть? Либо перебором имеющихся ключей и попыткой снять отпечаток у хозяина (подбор паролей и социальная инженерия) либо попыткой сломать ее, распилить, раздавить (прямой перебор). Подбор паролей сработает (может быть) если владелец лох, а возможность сломать оценивается прочностью металла (стойкостью шифра).
Пароль не хранится в БД. В БД хранится некий цифровой код, который получается из строки пароля с помощью неких вычислений - это собственно и есть хэширование - получение однозначной связи между текстом и цифровым кодом (хэшем), причем обратной связи НЕТ. То есть, по тексту можно получить хэш, но по хэшу текст получить невозможно (если это не так, значит алгоритм взломан).
Для проверки пароля считается хэш от полученной от пользователя строки, если совпали - все, вуаля.
Хотя утечка БД с открытыми данными даже и без паролей - крайне пренеприятная вещь.