Создайте URL-адрес подтверждения электронной почты с помощью Guardian

Я работаю над сайтом, который реализует аутентификацию пользователей (используя Comeonin и Guardian).

Я занимаюсь проверкой электронной почты. Я подумал, что могу воспользоваться функциями Guardian для генерации URL-адреса с помощью токена JWT. Согласно этому сообщению, это похоже на правдоподобное решение (при условии, что URL-адрес использует https, а срок действия токена истекает через относительно короткий период времени).

Вот код, который я написал до сих пор:

def email_verification( user = %User{} ) do
  if ( user.email != nil ) do
    claims = Guardian.Claims.app_claims
       |> Map.put("email", user.email)
       |> Guardian.Claims.ttl({1, :hours})

    { :ok, jwt, full_claims } = Guardian.encode_and_sign(user, :email_verification, claims)

    Zoinks.Mailer.send_verification_email( user.email, jwt )
  end
end

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

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

Следуя схеме, описанной в этом сообщении SO, возможно, я мог бы генерировать случайное число, хешировать его (используя Comeonin), хранить его против пользователя и вместо этого помещать его в качестве моего утверждения? Это хорошая идея, или я совсем сбился с пути?

Предполагая, что эта часть решения работает, можно ли установить тип полезной нагрузки :email_verification?


person Mitkins    schedule 12.09.2016    source источник
comment
Что именно вы имеете в виду под However, I'm assuming that this is a bad idea - especially since the link will be exposed as clear text via email.? Если вы используете надежный секрет, не должно быть проблем с использованием вашего подхода AFAIK   -  person Jonas Dellinger    schedule 13.09.2016
comment
Честно говоря, я не уверен - я неопытен в вопросах безопасности.   -  person Mitkins    schedule 14.09.2016
comment
Я предполагаю, что если вы соберете достаточно токенов (чистый текст по электронной почте), то, возможно, удастся применить такую ​​технику, как атака по радужной таблице? Если безопасность токена в электронном письме скомпрометирована, значит, веб-сайт тоже - так как он использует ту же конфигурацию.   -  person Mitkins    schedule 14.09.2016


Ответы (1)


Отправка JWT по электронной почте совершенно нормально, если используется надежный секрет (но это всегда важно, несмотря на метод транспортировки)

Цитата из комментариев:

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

Вот почему вам следует выбрать сильный секрет. Последняя часть JWT, подпись, представляет собой комбинацию base64UrlEncode(header), base64UrlEncode(payload) и secret, помещенных в сильную функцию хеширования, такую ​​как HMAC SHA256. Для получения дополнительной информации о безопасности есть хорошее описание на jwt.io

Реализация

Вам вообще не нужно указывать реальный адрес электронной почты внутри претензий. Простого поля, такого как email=true, должно быть достаточно, поскольку ваш сериализатор уже помещает идентификатор пользователя в токен. Просто убедитесь, что пользователя можно проверить только один раз, и выберите надежный секрет!

person Jonas Dellinger    schedule 14.09.2016
comment
Если я разрешаю пользователю изменять свой адрес электронной почты в любое время (т.е. даже до того, как пользователь щелкнет ссылку активации), разве мне не нужно будет подтверждать, что веб-токен был для адреса электронной почты в базе данных? - person Mitkins; 16.09.2016
comment
Да, если вы хотите поддерживать проверку различных электронных писем для одного пользователя, то хранение электронной почты внутри токена является правильным подходом! Я думал только о первоначальной проверке единственного электронного письма. - person Jonas Dellinger; 16.09.2016