2012-06-26 08:25 阅读 96


Basically, what I want is to use an alternative to the login cookies as they technically can be guessed (there are ways to counter this, but why not eliminate the threat completely)?

What I'm thinking of is a system with a big do not use on public computers warning that would allow users to auto-login not with a cookie, but by following an URL such as /login/email@example.com/myPassword.

What I want to ask is, should I bother creating such a system or would it make even more security flaws? On one hand, the cookie-based one can simply request the password again if, for example, the IP or user agent don't match, on the other, I can save quite a lot of DB space by not having to store cookie names.

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

2条回答 默认 最新

  • 已采纳
    duanditang2916 duanditang2916 2012-06-26 08:28

    With your approach, the user's password is now exposed: in their browser history, in your server logs, to any network sniffing tool, et cetera. Passwords of users should not be in the URL. So no, it's not a good idea.

    点赞 评论 复制链接分享
  • dongtang1909 dongtang1909 2012-06-26 08:44

    I agree with Simeon, but just want to point out a few additional things:

    • Cookies can be hijacked, you're right, but things like SSL do a good job of preventing this to the extent that its reasonable.
    • If you're using SSL, both approaches (yours and cookies) would be hidden from eavesdroppers.
    • As Simeon points out, the requested URL happens to be stored in many more places than the cookie would be, making accidental compromise or intentional compromise more likely.
    • Somewhat more importantly, however, is that cookies are just randomly generated strings, specific to your site and your site alone, while plaintext passwords are much more valuable. A plaintext password to your site might be the same password used for hundreds of other sites. In other words, a compromised cookie has a maximum impact of one site. A compromised password on the other hand could have much broader implications.
    • Because you note guessing, a PHP session ID is much longer than the typical password. PHP will typically generate session IDs between 27 and 40 characters, 4+ times the size of average passwords. Moreover, passwords are often able to be found through things like (modified) dictionary attacks in a fraction of the time that a brute force search over the entire search space would take. In other words, guessing a plaintext password is a lot easier than guessing the contents of a cookie, if you're worried about the security of cookies, increase the length and include server side logic to only accept cookies from clients in the same /24 address space. If you're still worried, force the user to re-authenticate more frequently.
    点赞 评论 复制链接分享