Как лучше всего хранить пользовательскую информацию и пользовательский вход в систему и пароль

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

Избегайте использования быстрых и дешевых хешей, таких как MD5 или SHA1; цель состоит в том, чтобы сделать вычисление радужных таблиц для злоумышленника дорогостоящим (на основе хэш-коллизий); быстрый хэш противодействует этому. Использование дорогостоящего хеша не проблема для сценариев аутентификации, так как это не повлияет на единичный прогон хеша.

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

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

По возможности избегайте использования собственного механизма аутентификации пароля; используйте существующее решение, например bcrypt .

Отличное объяснение того, как обрабатывать пароли и что вам нужно делать,

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

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

Я бы сказал, что большую часть времени я бы сделал что-то вроде этого в одной таблице:

UserID, FirstName, LastName, Email, Password, TempPassword

Но ... если вы собираете гораздо больше, чем это. Скажем, вы собираете телефон, факс, дату рождения, биографию и т. Д. И т. Д. И если большая часть этой информации редко доступна, я бы, вероятно, поместил ее в отдельную таблицу и связал ее отношениями один-к-одному. В конце концов, чем меньше столбцов в таблице, тем быстрее будут выполняться запросы к этой таблице. И иногда имеет смысл упростить наиболее доступные таблицы. При использовании JOIN производительность падает, хотя всякий раз, когда вам действительно нужно получить доступ к этой личной информации, вы должны это учитывать.

EDIT - Знаете что, я просто кое-что придумал. Если вы создадите индекс для поля имени пользователя или адреса электронной почты (в зависимости от того, что вы предпочитаете), это почти полностью устранит недостаток производительности, связанный с созданием такого количества столбцов в пользовательской таблице. Я говорю это, потому что всякий раз, когда вы входите в систему, предложение WHERE на самом деле будет очень быстро найти имя пользователя, если у него есть индекс, и не имеет значения, есть ли у вас в этой таблице 100 столбцов. Итак, я изменил свое мнение. Я бы все это поместил в одну таблицу. ;)

В любом случае, поскольку безопасность кажется популярной темой, пароль должен быть хеш-значением. Я' d предложить SHA1 (или SHA256, если вас это действительно беспокоит). TempPassword также должен использовать хэш, и он нужен только для функции забытого пароля. Очевидно, что с помощью хеша вы не можете расшифровать и отправить пользователю его исходный пароль. Поэтому вместо этого вы генерируете временный пароль, с которым они могут войти, а затем заставляете их снова сменить пароль после входа в систему.

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

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

Всегда ли все эти данные связаны с пользователем в соотношении 1: 1? Если вы можете предвидеть, что пользователям разрешено иметь несколько адресов, номеров телефонов и т. Д., Вы можете выделить личную информацию в отдельную таблицу.

Вы должны хранить их в одной таблице и использовать одностороннее шифрование. MD5 будет работать, но он слабый, поэтому вы можете рассмотреть что-то вроде SHA1 или другого метода. Нет смысла хранить 2 элемента в отдельных таблицах.

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

Если вы должны сохранить учетные данные:

• Не храните обратимую форму; хранить хеш, используя признанный алгоритм, например SHA-256. Используйте криптографическое программное обеспечение из авторитетного надежного источника - НЕ ПЫТАЙТЕСЬ СВОИМ ОБРАТИТЬСЯ, ВЫ ВЕРОЯТНО ПОЛУЧИТЕ ЭТО НЕПРАВИЛЬНО.
• Для каждого набора учетных данных сохраните соль вместе с хешированными данными; это используется для «начального» хэша, так что два идентичных пароля не дают один и тот же хэш - поскольку это показывает, что пароли одинаковы.
• Используйте безопасный генератор случайных чисел. Слабая случайность является основной причиной сбоев безопасности, связанных с шифрованием, а не алгоритмов шифрования.

Если вы должны хранить обратимые учетные данные:

• Выберите хороший алгоритм шифрования - AES-256, 3DES (датировано) , или шифр с открытым ключом. Используйте криптографическое программное обеспечение из авторитетного надежного источника - НЕ ПЫТАЙТЕСЬ СВОИМ ОБРАТИТЬСЯ, ВЫ ВЕРОЯТНО ПОЛУЧИТЕ ЭТО НЕПРАВИЛЬНО.
• Для каждого набора учетных данных сохраните соль (в незашифрованном виде) вместе с зашифрованными данными; это используется для "начального" шифрования шифра таким образом, чтобы два идентичных пароля не давали одинаковый зашифрованный текст - поскольку это показывает, что пароли одинаковы.
• Используйте безопасный генератор случайных чисел. Слабая случайность - это основная причина сбоев безопасности, связанных с шифрованием, а не алгоритмы шифрования.
• Храните ключ (и) шифрования / дешифрования отдельно от вашей базы данных в защищенном O / S файле, доступном только для вашего рабочего профиля приложения. Таким образом, если ваша БД взломана (например, через SQL-инъекцию), ваш ключ не станет автоматически уязвимым, поскольку для этого потребуется доступ к жесткому диску в целом. Если ваша операционная система поддерживает шифрование файлов, привязанных к профилю, используйте его - это может только помочь и обычно прозрачно (например, шифрование NTFS).
• Если возможно, храните сами ключи зашифрованными с помощью основного пароля. Обычно это означает ваше приложение. этот пароль потребуется ввести при запуске - нет смысла указывать его в параметре из сценария, поскольку, если ваш жесткий диск взломан, вы должны предполагать, что можно просмотреть как файл ключа, так и сценарий.
• Если имя пользователя не требуется для нахождения записи учетной записи, зашифруйте имя пользователя и пароль.