Я хочу использовать bcrypt.compare вместе с поиском mongoose / mon go enginee

Question

Рассмотрим этот код:

const hashPassword = function(plainText) {
  return crypto
    .createHmac(process.env.Secret_hash_Password, "secret key")
    .update(plainText)
    .digest("hex");
};

Как вы могли заметить, это простая функция хеширования, использующая crypto.

Теперь рассмотрим этот фрагмент кода:

bcrypt.compare(password, user.password, (err, isMatch) => {....}

Как вы, возможно, заметили, это простая функция сравнения хэширования, использующая bcryptjs.

Как я полагаю, все согласятся, вторая наиболее безопасна .

Теперь рассмотрим проблему:

У меня есть ключ для хранения в пн go, и этот ключ является конфиденциальной информацией, поэтому я решил иметь sh это так, что никто не может расшифровать его. Этот ключ используется для выполнения поиска go, эта информация, которую имеет только пользователь, своего рода пароль.

Решение : используйте первый код, так как, тем не менее, вы не можете расшифровать, вы можете получить тот же результат хеширования, если входные данные одинаковы.

Проблема : мое решение состоит в том, чтобы использовать технику, которая, как известно, легко взломана, кому-то, кто каким-то образом имел доступ к серверу, просто нужно ввести несколько входов, и как только они получат тот же вывод, они его получат! это известный недостаток моего решения.

Желаемое решение : используйте второй код с mon go.

Обсуждение : Я мог бы просто получить всю информацию о базе данных с помощью find({}) и применить, скажем, ForEach и bcrypt.compare, тем не менее, я знаю из моих исследований, что пн go оптимизирован для поиска, например, они используют индексы. Было бы неплохо иметь возможность передать bcrypt.compare как настраиваемую функцию в mon go поисковик.

Было предложено "Увеличить количество соляных циклов bcrypt.": Я не могу использовать соль , так как это изменит ключ, и всякий раз, когда мне нужно будет сравнить, он будет меняться. bcrypt.compare существует, чтобы преодолеть это, но запросы mongo / mon goose не имеют такого внутреннего механизма.

То, что у меня в голове, в псевдокоде:

Model.findOne({bcrypt.compare (internalID, internalID')}) //return when true

Где: bcrypt.compare (internalID, internalID ') будет своего рода Функция обратного вызова, при каждом поиске mon go будет использовать эту функцию с internalID', текущим internalID для сравнения, и вернет документ, который выдает true.

Любое предложение , комментарий или что-нибудь?

PS. Я использую пн goose.

Answer 1

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

Я думаю, что использование crypto js является правильным решением. Теперь вам нужно добавить некоторую случайность в ключ / решение. По сути, у вас есть sh идентификатор с crypto js, но вместо того, чтобы предоставить ключ самостоятельно, вы можете взять секретный ключ у самого доктора, а затем sh каждый идентификатор с этим ключом. Теперь вам придется снимать sh и ha sh каждый идентификатор пациента каждый раз, когда врач меняет секретный ключ (используя какую-то очередь сообщений). Вы также можете иметь sh секретный ключ, введенный доктором перед сохранением, и вам придется открывать sh каждый раз (дважды!), Когда врач хочет найти информацию по PatientId.

В зависимости от количества пользователей, которое, как вы ожидаете, будет обслуживать ваше приложение, если число будет достаточно низким, моё решение будет работать. Но слишком много пользователей, вам придется увеличить вычислительные ресурсы и, вероятно, инвестировать в некоторые меры безопасности вместо моего решения по избыточному количеству. Почему вы все равно теряете секретный ключ от хакеров?

Удачи.