Как грамотно замаскировать поле _id при передаче на UI?

Question

[Apogeios]

Если в одной бд создать два документа с интервалом времени меньше секунды, то _id последнего это инкремент предшествующего, который отличается как видно только последним символом:

ObjectId("585f695e45a2c61b5c7ca452")
ObjectId("585f695e45a2c61b5c7ca453")

Т.е зная _id последнего мы может "почти точно" знать _id документа который был создан до него.

Допустим, организация ссылок на моем сайте, это вызов документа через явное указание _id (в строке адреса), но мне не хотелось бы что бы человек, всего лишь посмотрев на запрос, мог узнать и получить доступ к документам из этого диапазона _id (авторизация не учитывается).

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

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

Answer 1

[Евгений Вольф]

Допустим, организация ссылок на моем сайте, это вызов документа через явное указание _id (в строке адреса), но мне не хотелось бы что бы человек, всего лишь посмотрев на запрос, мог узнать и получить доступ к документам из этого диапазона _id (авторизация не учитывается).

А не лучше ли тогда, для этих целей использовать не ID, а какое-то отличное от ID значение, генерируемое иным образом, с установкой индекса на оное (для производительности аналогичной той, что будет при использовании ID).

Первое что приходит на ум это назначить свой _id рендомом.

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

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

Я бы всё-таки оставил ID в покое и не пытался бы сделать "из палки пистолет". Добавьте новое поле в качестве URL'а документа и записывайте туда хэшированный ID, не думаю, что увеличение объёма документа на 20-40 байт данных, может привести к тотальному краху системы (это как минимум, было бы странно). Ну или, если очень хочется и... и того и другого, используйте механизм "обратимого шифрования", т.е. хэширование - это по сути своей "односторонее шифрование" (если выражаться по простому), хэш нельзя превратить обратно в данные. Используйте обратимое шифрование, например такое. Идею с обратимым шифрованием можно развить и придумать какие-то дополнительные ключи или соль, если хочется прям "совсем страшно зашифроваться"...

P.S. Библиотека для шифрования в примере, - первая что попалась в поиске. Судя по тегам, Вы используете Node.JS, уверен для нее подобных библиотек и алгоритмов должно быть в избытке.

Comments

[Apogeios]

Спасибо! Похоже обратимое шифрование, это мой вариант. А коллега ответом ниже, рассказал как это сделать красиво)

Answer 2

[Алексей Ярков]

У Монго есть виртуальные поля. Заюзайте их и будет счастье ))

// ПСЕВДОКОДИЩЕ!!!
var ArticleSchema = new Schema({
  title: {
      type: String
  }
});

ArticleSchema
  .virtual('id') // вместо _id
  .get(function() {
    let hash = md5(this.title);
    return encrypt(this._id, hash);
  })
  .set(function (setFullNameTo) {
    // some setter code
  });

Comments

[Apogeios]

Спасибо, товарищ! Это то что доктор прописал)

[Алексей Ярков]

Apogeios: На здоровье, товарищ ))

[kliss]

Показать ссылку то он покажет, а как он найдет документ по этому хешу? :)

[Apogeios]

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

Answer 3

[Александр Аксентьев]

"почти точно" знать

почти точно взломать, почти точно увидеть секретные секреты.

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

Опять же что получить "почти одинаковые" записи надо добавлять прям вообще одномоментно.
Дальше чем 1 ID соседний вряд ли "переберётся" брутом.
Короче это все Неуловимый Джо.

И если нужна безопасность и защита от чужих глаз - нужно авторизацию проверять.

Comments

[Apogeios]

"Дальше чем 1 ID соседний вряд ли "переберётся" брутом"

Я Вас понял, возможно я просто загоняюсь, но эту вероятность хочется исключить

Из этого документа https://docs.mongodb.com/manual/reference/method/O... следует, что первые 4 байта это Unix Timestamp. Меняется в _id только они и ещё последние 3 байта отведенные под счетчик.

Если в друг удастся обойти авторизацию, то зная время создания документа (а это время я планировал передавать в UI для вычисления Timezone), то теоретически можно получить доступ к закрытым от чужих глаз документам.

К примеру ObjectId("585f695e45a2c61b5c7ca452"), если 585f695e перевести в десятичную, то получим
обычный Unix Timestamp 1482647902, теперь только брут с учетом счетчика, а это слишком просто за 200 проходов получим столько же слитых документов.

[Александр Аксентьев]

Apogeios:
>Если в друг удастся обойти авторизацию
то значит ваш код можно выкинуть и уже ничего не поможет...

[Apogeios]

Александр Аксентьев:
рад за вас что вы пишите безупречный код..

[Александр Аксентьев]

Apogeios: если вы не можете написать такую базовую вещь как авторизация без серьезных дыр, то наверно стоит задуматься.

А если всегда рассчитывать на гипотетическую ситуацию "а вдруг сломают/обойдут/украдут", то проще/безопаснее ничего не писать получается, а не придумывать какие-то невероятно сложные схемы(и такие же бесполезные).

[Apogeios]

Александр Аксентьев:
>авторизация без серьезных дыр
а какие ещё есть?
>какие-то невероятно сложные схемы
в том что бы скрыть id ничего плохого, сложного и тем более лишнего нет
Вы пишите своё, а я своё - на этом можно закончить.

Answer 4

[kliss]

> мог узнать и получить доступ к документам из этого диапазона _id (авторизация не учитывается)

Вот где проблема, а не в айдишниках. Security by obscurity не работает. Настрой проверку прав и хоть интегерами айдишники передавай.

Comments

[Apogeios]

как раз разбираюсь с данной частью. Security by obscurity это уже встроенный функционал какого то модуля, или общий термин, на котором строится логика аутентификации?

[kliss]

Apogeios: общий термин. Секурити, основанная на факте, что атакующий чего-то не знает - ненадежна. Потому что стоит только ему узнать это, как он получает нужные доступы.

Правильная авторизация должна работать даже при условии, что атакующему известен весь алгоритм.

[Apogeios]

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

[kliss]

Apogeios: жесткую? А как ты жесткость будешь проверять? Как удостовериться, что никто лишний не получил доступ? Надеяться, что те, кому ты послал шифрованную ссылку, не пошлют её кому-то еще?

[Apogeios]

понял.. последний комментарий был не корректный. Иногда нужно будет некоторые документы отдавать без авторизации, из за этого не хотел что бы в id было видно хоть что то

[kliss]

Apogeios: то что иногда некоторые документы надо будет отдавать публично, не значит, что авторизацию делать не надо вообще :)

[Apogeios]

может быть вы знаете интересную статейку, где аутентификация разбирается по фэншую?)

[kliss]

Apogeios: не путай аутентификацию и авторизацию. Разные вещи. :)

Не, сходу не припомню.

[Apogeios]

Хорошо, спасибо) буду дальше ковыряться)

Answer 5

[Alexander Litvinenko]

Apogeios там на самом деле основано на метке времени, но это просто чтобы админы не сказали что на вопрос не ответил.

По твоему вопросу недавно удаленному про 20к, есть идеи, но такие вещи публично не обусуждаються.
Если намерения серьезные, пиши в скайп FenixSumi, обговорим, если теоретическое размышление то сам понимаешь.