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

Ответ 1

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

РЕДАКТИРОВАТЬ: ОП ответил, что он понимает вышеупомянутую проблему.

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

Если вы достаточно озабочены безопасностью и безопасностью, вы можете рассмотреть возможность хранения учетных данных пользователя в полностью отдельном хранилище данных из ваших данных домена. Один из общепринятых способов - хранить учетные данные на сервере каталогов LDAP. Это может также помочь в любой работе с одной подписью, которую вы сделаете позже.

Ответ 2

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

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

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

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

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

Отличное объяснение того, как обращаться с паролями, и что вам нужно для беспокойства, можно найти в http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes.

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

Ответ 3

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

Ответ 4

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

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

UserID, FirstName, LastName, Email, Password, TempPassword

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

РЕДАКТИРОВАТЬ. Знаешь, я только что подумал. Если вы создаете индекс в поле имени пользователя или электронной почты (в зависимости от того, что вы предпочитаете), он почти полностью устранит недостаток производительности, создавая так много столбцов в пользовательской таблице. Я говорю, что, поскольку всякий раз, когда вы входите в режим WHERE, на самом деле будет очень быстро найти имя пользователя, если оно имеет индекс, и не имеет значения, есть ли в этой таблице 100 столбцов. Итак, я изменил свое мнение. Я бы положил все это на один стол.;)

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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