https网址中的用户名和密码 [英] Username and password in https url

问题描述

考虑网址：
https：// foo：[e-mail]

以上示例中的用户名/密码部分是否符合URL参数，如这个问题？

Does the username/password portion in the above example qualify as a "URL parameter", as defined in this question?

推荐答案

当您将用户名和密码放在主机前面时，此数据不会以相同方式发送到服务器。而是根据使用的身份验证模式将其转换为请求标头。大多数情况下，这将是基本身份验证，我将在下面介绍。 Digest Auth 现在提供了类似的（但使用频率较低）认证方案，现在提供了类似的安全功能。

When you put the username and password in front of the host, this data is not sent that way to the server. It is instead transformed to a request header depending on the authentication schema used. Most of the time this is going to be Basic Auth which I describe below. A similar (but significantly less often used) authentication scheme is Digest Auth which nowadays provides comparable security features.

使用Basic Auth，来自问题的HTTP请求将如下所示：

With Basic Auth, the HTTP request from the question will look something like this:

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

你看到的字符串之类的字符串是由浏览器创建的，如下所示： base64_encode（用户名+：+密码）。

The hash like string you see there is created by the browser like this: base64_encode(username + ":" + password).

对于HTTPS传输的外部人员，此信息是隐藏的（与HTTP级别的其他内容一样）。您应该注意登录客户端和所有中间服务器。用户名通常显示在服务器日志中，但密码不会。但这并不能保证。当您在客户端上使用例如URL调用该URL时 curl ，用户名和密码将在进程列表中清晰可见，并且可能会出现在bash历史文件中。

To outsiders of the HTTPS transfer, this information is hidden (as everything else on the HTTP level). You should take care of logging on the client and all intermediate servers though. The username will normally be shown in server logs, but the password won't. This is not guaranteed though. When you call that URL on the client with e.g. curl, the username and password will be clearly visible on the process list and might turn up in the bash history file.

当您使用 ayush方法时，用户名和密码始终将在服务器日志中显示您的网络服务器，应用程序服务器，缓存，...除非您专门配置您的服务器不记录它。这仅适用于能够读取未加密的http数据的服务器，例如您的应用程序服务器。

When you use the approach by ayush, the username and password will always turn up in server logs of your webserver, application server, caches, ... unless you specifically configure your servers to not log it. This only applies to servers being able to read the unencrypted http data, like your application server though.

基本身份验证由浏览器标准化并通过显示此小用户名/密码实现弹出。当您将用户名/密码输入通过GET或POST发送的HTML表单时，您必须自己实现所有登录/注销逻辑（这可能是一个优势）。但是你应该从不通过GET参数传输用户名和密码。如果必须，请改用POST。默认情况下会阻止记录此数据。

Basic auth is standardized and implemented by browsers by showing this little username/password popup. When you put the username/passwort into an HTML form sent via GET or POST, you have to implement all the login/logout logic yourself (which might be an advantage). But you should never transfer usernames and passwords by GET parameters. If you have to, use POST instead. The prevents the logging of this data by default.

使用用户/密码输入表单和后续基于cookie的会话实现身份验证机制时，因为它现在通常使用，你必须确保密码是通过POST请求或上面的标准化身份验证方案之一传输的。

When implementing an authentication mechanism with a user/password entry form and a subsequent cookie-based session as it is commonly used today, you have to make sure that the password is either transported with POST requests or one of the standardized authentication schemes above only.

总结我可以说，那样传输数据通过HTTPS是安全的，只要您注意密码不会在意外的地方出现。但该建议适用于任何密码的任何转移。

Concluding I could say, that transfering data that way over HTTPS is safe, as long as you take care that the password does not turn up in unexpected places. But that advice applies to every transfer of any password in any way.

这篇关于https网址中的用户名和密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！