编者按:本文是一名软件开发者写的
博文,讨论了目前各大网站密码登陆系统存在的问题,并举出了几种可能的身份验证方案,欢迎读者讨论,拍砖。
你肯定有过这样的经历,不管登陆哪个网站,都需要输入各种用户名和密码。除了密码容易忘以外,现在移动设备越来越普及,在小小的屏幕上输入用户名和密码也更麻烦了。事实上,即便是那些人气超高的网站也经常会收到用户关于登陆的各种问题反馈。
怎么才能让上面的登陆过程变得尽可能简单呢?假如用户想通过多台设备访问我们的产品,那他们为什么一定要在每台设备上输入自己的用户名和密码呢?可不可以不输这些符号呢?
在回答这个问题之前,让我们先看看目前市面上的登陆体系:
可以看到,Facebook的登陆页面有6个不同的控件(点击会出现不同结果的控件,比如上面的Log In按钮)。
而Yahoo的登陆页面放了高达9个不同的控件。
因为有些用户已经有账户,而有些用户是新来的,所以网站还需要在登陆页面添加注册这一选项。对老用户来说,在最好的情况下,他们也需要输入一次用户名和密码。假如密码和账户不匹配,他们通常会在信息提交之后才会被告知,所以就需要同时重输用户名和密码。实在记不住的时候,还需要通过邮件重置密码。而对新用户来说,他们除了在注册时需填写用户名和密码以外,一般也都需要登录自己的邮箱来核实邮件地址,才能激活账户。
针对这个问题,lukew提到了一种登录的设计模式:允许用户名字段自动填充。用户可以从一系列现有的名字中选择自己的名字,而不是全部手动输入。然后,假如用户成功登录过一次,网站起码可以永远记住用户名,下次为用户自动提供。
我认为这一步的方向没错,因为这样用户就只要记住密码就行了。而且,假如用户输入的名字没有跟列表里面的名字匹配,软件还可以自动从登陆转到注册这一项。
但是,这种方案还是要求用户输入自己的密码,这些密码要么长得奇形怪状不容易记住,要么就会像之前的lukew网站披露的那样,都是一些“123456”这样无效的傻子密码,根本达不到保护账户的目的。
我自己个人更喜欢,认为更好的一个方案是,将输入密码这一步也完全剔除。目前,已经有一些系统允许用户无需输入用户名和密码就登录,其中以Oauth最受欢迎。Oauth的方法是:允许用户使用其他服务上已有的账户登录,比如 说Twitter或者Facebook。
但是,用户用上面的社交账户登录Oauth却有潜在风险:
容易泄露自己的好友列表和自己的社交网络资料。而对 Oauth自己来说,假如第三方软件的API改变,或者一个外部宕机,都可能对自己的服务产生影响。而且,尽管Oauth想要简化登陆流程,但是在某些情 况下,它的用户也有可能会被导向诸如Facebook或者Twitter这样的第三方服务,然后他们还是需要输入这些服务的用户名和密码,并被这些第三方服务要求授权给Oauth,才能最终登陆Oauth自己的服务。整个登陆过程真的被简化了吗?
而我的方案是:让用户直接通过自己的email登陆。用户在第一次使用的时候输入自己的email地址,以后需要登录的时候,他们直接通过收到的邮件里面的链接登陆账户,而根本不需要记各种各样的密码。
假如我们将这种方法跟上面lukew提到的用户名自动填充方法结合,那么老用户就只要点几下(选择用户名,点击邮件里面的链接),而无需输入就实现登陆。
而对新用户来说,整个过程也是类似的:他们只需在注册时输入自己的email地址,然后他们在核实邮件地址的同时,点击里面的链接,就可以登陆账户。
而且,这个认证系统除了应该简化用户的登陆过程以外,也应该被设计成允许登陆链接在多个设备上使用。
设想一下,假如你的新用户只要输入email地址一次,就可以在他们的手提电脑,手机,平板和其他任何设备上登陆你的软件,是不是很方便呢?
此外,这个登陆链接还应该可以扩展到移动设备的原生应用上。
也就是说,用户点击链接之后,就可以一边打开应用,一边把验证细节传过去。而对web端的应用来说,整个过程就更简单了:用户只要点击一次,就可以即登即用。
不过为了保证安全,上面的登陆链接应该有一个生命期,只能被使用一次,或者在一小段时间内有效。
这些链接可以被存储在浏览器的历史记录里面,或者存在代理或者缓存系统里面。而且,我们必须记住,上面提到的登陆方法也有一个大前提,即你的邮箱账户一直是安全的,而这也是大多数密码重设工具假定的大前提。所以出于这方面的考虑,我并不建议那些存储敏感信息应用也通过同样的方法验证用户身份。