m
Большая часть вскрывшихся за последние годы факапов показывает, что там либо вообще никто нихера не делал, либо человеческий фактор
можно стать звездой канала https://t.me/dataleak ..)
Size: a a a
2020 December 12
VC
Т.е. надо начать хотя бы с минимальной секурности
заменить сторонний uuid на стандартный рандом - это и есть минимальная секюрность для меня ) Если уж вообще начал думать об угрозе угадывания идентификаторв
EG
Можно генерить id картинки просто какой-то хеш, как публичный ключ, длиной 256 символов
DP
не хотелось бы завязывать картинки на пользователей. Хотелось бы чтобы всякие другие штуки хранили в себе идентификаторы картинок.
В системе может быть много разных картинок, всякие там аватары пользователей, документы и т.п.
В системе может быть много разных картинок, всякие там аватары пользователей, документы и т.п.
Имхо, вы напрасно смешиваете публичные картинки и картинки пользователей. У одних должна быть проверка прав, другим она не нужна, то есть нужно их гнать через немного разные точки входа, а то и вообще через разные механизмы и разные хранилища.
k
Имхо, вы напрасно смешиваете публичные картинки и картинки пользователей. У одних должна быть проверка прав, другим она не нужна, то есть нужно их гнать через немного разные точки входа, а то и вообще через разные механизмы и разные хранилища.
проверкой прав занимается приложение в зависимости от ресурса, в котором находятся картинки(точнее их идентификаторы). Соответственно если для ресурса нужна проверка прав - приложение это проверит, если не нужна - не проверит.
Суть именно в том, чтобы отделить файлы сами по себе от конкретных ресурсов, в которых они используются.
Т.е. в контексте загрузки файлов - картинка - это файл, у неё есть там расширение, оригинальное имя и т.п.
В контексте подачи заявления куда-нибудь, например, файл - это паспорт в виде идентификатора, ссылающегося на файл.
Суть именно в том, чтобы отделить файлы сами по себе от конкретных ресурсов, в которых они используются.
Т.е. в контексте загрузки файлов - картинка - это файл, у неё есть там расширение, оригинальное имя и т.п.
В контексте подачи заявления куда-нибудь, например, файл - это паспорт в виде идентификатора, ссылающегося на файл.
AM
Из спеки: Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.
А у random_int, значит, источник генерации числа неизвестный, да?
AM
Какие-нибудь time-based атаки возможны
Версий юидов несколько.
AM
криптостойкие рандомные инты или строки надежнее чем uuid по определению
А uuid, значит, не может быть криптостойким рандомным интом? (и это после обсуждения разных версий юида...)
AM
по идее да, но вопрос был про uuid в целом, даже без версии ) и с реализациями есть такой нюанс - добавил криптостойкую зависимость, всё хорошо, а потом начались тормоза, начали другие люди профилировать, увидели что реализация тормозит и заменили на не криптостойкую, но боле быструю. Они ведь опытные, спеки читают и знают, что uuid несекьюрный, и никто в здравом уме не будет на это завязывать безопасность ))
Такие "спецы" и вместо random_int будут своё говно добавлять. Какой смысл это вообще обсуждать?
VC
А у random_int, значит, источник генерации числа неизвестный, да?
/dev/urandom по дефолту
AM
заменить сторонний uuid на стандартный рандом - это и есть минимальная секюрность для меня ) Если уж вообще начал думать об угрозе угадывания идентификаторв
> заменить сторонний uuid на стандартный рандом
рукалицо
рукалицо
AM
/dev/urandom по дефолту
Какая неожиданность!
VC
А uuid, значит, не может быть криптостойким рандомным интом? (и это после обсуждения разных версий юида...)
может, но если контролировать реализацию, да и энтропия поменьше будет чем у чисто случайноого набра байт той же длины
AM
может, но если контролировать реализацию, да и энтропия поменьше будет чем у чисто случайноого набра байт той же длины
Каким образом контролировать, прощу прощения? А контролировать использование random_int, значит, не нужно?
VC
ну, насколько можно говорить о чистой случайности на типовом сервере )
AM
может, но если контролировать реализацию, да и энтропия поменьше будет чем у чисто случайноого набра байт той же длины
> энтропия поменьше будет чем у чисто случайноого набра байт той же длины
С какого перепуга?
С какого перепуга?
AM
Сейчас бы заливать, что у "чисто случайноого набра байт той же длины" энтропия выше при том, что uuid и является тем же "чисто случайноого набра байт той же длины" -_-
VC
> энтропия поменьше будет чем у чисто случайноого набра байт той же длины
С какого перепуга?
С какого перепуга?
в двоичном представлении uuid есть служебные биты
AM
в двоичном представлении uuid есть служебные биты
Они "необходимы" исключительно в случае их использования. Ничто не мешает тебе генерировать UUID самому из чисто случайных данных
VC
Они "необходимы" исключительно в случае их использования. Ничто не мешает тебе генерировать UUID самому из чисто случайных данных
это будет не UUID а просто рандомная строка )