Ответ на пост «Ваши личные фотографии в общем доступе!»16
Решил я тут проверить криптографическую стойкость ссылок на изображения, которые используются в Max. Для этого я отправил три изображения другому пользователю, и другой пользователь отправил три изображения мне, которыми не жалко поделиться со всем интернетом. Ссылки получились такими:
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2NotwhIfmcEG-AQ04...
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2NotOrCtArXBjq22l...
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2NotuCeSw_mahSxcJ...
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2Not3SBIKFh0j_uS4...
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2Not3eud5ZnHve_Kd...
https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2NotObvU-CP4zgDVe...
Как можно заметить, у параметра r есть префикс и постфикс, который, скорее всего, генерируется на основе каких-то метаданных (ID аккаунтов, ID чата, etc.), а возможно, является идентичным для всех пользователей Max. Выделим отличающиеся части ссылок:
whIfmcEG-AQ04SLHDttpwu
OrCtArXBjq22lCBwOCDEL-
uCeSw_mahSxcJfxo1C8gOO
3SBIKFh0j_uS4NxSE_Uc6e
3eud5ZnHve_KdN2h70ccLe
ObvU-CP4zgDVerJ9CWGMDu
Данная часть ссылки состоит из 22 символов. Учитывая, что параметр представляет собой Base64 строку, то количество возможных вариантов ссылок в данном случае равняется 64²², что примерно равно 5×10³⁹ возможных вариантов.
Представим такую невозможную ситуацию, что в базе данных изображений Макса находится триллион (10¹²) изображений. И у нас есть возможность совершать на сервера Max миллиард (10⁹) запросов в секунду. Тогда вероятность найти за сутки хотя бы одно изображение будет равняться (24×60×60×10⁹×10¹²)/(5×10³⁹) ≈ 1/10⁻¹⁴, что ИММОЛЕЙТ ИМПРУВЕД! Это означает, что возможность его подбора КРАЙНЕ МАЛА! Или, если серьёзнее, то понадобится примерно 274 миллиарда лет, чтобы найти одно изображение. Так что, если вы используете в качестве пароля строку из менее чем двадцати двух символов с алфавитом мощностью менее 64, то вас взломают раньше, чем найдут хотя бы какое-то изображение. В данном случае сложность сравнима с поиском подписи для JWT-токена другого пользователя. И также нужно учесть допущение, что ни один сервер в мире не выдержит миллиард запросов в секунду, а уж тем более вряд ли будет хранить триллион изображений.
Теперь отойдём от математики к практике программирования бэкэндов. Использование случайных хэшей в качестве параметров ссылки для передачи данных пользователей, в том числе чувствительных, является нормальной практикой, но далеко не лучшей. Если используются достоверные SSL-сертификаты и передача данных идёт по HTTPS, то всё, что смогут узнать посредники в лучшем случае, это домен, а параметры и вызванные методы передаются в зашифрованном виде.
В конце добавлю, что гораздо лучше было бы, если бы для получения изображения по ссылке проверялось наличие доступа у пользователя к данному изображению через токен авторизации, это не сложно в реализации, но может создать дополнительные издержки для инфраструктуры, так как тогда нужно заводить отдельную таблицу в БД или отдельную БД, которая будет хранить данные о том, кто к каким ссылкам имеет доступ, а также выполнять дополнительные обращения к данной БД. В случае Max, скорее всего, используется хранилище типа Amazon S3, к которому идёт прямой запрос, на который сразу возвращается ответ без дополнительных проверок.
UPD: По мнению пользователей Хабра, префиксная часть как-то связана с датой и, возможно, меняется. Постфиксная часть у некоторых других пользователей разная. Так что сложность подбора увеличивается экспоненциально.
UPD2: Аналогичным образом, то есть без авторизации, хранятся фотографии в Одноклассниках и ВКонтакте.