我现在有一个（客户端/服务器通信）设置，如下所示：
1) 客户向用户询问用户名并通过
2）客户端使用端口 80（通过网络）将其发送到服务器
3）服务器回应说这是否是正确的密码（正确密码/错误密码），如果正确，它将向客户端发送一个加密密钥。
4）客户端向服务器发送一系列命令（所有命令都以服务器给客户端的加密密钥开头）。
5）服务器检查加密密钥以识别客户端并响应命令
我的问题是：
这是保证事情安全的正确方法吗？我不确定来回发送单个加密密钥是否会有任何好处。让客户端生成加密密钥并让服务器验证它会更有帮助吗？
我想做的事情就像 facebook 所做的那样来验证它的应用程序。例如，我可以想象 facebook 做了一些事情来阻止我通过像 wireshark 或 tcp 分析器这样的程序窃取原始密码。
如果这很重要，我的程序是用 c# 编写的，并使用标准 http 来发送/接收数据。
谢谢，
罗希特
为了使您所做的大部分事情保持不变，您只需将步骤更改为
客户向用户询问用户名并通过
客户端与服务器建立 SSL 连接。
客户端通过 SSL 连接发送用户名和密码。
服务器响应说这是否是正确的密码（正确密码/错误密码）。
客户端向服务器发送一系列命令（所有命令都通过用于发送密码的同一 SSL 连接发送）。
服务器不需要在每条消息中不断地重新验证用户的身份，只要您使用一个连续连接，SSL 层就会在幕后为您完成所有这些工作。
另一方面，Facebook 与您所描述的完全不同，他们使用OAuth。这是 OAuth 工作原理的基本示例（来自 yahoo 的开发人员页面）
因此，您在编写时为每个应用程序执行第 1 步，每个用户完成第 2-4 步以将应用程序与其帐户相关联，然后您只需执行第 5 步，直到第 4 步中收到的令牌过期（可能在任何地方从几小时到几天，取决于站点）。令牌过期后，您只需重复第 4 步（如果失败，请执行第 2-4 步），用户就可以再次使用该程序。
第 3 步是他们输入密码信息的地方，但请注意，他们是在 Yahoo 的网站上输入密码，因此您的程序永远不会触及用户的用户名和密码（这是 OAuth 的全部要点！）。
几个通用的指针：
正如其他人指出的那样，尽可能使用 SSL。
您永远不应该以明文形式存储密码。相反，存储原始密码的哈希并在比较之前重新哈希任何收到的密码。如果您不能使用 SSL，请让客户端在传输之前对密码进行哈希处理（使用 MD5 或类似方法）。
如果客户端是应用程序（不是浏览器中的页面）但您不能使用 SSL，那么客户端和服务器可以共享一个可用于加密传输的密钥。秘密当然不应该被发送，而是在例如 AES 加密中用作密钥。
在您的场景中，您可以使用例如由共享密钥、客户端 IP 地址和当前命令（或其子集）组成的字符串的散列，并将散列与命令一起传输，以便不断验证自己服务器。
但是，如果可能，请使用 SSL。