Является ли использование пароля пользователя для шифрования его имени пользователя возможным и безопасным способом, позволяющим им войти в службу?

Question

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

Я придумал это на уроке хэширования в школе, поэтому я не удивлюсь, если есть простая причина, почему это не используется веб-сайтами, но я не нашел никаких примеров вообщеиз этого используется онлайн.Это будет использовать форму асимметричного шифрования на стороне сервера, чтобы объединить имя пользователя и пароль в один уникальный «userLoginID», который будет храниться на сервере.Код, подобный этому, будет использоваться на стороне сервера, где «шифрование» будет функцией одностороннего шифрования:

userLoginID == "331845364410495642424788" # Just an example
if (encrypt(inputtedUsername,inputtedPassword) == userLoginID)
    return True
else
    return False

Если у кого-либо есть примеры подобных процессов или объяснение, почемуэто не используется чаще, это было бы здорово.Используя этот метод, пользователь будет иметь разные «Отображаемое имя» и «Идентификатор пользователя», если это необходимо, чтобы на них ссылались другие / сервер.Лично я не вижу никаких недостатков в использовании этой системы, поэтому мне бы хотелось, чтобы кто-то, обладающий большими знаниями в области безопасности сервера, мог объяснить недостаток системы такого типа.

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

Answer 1

То, что вы делаете там, на самом деле хэширование (асимметричное шифрование - странный термин tbh) пароль, использующий имя пользователя в качестве salt , что является довольно хорошим методом предотвращения таблицыатаки на основе lookup, такие как радужные таблицы, онлайн-поиск и т. д.

Это совсем не плохой метод, если хэш-функция, которую вы используете, безопасна, как SHA-1, но сегодня она на самом деле рекомендуетсяиспользуйте функцию получения ключа, где вы выполняете одну и ту же хэш-функцию несколько раз, чтобы также предотвратить атаки методом грубой силы (или, по крайней мере, сделать их невероятно сложными), см. PBKDF2 для довольно хорошей реализации, вы можете использовать ее симя пользователя + пароль тоже самое.

Answer 2

Текущий стандартный способ обработки этого сценария очень похож, только без указания имени пользователя.При создании учетной записи пароль пользователя хэшируется с помощью алгоритма хеширования пароля (argon2, bcrypt и т. Д.).Этот хеш хранится вместе с именем пользователя.Единственная разница с вашим предложением состоит в том, что имя пользователя включено в этот хэш.

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