PHP安全会话和Cookie [英] PHP secure session and cookies

问题描述

我不明白为什么我们要保证cookie和会话，我有一个cookie存储userid，用户名加密的密码。

I don't understand why we have to secure the cookies and session, I have a cookie that store userid, username encrypted password.

我有一个功能，如果信息与DataBase信息匹配，则随时检查Cookie，如果不匹配，则重定向到登录页面。
然而我不明白的风险，可以查看这些信息，他可以做什么与这些信息。

I have a function that checks the cookies at any moment if is the information matches with DataBase information, if not, redirect to login page. however I don't understand the risk with that can view this information and what he can do with this information.

任何人都可以向我解释什么是风险？

Can anyone explain to me what is risk ?

推荐答案

难以精确量化。首先，请记住，Cookie会在客户端和服务器之间在每个请求中传输。这可能有很多机会让别人拦截它们。

It's hard to quantify in exact terms. First, remember that cookies are transferred between the client and the server in every single request. That's potentially many opportunities for someone to intercept them. Just assume that cookies will be intercepted at some point by somebody.

在Cookie中储存使用者名称，使用者名称和（加密）密码：

Storing the username, userid and (encrypted) password in the cookie:

• 泄漏可能或可能不适用于恶意目的的信息;即：为了成功登录，您需要一个用户名和密码，并且您在空中喊叫 CAPTURE ME ，即使是明文


• 仅依赖于您的加密算法对密码的保密性;如果它变得已知，你有相当一个安全问题
  
  
  
  • ，因为加密的密码是已知的，可以加载一个离线暴力攻击以揭示加密算法和明文密码;这种攻击可能是也可能不是纯粹的理论，事实，它存在所有应该打扰你
  
  
  • 如果有可能所有以解密密码，你已经失去;密码是一个秘密只有用户应该知道，甚至你不想知道什么密码是什么;如果你知道密码，你有一个巨大的责任来保护它，当然你不想通过HTTP在整个时间内来回发送它; →请参阅密码散列
  
  
  • leaks information which may or may not be useful or usable for nefarious purposes; i.e. for a successful login you need a username and a password, and you are waving both high up in the air shouting CAPTURE ME, the username even in plaintext
  • relies solely on the secrecy of your encryption algorithm for the password; if it becomes known, you have quite a security problem
    • since the encrypted password is known, an offline brute force attack can be mounted against it to reveal the encryption algorithm and plaintext password; this attack may or may not be purely theoretical, the fact that it exists at all should bother you
    • if it is possible at all to decrypt the password, you have already lost; the password is a secret only the user alone should know, not even you want to know at any point what the password is; if you do know the password, you have a giant responsibility to safeguard it, certainly you do not want to send it back and forth over HTTP the whole time; → see password hashing

    另一方面，只使用无意义的会话ID：

    On the other hand, using only a meaningless session id:

    
    
    • 显示Cookie中没有有用的信息
    
    
    • 没有机会破解或强力任何有价值的
    
    
    • 服务器拥有终极的权力，因为会话可以被撤销
    
    
    • 使用服务器端状态的完整会话允许您提升权限;
    例如要求用户在最近的 x 分钟内使用其密码主动登录当前IP，以允许他更改其密码或电子邮件地址→即使会话cookie应被劫持也提供安全
    • 
      
    • reveals no useful information in the cookies
    • no opportunity to crack or brute force anything of value
    • server holds the ultimate power since sessions can be revoked at any time
    • it's simpler (simpler is always good in security)
    • using a full session with server-side state allows you to escalate privileges; e.g. require the user to have actively logged in with his password within the last x minutes from the current IP to allow him to change his password or email address → provides security even if the session cookie should be hijacked

    简而言之：session ID根本不存在攻击面，因为它们本来就没有意义。用户标识，名称和密码提供了一个非常多汁的目标。只是从那些基本点会话似乎更多的吸引力。假设一个完美的实现，否则完美的安全，两者都应该相当安全。但是，你不知道你有什么不安全感，你不会有完美的安全。假设这一点，知道这个，更简单的系统与更少的注意事项应该永远是首选。

    In short: session ids present no attack surface at all, since they're inherently meaningless. Userids, names and passwords present a very juicy target. Just from those basic points sessions should seem a lot more appealing. Assuming a perfect implementation with otherwise perfect security, both should be rather secure. However, you do not know what insecurities you have, you won't have perfect security. Assuming this, knowing this, the simpler system with fewer caveats should always be preferable.

    这篇关于PHP安全会话和Cookie的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！