Почему не стоит подавать документы через сайт Московского Политеха, какая угроза персональным данным абитуриента и к чему может привести утечка данных? Обо всем этом — в данной статье.
Дисклеймер: я не квалифицированный специалист по компьютерной или информационной безопасности. Цель статьи — ознакомить читателя с имеющейся «недоработкой» сайта Московского Политехнического Университета и дать повод задуматься о других способах подачи документов, если читатель особенно трепетно относится к размещению персональных данных в интернете. Приятного чтения!
Как родилась статья
В связи с обновлением правил приема 1 апреля 2023 года началась работа приемной комиссии Московского политехнического университета (он же МПУ, он же Политех). Плохо это или хорошо — решать каждому самостоятельно, однако, я считаю, что если подать документы раньше, то это позволит избавиться от лишних забот во время всеобщей волны подачи документов. В такие периоды из головы и не такое может вылететь.
Политех я выбрал как один из вузов для поступления в магистратуру после выпуска с «айтишной» специальности одного из лучших региональных вузов. А МПУ как раз располагает неплохим общежитием, а также парочкой интересных мне программ. Поэтому недолго думая я зарегистрировался на сайте Политеха, чтобы подать документы онлайн, не тратя деньги на перелет в Москву или на отправку почтой.
Примечание: изначально, конечно, я хотел подать через Госуслуги — все-таки к ним больше доверия в плане сохранности персональных данных. Но там приемная кампания начинается лишь с июня, поэтому вариант оставался один — регистрация личном кабинете на сайте университета.
Что знает Политех об абитуриенте
Для регистрации стандартно требуется ФИО, дата рождения, почта, пароль и, — внимание — паспортные данные. Не знаю, зачем они нужны уже на этом этапе. Для того чтобы ботов и фейков не регистрировали?
Уже «звоночек», но да бог с ним, регистрируемся. Это ведь сайт известного столичного университета, мои персональные данные наверняка будут в безопасности :)
После регистрации сайт сразу предложил заполнить анкету, в которую любезно и автоматически были вписаны введенные на предыдущем этапе мои паспортные данные.
В анкете требуют также стандартный набор данных о себе для поступления: гражданство, сотовый, прописка, адрес проживания, сканы СНИЛСа и паспорта (в т. ч. 19 страница) и т. п.
В итоге получается неплохой набор персональных данных абитуриента:
- ФИО;
- Дата и место рождения;
- Пол;
- Email (он же логин) и пароль;
- Номер мобильного (или даже два, с учетом запасного);
- Данные паспорта (первая страница, страница с пропиской и 19 страница, на которой находятся данные о предыдущих и заграничных паспортах) и его сканы;
- Номер документа СНИЛС и его скан.
Все это хранится на серверах МПУ. И пароль в этом списке неслучайно. Политех знает логин и пароль абитуриента. Он сам дает это понять, высылая после регистрации на указанную почту письмо с логином и паролем для входа.
Давайте просто сделаем вид, что не видим опечаток в автоматической рассылке.
Почему хранить пароли юзеров — плохо?
В письме выше Политех прислал мне логин и пароль. Для того чтобы вставить в письмо эти данные система должна их откуда-то взять. Системы берут данные из базы данных, но перед этим данные должны попасть в эту базу. Очевидно, что логин и пароль были записаны в базу как обычный текст после регистрации — после отправки на сервер формы с логином, паролем, ФИО и т.п.
Вывод: логины и пароли абитуриентов (а может и не только) Политех хранит в базе «как есть». И нет гарантий, что после отправки этого письма зарегистрировавшемуся эти данные пропадают из базы.
Проблема заключается в том, что, как и (почти) любая база данных, база Политеха не защищена от утечек на 100%. Равно как и вся система не защищена от взлома на 100%. Соответственно, данные из базы могут попасть в руки злоумышленников или вовсе в открытый доступ. В данном случае, «стащив» лишь логины и пароли пользователей, злоумышленники могут получить доступ ко всему списку персональных данных, указанных в предыдущем разделе статьи. А это не есть хорошо, думаю, и так понятно.
Как можно было бы решить проблему
— Но ведь для авторизации пользователя система должна знать его логин и пароль! Нужно ведь знать правильный пароль ввел юзер или нет, — возразит неравнодушный читатель.
— Правда, но лишь отчасти, — ответит автор.
Возможное решение — хэширование. Если быть точным, то аутентификация с помощью хэша.
Небольшой ликбез: хэширование — это процесс преобразования каких-либо данных в строку фиксированной длины, состоящей из букв и цифр. Этот процесс осуществляется с помощью т.н. криптографических хэш-функций, к примеру, SHA-1, RIPEMD-160, MD5 и др.
Для интересующихся оставлю ссылку на хорошую статью, в которой автор описывает их «природу» более подробно.
Если говорить по сути этой статьи, то хэширование относится к тем видам математических операций, легко вычисляемых «в одну сторону», но довольно сложно обращаемых «вспять».
Пример: ученик начальной школы сможет перемножить два простых числа, например,
709 * 941 = 667169. Но провернуть обратную операцию — узнать множители из произведения — уже задача нетривиальная.
Аналогично с хэшированием: можно хэшировать слово «амогус» с помощью функции, например, SHA-1, получив строку «f49440bf4d3ce333c46b6bc86618937fe39eaa2e». Но для того, чтобы перевести эту строку обратно в слово потребуется довольно много времени и вычислительных мощностей.
Теперь рассмотрим пример касательно авторизации:
Допустим,
мой логин — user1,
а мой пароль — qwerty123 (никогда не используйте такой пароль).
Их я придумал при регистрации на каком-то сайте.
На первый взгляд системе можно просто взять их в таком виде и записать в базу данных или в виде пары «логин-пароль», или в условную таблицу со столбцами «Логин» и «Пароль», или как-либо еще. А потом, когда пользователь пытается войти на сайт, сравнивать то, что он ввел в полях «Логин» и «Пароль», с тем, что хранится в базе данных соответственно.
Логин совпадает?
Пароль совпадает?
Отлично, добро пожаловать на сайт, user1!
Это было бы хорошо, если бы не возникала описанная ранее проблема с безопасностью и утечками.
Проблема решается хэшированием (как минимум) пароля.
Введенный пароль хэшируется при регистрации аккаунта, и в базу данных на сервере записывается этот самый хэш — сгенерированная хэш-функцией строка символов.
В моем случае:
qwerty123 —> 5cec175b165e3d5e62c9e13ce848ef6feac81bff.
Таким образом, вместо пары «логин-пароль» (user1 — qwerty123) в базе хранится пара «логин-хэш» (user1 — 5cec175b165e3d5e62c9e13ce848ef6feac81bff), которая вызывает намного меньше интереса у «воришек данных».
По этой причине известные компании типа Google, Apple, Microsoft и пр. не присылают пароль на почту, если нажать «Забыли пароль». Они просят придумать новый пароль потому, что старый они просто не знают. У них есть хэш, сделанный на основе пароля, но нет самого пароля.
В таком случае процедура авторизации проходит подобным образом: после нажатия пользователем кнопки «Войти» пароль сначала прогоняется через тот же алгоритм хэширования, который использовался при регистрации, и только затем отправляется на сервер, чтобы провести проверку: верен ли логин и верен ли хэш.
(Также возможен вариант с хэшированием пароля уже на сервере, это увеличит производительность сайта на клиенте, но с точки зрения безопасности все же не рекомендуется.)
Если значения логина и хэша совпадают с тем, что было записано в базу при регистрации — «добро пожаловать на сайт, user1». Если нет, то «неверный логин или пароль».
Это решение намного безопаснее с точки зрения потенциальных утечек. Как минимум, это осложнит доступ к данным со стороны недоброжелателей. Однако все мы понимаем, что ничего невозможного нет :)
Будьте аккуратны, уважаемые читатели.
Если компания присылает в письме ваши реквизиты для входа, стоит десять раз подумать, прежде чем оставлять на ее сайте какие-либо персональные данные.
Комментарии (34)
Xeldos
19.04.2023 22:01+25Вам не приходило в голову, что ваш пароль вуз знает примерно полсекунды? Ну то есть сколько времени потребуется для отправки вам письма. А в базу данных он пишется шифрованный. И письмо, кстати, тоже может уйти шифрованным.
То есть конечно вседа есть вариант, что копия письма отправляется на почту всем сотрудникам вуза, а службе ИТ - по два раза, но тут уж вопрос доверия.
Вот если бы он вам на предложение восстановить учётные данные отправил ваш пароль - вот тогда ай-яй-яй.
Ну и это. Хабр - не жалобная книга. А ещё проводить здесь ликбез на тему "что такое хеширование пароля" - несколько странно. Ваши предложения по хранению учётных аднных абитуриентов следовао бы направить в приёмную комиссию, а те передали бы в ИТ. Что сказала бы служба ИТ - скорее всего, останется в стенах вуза.
Ostin_66
19.04.2023 22:01+3А никому не приходило в голову, что запрашивать и делать СКАН паспорта это излишняя информация для универа? в принципе!!
iig
19.04.2023 22:01+1И письмо, кстати, тоже может уйти шифрованным.
Не может. Разве что клиент и сервер заранее обменялись ключами.. Никогда про такое не слышал.
Krouler7
19.04.2023 22:01-1Протокол SMTP поддерживает передачу данных с SSL/TSL.
iig
19.04.2023 22:01+2Это транспортный протокол. Нельзя просто взять wireshark и сниффить траффик. Но после того, как письмо принято, его читает спамфильтр на сервере, антивирус, возможно, пишет какие-то логи, возможно, сохраняет какие-то временные файлы.. И так на каждом сервере.
avacha
19.04.2023 22:01+1Все очень просто на самом деле. Аудитории Хабра сложно в этом поверить, но современный студент/студентка зачастую не имеет компьютера вовсе! ПК/ноутбук "устарел", ребята 17-18 лет, приходя в ВУЗ - пользуются условными айфонами с инстаграммами, ВК и т. п. У половины вообще нет электронной почты - они ей не пользуются, регистрация в сервисах у них по номеру телефона, а общение - в мессенджерах. О том, что учетная запись Apple или Google в том числе и есть адрес электронной почты - знает процентов 10 от силы, и то - ей не пользуются. Своеобразная ситуация, ведь работать в электронной образовательной среде ВУЗа (в 99% случаев - это опенсорсный Moodle в различной степени допиленности под нужды универа) нужно под учетной записью, а она в свою очередь в 99% привязывается к электронной почте (отправка ссылок для восстановления пароля и т.п)
Dima954
19.04.2023 22:01+1Скажу больше, многие даже и не знают, что есть такая учётная запись Google, так как воспользовались услугой "настройка телефона" при покупке, а заботливый настройщик не стал грузить клиента такими излишними деталями, как адрес почты, или, упаси боже, пароль.
TheRaven
19.04.2023 22:01+9Из того, что сайт прислал логин и пароль после регистрации совсем не следует, что пароль хранится в БД в открытом виде.
Вот если они при запросе восстановления пароля пришлют старый пароль на почту — тогда да.
UPD: я когда-нибудь научусь обновлять комментарии перед написанием своего
letow Автор
19.04.2023 22:01-1Обязательно научитесь, как и я научусь писать качественные статьи на Хабр :)
Спасибо.
SergeyDeryabin
19.04.2023 22:01+2Ну и имя с фамилией могли бы не замазывать, я полагаю будет не много записей примерно в это время, с почтой на Яндексе, и проживающего во временной зоне +1 - +2 часа от Москвы
sepetov
19.04.2023 22:01+1Возможно, он вообще единственный за неделю. Если вузу вдруг потребуется вычислить жалобщика, то там ещё набор признаков:
шрифт в письме не моноширинный, но в одном замазанном месте длина текста всё равно опознаётся: после "Здравствуйте" в письме однозначно 14 символов в имени (или имя + фамилия, смотря что там в приветствии). И первая буква однозначно "Г" или "П".
если уж пароль (ну вдруг?) и правда хранится в открытом виде, то первый символ - это однозначно "H", что наверняка сужает круг поиска уже до одного подозреваемого
Такой несложной дедукцией даже среди десятков абитуриентов сложно затеряться.
Для наглядности
Конечно, открытость пароля маловероятно, поэтому два последних признака - это уже для гурманов.
SergeyDeryabin
19.04.2023 22:01+1Личный кабинет абитуриента на Yii (не знаю первая или вторая, скорее вторая версия) сделан. Конечно можно и там пароли положить plain text-ом но вероятность крайне мала
Metotron0
19.04.2023 22:01Я бы сказал, что в вариантах решения проблемы не упомянута регистрация/вход через сторонний сервис, вроде госуслуг, гитхаба или соц. сетей.
meaqese
19.04.2023 22:01+3Хехе, автор конечно чутка поспешил с выводами) И ещё в комментах выше указали что лучше не стоит отправлять пароли на почту, в целом я согласен, но всё таки у данного способа есть очень такой жирный плюс - сложные пароли которые пользователь не использует на других сайтах, т.е. учитывая то что люди в большинстве случаев используют слабые пароли, да и ещё один пароль на несколько ресурсов, будет разумно генерировать его сайту и отправить по почте. Это закроет сразу как минимум две дыры.
По поводу хэширования пароля на клиенте - довольно странное предложение, мне приходилось писать брут/чекеры на многие ресурсы, но мало сайтов где хэширование пароля на клиенте, и они прекрасно живут. Да и ещё, если сравнивается тот же хэш от клиента с тем что в БД, получается если кто-то получит хэшированный пароль (даже без реального пароля), он сможет просто отправлять его обойдя ваш клиентский JS и тем самым успешно аутентифицируется.В таком случае процедура авторизации проходит подобным образом: после нажатия пользователем кнопки «Войти» пароль...
Но ведь для авторизации пользователя система должна знать его логин и пароль! Нужно ведь знать правильный пароль ввел юзер или нет
Авторизация != аутентификация.
letow Автор
19.04.2023 22:01Авторизация != аутентификация.
Да, произошла подмена понятий. Ошибка и впрямь глупая.
всё таки у данного способа есть очень такой жирный плюс
Этот способ я не упоминал в статье (хотя может и стоило), т.к. этим способом не пользуется сайт этого вуза. Но это действительно может быть удобно и разумно в ряде случаев.
если кто-то получит хэшированный пароль (даже без реального пароля)
Если честно, не могу представить, как можно получить хэшированный пароль без реального пароля. Если перехватом каким-либо, то с таким же успехом можно перехватить и нехэшированный пароль. Можете пояснить, что Вы имели в виду?
По поводу хэширования пароля на клиенте - довольно странное предложение
Я посчитал, что это безопаснее для пользователя, чем посылать серверу свой пароль, пусть даже через https. Если Вы разбираетесь в теме и поделитесь какими-нибудь good practices, то буду крайне признателен.
Спасибо за развернутый комментарий.
IvanPetrof
19.04.2023 22:01+6Вы писали, что если пароли из базы "утекут", то злоумышленник сможет получить доступ к личному кабинету и увидеть персональные данные.
В предложенном вами способе, когда на сервере хранится хэш пароля - есть смысл, (так и делают). Но далее вы предлагаете при входе хэшировать пароль на клиенте, и передавать серверу тот самый хэш, сравнив который со своим - сервер вас пустит. Ну так это ничем не отличается от варианта нехэшированного пароля.
Объяснение:
Представьте себе, что утекла база хэшированных паролей. Да, сами пароли мы не знаем, но нам они и не нужны, если для входа на сервер, нужно послать лишь хэш (а он у нас как раз и есть).
AlanRow
19.04.2023 22:01ничем не отличается от варианта нехэшированного пароля
Немного отличается, т. к. если пользователь использует 1 пароль для разных сайтов, то при утекании пароля в чистом виде можно будет применить его везде, где использовался этот же пароль, а при утекании хэша все будет зависеть от алгоритмов хэширования и стойкости к коллизиям первого рода
Но в целом, да - хэшировать на клиенте смысла нету, т. к. при передаче по HTTPS данные все равно шифруются, а вводить свои данные на HTTP, это уже крайне неосторожно
gmtd
19.04.2023 22:01Просто представьте (реальный опыт) что злоумышленник получил доступ к серверу, подредактировал php (или иные) файлы и записывал какое-то время логины-пароли пользователей.
В случае клиентского хэширования другие опасности - знание хэшированной базы данных дает возможность логина
Везде свои плюсы и минусы
Wesha
19.04.2023 22:01+3Все обсуждают пароли, хэширование, и хоть бы одна живая душа вспомнила, что от чистого хеширования пользы не шибко много, потому как есть такое слово, сЫнки —
Родинарадужные таблицы, в наше время солить пароли надо.IvanPetrof
19.04.2023 22:01Мы до соли просто ещё не добрались)). Соль помогает от брутфорса слитых хэшей. А в подходе автора более фундаментальные проблемы (при которых брутфорсить хэши может и не понадобиться)
inkelyad
19.04.2023 22:01+2А есть еще такая экзотика как SRP (статья на хабре). Но все равно, кажется, уже давно пора начинать пользоваться всякими WebAuthn и производными от него.
gmtd
19.04.2023 22:01+7Статья - необоснованный наезд на ВУЗ, вне зависимости от того, как последний хранит пароли. Доказательств хранения текстом в БД нет. Сервисов/сайтов, которые присылают пароль по email - хватает, хотя эта практика и "не бест".
Непонятно одно - получить "айтишного" бакалавра в одном и "лучших" нестоличных вузов, и зацепиться за такую ерунду?
ildarz
19.04.2023 22:01У нас через собеседования в техподдержку проходит порядочно людей, учившихся в том числе на ИТ или ИБ специальностях и предполагающих дальше по профилю работать. И увы, это далеко не худший случай.
arshavina
19.04.2023 22:01Если есть банковская карта или симка любого оператора - можно забыть о "конфиденциальности" своих данных.
gregs0n
19.04.2023 22:01+2Подача документов через госуслуги - это такая дичь, вы себе даже не представляете. Если есть возможность подать доки через сайт вуза, то лучше это делать так.
SergeyDeryabin
19.04.2023 22:01По хорошему, следовало бы написать тем, кто занимается поддержкой сайта. А дальше уже в зависимости от ответа или не ответа. Но будь так и статьи бы не было, скорее всего.
А так довольно громогласные обвинения, построенные на догадках, причем как большинство заметило, очень слабых
pyrk2142
Отправлять пароли письмом - довольно плохая практика. Но я не очень понял, почему сделан такой вывод:
Что мешает получить пароль, записать его хеш в базу данных, а сам пароль отправить письмом и нигде не хранить?
letow Автор
Да, вроде ничего не мешает делать так, я видимо не до конца понимаю работу бэкенда, как он может это провернуть, раз мне в голову не пришла такая мысль. Спасибо.
sovaz1997
Пароль может прямо из тела запроса отправится на почту, а хешированный пароль записаться в базу данных. Все это может произойти одновременно
aamonster
А зачем его вообще отправлять почтой? Так не принято. Ближайшая ситуация – юзер забыл пароль и сбрасывает его, тогда ему отправляется ссылка или код для сброса с ограниченным сроком действия. Чтобы избежать хранения пароля в почте.
iig
Пароль может случайно оказаться в своих собственных логах. Забыли debug отключить, например. Это же не криминал. Письмо пересылается через какое-то количество почтовых серверов (неизвестно кем настроенных), его читают почтовые фильтры, антивирусы, и, конечно же, никто не пытается его анализировать.
nfsue
Может быть МПУ и не хранит пароль в явном виде, но, например, НГТУ НЭТИ выдает ваш пароль при обращении в деканат :) По крайней мере так было 3 года назад. Так что проблема для некоторых организаций актуальна.