我使用以下方法为需要安全性的所有内容生成密码：
ksoviero@ksoviero-Latitude-E7440:~$ head -c 16 /dev/urandom | base64
gorv/cp+lSiwiEfKck2dVg==
256^16 种组合已经足够安全了（至少对我而言），即使是最强大的计算机也需要 2e21 年才能进行暴力破解（每秒 50 亿次尝试，这是不可能的）。
但是，注意到最后两个字符了吗？由于 base64 采用的格式以及我使用 16 个字节的事实，这些总是存在的。
是否有理由包含或不包含两个“=”符号？ 包含它们的论点是它们为密码添加了额外的符号和长度。但是，如果您假设攻击者知道我使用此方法生成密码（并且为了安全起见，您必须假设他们知道没有实际密码的所有内容），那么两个 '=' 符号是已知的，因此添加 no额外的安全性。然而，他们会受伤吗？
Base64 -encoding 按 3 组处理输入字节；每组产生 4 个字符。'=' 符号是填充的，因此字符串长度始终是 4 的倍数；由于“=”符号不是核心 Base64 字母表（字母、数字、“+”和“/”）的一部分，因此解码器知道这些符号是填充而不编码实际字节。这样，可以对n字节的输入序列（其中n不是 3 的倍数）进行明确编码和解码。
熵方面，“=”符号无害也无济于事。您可以根据需要保留或删除它们，这不会改变任何安全性。
（如果他们受伤了，那么这意味着系统中使用的密码哈希函数非常差和弱，这将是一个应该解决的问题——不是通过删除“=”符号，而是通过使用一个好的密码而是散列函数。）
给出的答案已经回答了这个问题，但是如果您想要一个长度相同的密码，而那些等号被更多随机字符（更多随机字符，而不是更多随机性）替换，您可以将读取的字节数四舍五入到最接近 3 的倍数：
head -c 18 /dev/urandom | base64
这是因为 base64 编码对 3 个字节组进行操作（正如 Tom Leek 已经指出的）。
听起来你已经知道答案了。
保留它们可以减少搜索的密码空间。仅当您可以根据密码生成将密码空间减少到可以用尽的大小时，密码之间的一致性才是有害的。在这种情况下，我不相信这是可能的。我个人喜欢在我的密码生成中包含更多符号，但是你生成的长度保持它们是无害的。