通过默默无闻的安全意味着违反Kerckhoffs 原则，可以这样总结：假设所有的聪明都是公开的，保持随机性是私密的。

这意味着您的安全不得因公开您的协议而受到损害。另一方面，将密码保密是密码的全部意义所在。

您应该能够量化攻击者丢失了多少知识。这对于协议是不可能的，您无法衡量攻击者找出它的难度。这对于密码来说是非常可能的：它是生成它的熵。

其安全性取决于密码保密性的方案绝不是隐秘保密。密码的生成可以通过晦涩来保证安全（如果密码被选择为聪明而不是随机的），但密码的使用不是。

您的两个提案之间的选择完全取决于客户端和服务器将如何处理 URL。请注意，客户端和服务器是指 SSL 连接两侧的所有内容；如果您有一个服务器前端来解码 HTTPS 请求并将其转发到后端，那么它们都是服务器的一部分。

在密码字段之外的 URL 中包含秘密（有时甚至在密码字段中）通常是不好的，因为 URL 可能最终出现在客户端（浏览器历史记录）和服务器端的许多日志中。如果请求来自您的应用程序而不是通过浏览器，那是一方面安全的。您需要仔细查看服务器端，包括现在的方式和未来可能发展的方式。有日志吗？它们包括哪些信息？如何保护日志？他们在哪里备份？

关于 GUID 的使用：虽然某些 Windows API 提供“有点随机但实际上可预测”的 GUID，但几乎没有理由使用它们。坚持使用随机（版本 4）UUID，使用具有合适熵的良好随机数生成器。如果您没有合适的库函数，则生成 128 个随机位，如果您需要符合 RFC 的 UUID，则应用掩码uuid[6] = (uuid[6] & 0x0f) | 0x40; uuid[8] = (uuid[8] & 0x3f ) | 0x80;。

我将尝试回答这个问题本身，而不是教你使用什么和不使用什么。

考虑到您的假设（这是非常大胆的假设，IMO）

• 使用 SSL。
• 任何地方都没有记录。
• GUID 不容易预测。
• 密码很强。

那么不，这不是默默无闻的安全。这是安全的，嗯..，安全。您的安全取决于攻击者无法猜测/知道密码，而不是攻击者无法猜测/知道您的系统如何工作。在某种程度上，您的密码就是您的密钥。只要您的安全取决于您的密钥，您就可以。

现在，恐怕您正在尝试使用这些 GUID 和密码在服务器上存储目录，然后链接到这些目录中的资源。在那种情况下，绝对不是！不要这样做！密码不应该被那样对待。

让我们看看我们是否可以分解：

1. 您正在使用 SSL，这很好。SSL 会加密您发送的所有数据，包括 URL。然而，SSL 仅在数据传输时保护数据。在服务器端和客户端都意味着数据可能是可读的。
2. 如果您有一个安全令牌（用户名/密码、随机生成的密钥或其他任何东西）并且您安全地传输它（即 SSL，请参见第 1 点），那么对于试图拦截数据的人来说，加密数据的位置没有区别块它被存储。他们看不到。
3. 您需要完全了解服务器如何处理它接收到的（现已解密的）数据。正如其他答案提到的那样，典型的 http 服务器将记录它收到的 URL。这以及服务器对 URL 所做的任何其他事情都会成为潜在数据泄漏的来源。
4. 您还需要完全了解客户端（以及它使用的任何操作系统库）的工作原理，以确保它不会泄露您的安全令牌（无论您将其存储在数据中的什么位置）。客户端是否是浏览器在很大程度上与您的问题无关
5. 你不能真正信任客户。如果客户端知道安全令牌，则假设用户也知道。这通常不是常规用户名和密码的问题，但如果您使用在多个用户之间共享的一个密钥，您将无法轻松撤消访问权限。

简而言之，您需要始终知道数据在哪里（以及处于什么状态）。无论是在途中还是在休息时。如果您了解这一点，您就可以决定您要担心或可能需要进一步缓解的风险。

通过 HTTPS 在 URL 中传递安全令牌的基本前提不是通过默默无闻的安全性。但是，它仍然可能不是一个好主意，并且可能有更好的方法来做你想做的事。

根据您的一条评论，听起来您正在创建一个 URL，以便知道一个数据的 URL 不会使数据的其他部分的 URL 变得可猜测（任何较长的随机密钥都可以工作）。根据您的总体目标，这可能是合适的（我使用过执行此操作的软件），但我不会认为这与密码相同。

前一种格式<user>:<password>@<host>已弃用，并非所有主流浏览器都支持，所以不要使用它。但是，支持它的浏览器会将这样的 HTTP URI 转换为具有 HTTP Basic Authentication 的请求。

因此，您的问题应该是关于通过 HTTPS 的 HTTP 基本身份验证和 URI 参数。而后者的主要缺点是所请求的 URL 可能会在多个位置弹出，即 Web 服务器的日志文件、浏览器历史记录、HTTP 引荐来源网址等，这可能导致所用凭据的泄露。所以，再一次，不要那样做。

相反，请使用 HTTP Basic 或 Digest Authentication，或其他一些经过验证的身份验证方案。