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

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

EDIT : ОП ответил, что он понимает вышеупомянутую проблему.

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

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

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

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

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

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

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

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

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

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

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

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

 UserID, FirstName, LastName, Email, Password, TempPassword 

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

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

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

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

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

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

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

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

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

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

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

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