Безопасный способ разрешить пользователям входить в систему с единственным уникальным кодом (без имени пользователя)?

Question

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

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

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

• Сайт сам по себе не будет интересовать никого, кроме приглашенных, и не будет индексироваться поисковыми системами.

Если вы представите пользователи получают часть почты в пост, который говорит что-то вдоль линий:

Please visit www.example.com 
Log in with your unique code: 

      A6XH3 

Что касается кода, то он должен быть очень легко запомнить и ввести ,

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

• Альтернативная идея, которую я имел, заключалась в том, чтобы использовать два/три слова, удобные для написания, такие как [adjective] [noun], которые были бы более увлекательными и кажутся менее «техничными» для пользователей - например. симпатичный голубой цветок - который будет более соответствовать духу сайта.

Caveat

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

Есть ли альтернатива хранению кодов в виде простого текста в базе данных?

Вопросы

1. Является ли это достаточно безопасно для контекста? т.е. только те, кто знает о сайте, являются приглашенными, и нет никаких реальных мотивов для того, чтобы кто-либо попытался пробиться.

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

3. Есть ли другой способ, которым я мог бы позволить простой вход без ущерба для безопасности или простоты использования без имени пользователя?

Напоминание

Там нет процесса регистрации, и пользователи не выбирают свой собственный код. Их учетная запись создается администратором веб-сайта, и сайт случайно генерирует для них уникальный код.

Answer 1

В конечном счете, нет. Аутентификация с помощью одного фрагмента информации опасна. Я коснулся этой темы, когда я накрыл securely implementing "remember me" checkboxes. Поиск в базе данных собирает информацию о времени утечки и позволяет злоумышленникам тривиально угадать действительный код. (И реализация constant-time search algorithms - это не очень хорошая идея.)

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

В большинстве систем аутентификации, имя пользователя используется для поиска в базе данных:

$userData = $pgsql->dbQuery("SELECT * FROM accounts WHERE username = ?", array(
    $_POST['username'] 
)); 

... и пароль, в идеале, по сравнению вне запроса DB:

if(\password_verify($_POST['password'], $userData[0]['passwordhash'])) { 
    /* good password */ 
} 

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

С этими требованиями, вы должны сделать что-то вроде:

$result = $pgsql->dbQuery("SELECT * FROM accounts WHERE password = ?", array(
    hash($algo, $_POST['password']) 
)); 

... который идет полностью против лучших практик.

Мой совет: Укусить пулю и либо использовать две части информации (идентификатор и аутентификатор), либо полностью исключить аутентификацию, либо работать с OAuth, OpenID, SQRL, Mozilla Personas и т. Д. Не стесняйтесь реализовать это, если вы действительно хочу, но это не будет безопасно.

Answer 2

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

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

Answer 3

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

Не совсем так, как это позволяло бы нападающему (не обращайте внимания на понятие " нет мотивов, чтобы заставить их двигаться в) для принудительной авторизации логина - как и любая другая система входа, кроме этого в этом случае вам нужно было бы только попробовать four or five upper case alphanumeric characters, а не адрес электронной почты и пароль, который придерживается различных наборов символов ,

Конечно, вы можете сделать следующее, чтобы помочь предотвратить грубую силу;

• Добавить искаженным заполнить на каждый запрос авторизации
• Двухфакторная аутентификация с помощью SMS или E-Mail.

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

Оба метода: fine, на мой взгляд, поскольку это точно так же, как сайт не применяет «сильные» пароли. Тем не менее,, причина, по которой код должен быть в обычном тексте, ничем не отличается от хранения паролей (в обычном смысле) в виде простого текста - вы просто этого не делаете.

• Генерация случайного кода
• Отправить его пользователю (надежно)
• зашифровать код и хранить в базе данных

Есть еще один способ, которым я мог позволить простой вход без скомпрометировать безопасность или простоту использования без имени пользователя?

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

Вы также можете использовать API социальных сетей для входа в систему. Затем вы предоставляете безопасность платформе социальных сетей и пользователю (без какой-либо степени сохраняя все проблемы безопасности на вашем конце).

---

Чтобы поднять пункты в вашем вопросе, которые не были явно определен как вопрос.

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

No. I не видите причин, по которым вам нужно какое-либо взаимодействие с человеком, а также не иметь администратора сайта, чтобы видеть коды в виде простого текста - все, что могут видеть ваши администраторы, может видеть хакер.

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

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

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

Answer 4

Вы можете сделать это так же, как вы бы сделать со страницей сброса пароля:

1. Пусть пользователь с его электронной почты.
2. Отправить ссылку с токеном для пользователя, hash из токена хранится в базе данных.
3. Если пользователь нажимает на ссылку, и если токен действителен, добро пожаловать в него и дайте ему ввести свой пароль.

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

http://www.example.com/register/8eM2WwsuR59MnmyswYoQ

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