Безопасность данных для входа в систему с использованием хэша salt n и роли входа в postgresql

Я кодирую безопасность для веб-сайта в express.js и postgresql db. Теперь я читал о солении и хешировании, и у меня есть код, настроенный с помощью pdkdf2 с использованием модуля шифрования, но моя проблема в том, как я буду структурировать таблицу учетных записей в базе данных. Что, если бы я создал роль входа в систему, которая будет иметь для пароля зашифрованный формат MD5, и этот пароль будет производным ключом из "процедуры" хэша salt n. Будет ли это лишней защитой?

Будет таблица, которая будет иметь следующий вид: UID (идентификатор из роли входа), SALT, HASH. А также роль входа в систему.

Таким образом, при попытке аутентификации код будет пытаться войти в систему с этой ролью, сначала получая связанный UID, генерируя хешированный пароль salt n для предоставленного пароля и аутентифицируясь на уровне БД.

Надеюсь, я понимаю ...

       var usrSalt = crypto.randomBytes('128').toString('base64');
       //text , salt ,iterations , keylen , callback
       crypto.pbkdf2(usr, usrSalt, 10000, 512, function (err, derivedKey) {
           if (err) { console.log(err); }
           else {
               usr = derivedKey;
               next();
           }
       });

P.S Будет ли модуль pgcrypto снова лучше в том же сценарии, просто удалив код на node.js.


postgresql node.js hash login pgcrypto
person czioutas    schedule 13.01.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Это ответ на более высоком уровне, а не на низком уровне фактического кода.

«Избыточная защита» относится к вашему проекту. 10000 итераций займут некоторое время, и MD5 обеспечит некоторый уровень шифрования. Оба могут быть подходящими для вашего проекта и должны иметь приоритет по сравнению с другими аспектами (скорость, функции и т. Д.).

Говоря в общих чертах, некоторый уровень хороших практик безопасности защитит некоторый процент ваших пользовательских данных, а с определенным злоумышленником некоторый другой процент может «всегда» быть скомпрометирован.

Выбор для pgcrypto аналогичен. Если этого достаточно, как кода, который вы планируете написать (он, по сути, более протестирован, чем ваш текущий код), его обработка будет на вашем сервере БД. Хорошо держать его подальше от сервера Node? Легко обслуживать? Меньше работы? «Лучше» будет по отношению к вашему проекту.

person clay    schedule 13.01.2014

arrow_upward
0
arrow_downward

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

Трудно понять, что вы имеете в виду под второй частью, когда она используется для аутентификации на уровне БД. Обычно вы либо выполняете аутентификацию на уровне приложения, используя свои собственные имена пользователей и пароли, или вы создаете реальных пользователей в PostgreSQL и позволяете PostgreSQL аутентифицировать их, просто передавая их пароль и имя пользователя в PostgreSQL при создании соединения.

Есть промежуточный путь, который вы, возможно, пытаетесь найти. Аутентифицируйте пользователя самостоятельно, затем используйте SET SESSION AUTHORIZATION, чтобы сеанс базы данных PostgreSQL «стал» этим пользователем. Это немного специализированный подход, и я не использую его большую часть времени. Он в основном используется пулами соединений.

Смотрите также:

person Craig Ringer    schedule 14.01.2014
comment
во втором абзаце ур. что, если мы сделаем и то, и другое? вот что я пытаюсь объяснить в вопросе. Если мы создадим логин, содержащий пароль, который уже хеширован и обработан, а затем сохранен в логине с шифрованием MD5, тогда, когда нам нужно авторизоваться, мы берем соль из таблицы, которую мы связали с уникальным идентификатором входа. - person czioutas; 14.01.2014
comment
@drakoumelitos Отображение кода может помочь прояснить подобные вещи. Я предполагаю, что вы говорите, что CREATE USER в БД, но у вас есть собственная отдельная таблица паролей, в которой хранится имя пользователя или идентификатор пользователя. Вы аутентифицируете пользователя по своей собственной таблице пользователей, а затем SET SESSION AUTHORIZATION, чтобы стать этим пользователем в БД. Это правильное предположение о том, что вы делаете? - person Craig Ringer; 15.01.2014
comment
да, было бы неплохо, если бы я мог показать, что я имею в виду, но я действительно не могу показать вам изображение БД: P close, я СОЗДАЮ ПОЛЬЗОВАТЕЛЯ в БД и даю ему пароль, который уже хеширован и солен, и сохраняю соль в другой таблице привязка к уникальному идентификатору пользователя USER. у меня вопрос, если это перебор или все равно перебор - person czioutas; 15.01.2014