从电子邮件即时登录.为什么这么少呢?

Ala*_*nes 39 security email hash login

尝试寻找这个,但没有发现任何事情.请求讨论或相关链接.

假设我们要发送一封电子邮件,诱使用户登录我们的超级社交网络应用程序.这封电子邮件的目的是让他们回到网站并在他们忘记我们之前逛一点,所以我们自然希望降低他们返回的障碍.Cookie有助于防止他们每次都需要登录,但在用户忘记凭据时仍无法提供帮助.我们希望在这里获得即时满足 - 直接点击动作宝贝.相反,为什么我们不能只向用户发送我们存储在数据库中的随机生成的时间敏感令牌的哈希形式?如果他们可以将此令牌提供给服务器,那么我们可以信任他们的身份.

只要您正确管理令牌,这种情况似乎可以是安全的.这个过程如下:

  1. 在向John Doe发送提醒电子邮件之前,生成一个随机数字令牌(足够大的数字以防止猜测),在几天后过期.

  2. 在电子邮件中,包含一个包含哈希形式的令牌的URL(带有用户ID的perhap xor).

  3. 当John Doe登录到他的电子邮件并单击该链接时,服务器会验证数据库中是否存在令牌并且它未过期.如果令牌存在,他将自动由服务器登录.

安全性:我们假设John Doe的电子邮件实际上属于John Doe,只是因为电子邮件地址是作为注册过程的一部分进行验证的.任何有权访问John Doe电子邮件的用户都可以访问他的帐户; 然而,这并不新鲜.许多网站已经假设用户的电子邮件帐户是安全的,因为他们实现了将密码重置为电子邮件的功能.

我的谷歌搜索只出现了一个这样做的网站,OKCupid,这是一个在线约会网站.有谁知道这样做的任何其他网站?为什么不通过电子邮件即时登录更常见?安全?增加的复杂性缺乏实质性的好处?

Sim*_*com 11

在某些网站上,您可以将"重要内容"与"非常非常重要的内容"分开.假设您网站上的"重要内容"允许用户查看策略,活动成员和传入组消息."真正非常重要的东西"允许您更改策略,重置密码和添加新用户.所以你可以做的如下:

  1. 允许您的http链接访问"重要内容".毕竟,如果人们了解您系统中的政策,用户或消息,那么这不是世界末日.
  2. 如果请求"真正非常重要的东西",请求实际的用户名/密码验证.

实质上,您在系统中构建不同的信任级别.您发送到诱惑用户的电子邮件几乎总是用于无害的活动("嘿,看看我们添加的新小部件"),如果人们希望留在网站上,那么他们就不会介意额外的认证时间.


SLa*_*aks 9

电子邮件不安全.

您不能假设电子邮件在传输过程中不会被看到,并且您也不能假设用户将通过SSL阅读电子邮件(特别是如果他使用的是Webmail客户端)

通常通过电子邮件重置密码(希望?)需要第二个因素 - 安全问题.
你不会有安全问题.

  • 通过密码重置为电子邮件,我的意思是他们通过电子邮件为您提供链接,您可以通过该电子邮件重置密码.这里没有涉及明文密码. (2认同)

Kev*_*nko 7

如果用户出于任何原因将电子邮件转发给朋友,则该朋友可以作为用户登录.


aqu*_*nas 0

如您所知,这就是密码重置的工作原理(基本上)。为什么不这样登录呢?因为您基本上是以明文形式将用户名和密码放在查询字符串上,这是一件坏事。请参阅:HTTPS 查询字符串安全吗?