V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
int64ago
V2EX  ›  程序员

登录的时候为什么基本都需要用户名?

  •  
  •   int64ago ·
    int64ago · 2015-08-14 00:33:02 +08:00 · 11871 次点击
    这是一个创建于 3183 天前的主题,其中的信息可能已经有所发展或是发生改变。

    直接一个密码不就可以了
    如果可以做到每个人的密码是唯一的,登录的时候输入用户名就是多余的操作了
    当然,我只是说登录的时候可以不输入,并没有说用户名本身没必要

    所以,我看来唯一的难点就是密码唯一,其实做到这点也不会很难

    我也考虑过撞库的情景,其实考虑下也不成立,撞(密码)库和撞(用户名+密码)库难度差异真的很大吗?

    好吧,换一个情景,就是登录的时候只有一个框框,用户名和密码一起输入,把这里的(用户名和密码)当作(密码)不可以吗?--->仅仅是举个例子

    你们怎么看这个问题的呢?

    第 1 条附言  ·  2015-08-14 01:18:03 +08:00
    我脑中的场景是类似:
    注册的时候系统返回随机不重复的密码
    网站都只有一个密码框
    各个网站的密码保存在 LastPass 之类
    (登录成功后,可以得到完整的用户信息,不存在无法辨认或者 at 的情况)

    我只是提一种想法,顺便看看大家的想法
    136 条回复    2016-02-08 17:38:40 +08:00
    1  2  
    SeanChense
        101
    SeanChense  
       2015-08-14 13:33:10 +08:00
    请告诉我每次发帖必上热门的窍门。
    ooh
        102
    ooh  
       2015-08-14 13:36:18 +08:00
    虹膜就不需要
    xifangczy
        103
    xifangczy  
       2015-08-14 14:12:07 +08:00
    用户名是确认你身份 密码确认身份正确。不能少,只有变相的,比如openID...
    julyclyde
        104
    julyclyde  
       2015-08-14 14:13:42 +08:00
    如果是撞组合,那肯定是故意破解
    如果只撞一个单因素(只有密码无用户名)那有可能是碰巧
    minotaur
        105
    minotaur  
       2015-08-14 15:26:28 +08:00
    lz赶紧去做产品经理吧,拯救中国互联网就靠你了
    wangyoang
        106
    wangyoang  
       2015-08-14 15:37:05 +08:00
    哈哈,这个问题前几天脑洞开刚想过,结果被好基友好一顿训。
    julio867
        107
    julio867  
       2015-08-14 15:42:49 +08:00
    这个问题应该不止楼主一个人这么想,全世界应该有大量的产品经理想过这个问题;但是为什么没有用,自然有其道理;既然楼主想到了,可以自己尝试去做一个这样的系统出来,让大家用用到底好不好,而不是在这里这么去讨论,即使有100W个回复,这个讨论最终也没有意义;但是不能扼杀楼主的想象力····
    18000rpm
        108
    18000rpm  
       2015-08-14 15:43:38 +08:00
    @wclebb +1
    一个输入框完全能传递两个输入框的信息量。用户名密码分开只是把一个长字符串分成了两个短字符串,对破解难度也没有任何影响。
    前排好多人差点把我绕进去。。
    ipv6nxtgnwrt
        109
    ipv6nxtgnwrt  
       2015-08-14 15:44:12 +08:00
    验证一个用户是否确实是他所声称的身份,如果没有任何声称的身份,如何验证是否是他自己?
    18000rpm
        110
    18000rpm  
       2015-08-14 15:54:58 +08:00
    @ipv6nxtgnwrt

    比如 V2EX 登陆页面改成一个输入框,用户名密码用逗号分割。
    输入:Livid,Password

    然后后台分割有难度?
    yushaw
        111
    yushaw  
       2015-08-14 16:05:47 +08:00
    之前想过了... 这事 过几年了等线上线下身份统一之后靠谱

    比如说物联网普及,生物识别
    aosp
        112
    aosp  
       2015-08-14 16:08:15 +08:00   ❤️ 1
    @18000rpm

    现在向后台传的都是密码的md5,你那是要把带逗号的明文传给后台?
    yushaw
        113
    yushaw  
       2015-08-14 16:08:41 +08:00
    不过其实也是分好几个字段拼在一起,比如A区域特征+B区域特征+C区域特征,然后混在一起。

    但是现阶段在用户体验上来说,字段间分开肯定是最好的
    fo2w
        114
    fo2w  
       2015-08-14 16:12:42 +08:00
    任何事情都有一个看似简单的错误解
    18000rpm
        115
    18000rpm  
       2015-08-14 16:15:38 +08:00
    @aosp
    那在前端分割出密码,md5 后传到服务器。这和两个输入框有什么区别。。
    而且刚试了 V2EX 登陆现在就是明文啊。
    bdbai
        116
    bdbai  
       2015-08-14 19:49:26 +08:00 via iPhone
    @aosp https
    lavadore
        117
    lavadore  
       2015-08-14 21:59:19 +08:00
    @18000rpm 一个输入框带来什么好处?用户现在连自己输入用户名都看不到了,还要自己记得加分隔符把用户名密码分开。我能想到的唯一好处就是不用敲tab键了
    rockxie
        118
    rockxie  
       2015-08-14 22:09:54 +08:00
    现在很多虚拟币的在线钱包,都是直接输入密钥字符串就行了,当然,字串比较长,多达十几个英文单词。
    larsenlouis
        119
    larsenlouis  
       2015-08-14 22:12:14 +08:00
    我来开一下脑洞。web的登录身份验证都有一个通用的接口,像ssh密匙公密匙认证那样。就好比是cookies,网站可以读取。用户只要同意使用这个密匙就能登录了。
    JasperW
        120
    JasperW  
       2015-08-14 22:15:55 +08:00 via iPhone
    那么问题来了,我随便输入一串密码,就登陆成功了?怎么解
    stupil
        121
    stupil  
       2015-08-14 22:20:06 +08:00
    如果减少输入,为什么不一个框输入2次。

    先输入username 回车
    然后提示输入 pwd 再回车。

    输错了?

    错了就再输呗。
    typcn
        122
    typcn  
       2015-08-14 22:22:27 +08:00
    @18000rpm

    反着来啊!

    前端还是用户名和密码

    后端用 用户名|密码 进行 hash 保存
    invite
        123
    invite  
       2015-08-14 22:26:49 +08:00
    想法很好,不过使用用户名,密码,比较符合人类的习惯,因为习惯上,用户名和密码功能是不一样的,一个是身份识别,一个是身份验证。用户名表明你是谁,密码证明你是谁。
    des
        124
    des  
       2015-08-14 22:27:49 +08:00 via Android
    我只说一点,更短的东西有利于记忆。如果考虑密码包含用户身份的话。
    如果只是一个token的话,那就必须考虑碰撞,如果考虑碰撞,那么这个token必定不利于记忆。
    sunmonster
        125
    sunmonster  
       2015-08-14 22:36:11 +08:00
    如果返回一个唯一随机密码,那么就是说让用户去记住一个随机密码?或者说让每个用户都用lastpass? too yong too simple
    wd0g
        126
    wd0g  
       2015-08-15 00:53:05 +08:00
    现在用第三方登录比较安全,但是还有个缺点,万一第三方突然把你登录的接口关了,就over了~~
    记得以前有个网站,用的新浪的登录接口,直接登录
    然后新浪就关闭这个网站的接口,据说丢失了几万的用户~~~
    18000rpm
        127
    18000rpm  
       2015-08-15 01:33:54 +08:00
    @lavadore
    用户体验上的好处确实有待商榷。

    我主要是想喷前面那些说降低了破解难度的人。
    如果 LZ 的意思是登陆功能形式上只用一个输入框,完全可以在逻辑上保留现有的“用户-密码”结构。看不出安全性上有什么不妥。
    lavadore
        128
    lavadore  
       2015-08-15 01:54:58 +08:00
    @18000rpm 楼主的原意是不需要用户名,楼上喷的也是针对这种情况。你说的场景就是把两筐合一,破解难度当然没有变化,但这不是楼主所表达的情景
    18000rpm
        129
    18000rpm  
       2015-08-15 02:00:32 +08:00
    @lavadore 确实我也感觉理解的不是一个意思 233
    lincanbin
        130
    lincanbin  
       2015-08-15 08:53:36 +08:00 via Android
    OAuth啊
    palytoxin
        131
    palytoxin  
       2015-08-15 09:04:40 +08:00 via iPhone
    我有一个疑问,比如说有好几个人的生日都是00年1月1号。然后这些人设置密码都是000101。现在我输入这个登陆,你说我登谁的
    proudzhu
        132
    proudzhu  
       2015-08-15 09:12:20 +08:00 via Android
    LZ 的问题在于想得太多,但书读的太少
    zjl03505
        133
    zjl03505  
       2015-08-15 09:27:12 +08:00
    为什么这个问题在「程序员」下!
    skyshy
        134
    skyshy  
       2015-08-15 22:02:52 +08:00
    请问该如何找回密码? 当你这样一个密码而且你忘记了
    panzhc
        135
    panzhc  
       2015-08-16 00:21:51 +08:00
    内部系统可以用token,我们就是这么实现的,不过不适合需要人类记忆的场景。密码本来就是反人类的,期待生物识别技术和安全的完善,单因子验证一定会实现的。
    ysoserious
        136
    ysoserious  
       2016-02-08 17:38:40 +08:00
    @int64ago 如果密码足够长且足够复杂的话,被爆破的可能性几乎十分小,然而那种密码十分难记- -在这种情况下,用户必然用软件去记住密码,就像你说的 1password 等。也恰恰是在这种情况下,加上账户验证与否对普通用户来说是没有区别的,但是对于 hacker 来说多一道验证就多一道坎。

    另外,你要实现密码的唯一性,不可能让用户自定义密码吧,最多也是用户申请更改密码,然后密码还是由你们的算法生成的,在一定程度上有算法被破解的可能,定期更换算法的同时用户也要定期更换密码才行,与此同时,你还得保证新算法产生的密码不能与数据库中存在的撞库。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2315 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 06:53 · PVG 14:53 · LAX 23:53 · JFK 02:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.