Security - количество символов для хэша логина

Question

Допустим, я хочу предоставить каждому пользователю уникальный URL для входа в систему.URL-адрес может выглядеть следующим образом: http://example.com/login/a1b2c3d5e6

Например, строка a1b2c3d5e6 использует строчные буквы английского алфавита с цифрами от 0 до 9 и содержит 10 символов, поэтому строка этой длины имеет 36 ^ 10 вариантов.

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

Answer 1

Если ваш логин URL:

http://example.com/login/a1b2c3d5e6

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

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

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

Теперь о длине токена 10 символов кажется разумным. Просто убедитесь, что он действительно случайный или криптографически сильный хеш с уникальным значением, таким как имя пользователя и какое-то секретное значение. Для этого вы можете использовать HMAC , если хотите получить готовое решение. Если вы используете HMAC-SHA1, то вы получите 20 байтов за каждый токен. Это 40 шестнадцатеричных цифр, из которых вы можете использовать только первые 10 или 20 или что угодно, или вы можете закодировать его как некоторую форму Base64 или Base32 или что-то еще.

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

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

Answer 2

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

Я бы порекомендовал сделать следующее:

1. Take the user's ID from the database (which will obviously be unique)
2. base_convert it to base 36. (See: http://php.net/manual/en/function.base-convert.php)
3. Use the resultant string as your URL

Результатом будет очень маленькая строка, которая гарантированно будет уникальной и защищенной от столкновений.

Из того, что я понимаю, службы сокращения URL, такие как TinyURL и другие, используют этот механизм для создания своих URL. На самом деле я узнал об этом на этом сайте, но больше не могу найти ссылку на этот другой поток. Большое спасибо оригинальному автору, умнее меня, который обратил на это мое внимание!

Надеюсь, это полезно.