Сохраните зашифрованный хеш имени пользователя в базе данных
Вот один из способов разбить каждый hasValid на свое промежуточное ПО. Каждое промежуточное ПО будет закорачивать выполнение, если результат действителен :
const validA = async (req, res, next) => {
if (hasValidA(req)) {
res.send('something secret')
} else {
next()
}
}
const validB = async (req, res, next) => {
if (hasValidB(req)) {
res.send('something secret')
} else {
next()
}
}
const validC = async (req, res, next) => {
if (hasValidC(req)) {
res.send('something secret')
} else {
next()
}
}
const validD = async (req, res, next) => {
if (hasValidD(req)) {
res.send('something secret')
} else {
next()
}
}
router.use(validA, validB, validC, validD)
router.get('*', (req, res) => {
res.send('something public')
})
Обновление
Для достижения некоторого подобного результата с кодом ОП, но только с одним next():
const secretSender = async (req, res, next) => {
if (hasValidA(req) && hasValidB(req) && hasValidC(req) && hasValidD(req)) {
res.send('something secret')
} else {
next()
}
}
router.use(secretSender)
router.get('*', (req, res) => {
res.send('something public')
})
5 ответов
Короткий ответ: скорее всего, нет.
Длинный ответ: Вашей ситуации, кажется, недостает, ключ "мои имена пользователей чувствительны из-за...", который поднимает вопрос: "Почему? Какова определенная, доказуемая проблема, которую защищающий имена пользователей решил бы?"
Без той проблемы, что Вы описываете, распространенная ошибка в связанной с безопасностью разработке (и действительно разработке в целом): придумывая некоторую идею защитить или запутать некоторую часть системы, и затем ища причину использовать его. Как с чем-либо в разработке программного обеспечения, необходимо постараться не делать что-либо кроме точно, что необходимо, пока ясная проблема не представляет себя, который может только быть решен при помощи определенного инструмента.
Дополнительная подсказка (бесплатно!): посолите свои хэши пароля. Простые хеши намного менее безопасны.
Если бы Вы посолили и хешировали имя пользователя, то Вы оставили бы себя с определенной проблемой курицы и яйца.
Если бы Вы посолили и хешировали имя пользователя, как Вы нашли бы его в базе данных? Необходимо было бы искать запись пользователя для нахождения соли, Вы раньше хешировали имя пользователя...
Не очень справедливо Вашим пользователям сохранить их пароль в простом тексте начиная со всех, которые имеют доступ к Вашей базе данных, видят их пароли. Необходимо использовать соленый хеш.
Наверное, нет. Думайте о нем этот путь - имя пользователя является способом приложения выяснить, в какую учетную запись пользователь пытается войти как. Пароль является способом приложения выяснить, разрешают ли пользователю на самом деле войти в систему как та учетная запись. На практике это означает, что Вы собираетесь искать строку в своей таблице учетных записей с помощью имени пользователя в качестве индекса. Путем шифрования имени пользователя Вы просто мешаете находить правильную строку.
Однако, если Вы используете ту же схему шифрования для шифрования имени пользователя и пароля, они в значительной степени одинаково безопасны - если можно повредиться один, можно повредить другой. Таким образом шифрование обоих мешает к поиску пользователь, но не добавляет дополнительной безопасности.
Примечание: В Вашем вопросе Вы говорите о дешифровании Вашего поля пароля. Вы, вероятно, хотите сделать это невозможным (буквально). Большинство людей шифрует свои пароли с помощью какой-то односторонней хэш-функции (MD5, и SHA256 популярны), наряду с солью. "Односторонняя" часть просто означает, после того как выполнение чего-то через функцию Вы не можете использовать то, что Вы вынимаете для получения то, с чего Вы запустили. Однако, если Вы запустите с того же входа, то Вы будете всегда получать тот же вывод. Соль является секретом, который только знает Ваше приложение (вид подобных ключ шифрования), который добавляется к тому, что Вы шифруете, прежде чем это будет выполнено через односторонний хэш. Это лишает возможности делать, вещам нравится соответствие два зашифрованных пароля от двух различных сайтов (предполагающий, что они используют различные соли).
Вы никогда не можете правильно оценивать безопасность системы путем рассмотрения единственной части его в изоляции. Местонахождение - Вы хранящий ключ для дешифрования паролей?
Люди, которые имеют доступ к базе данных, также имеют доступ к местоположению, Вы храните encyption ключ? Раз так Вы только получили незначительное улучшение безопасности путем шифрования паролей и вероятно ничего особенного больше для получения путем шифрования имен пользователей.
Если ключ расшифровки и программа с помощью него более безопасны, чем база данных - который довольно необычен, обычно база данных находится в самом безопасном возможном месте - затем возможно была бы дополнительная выгода для также шифрования имени пользователя, поскольку Вы будете лишать взломщиков полезной информации в атаках перебором.