您将如何在Java中实现安全的静态登录凭证系统? [英] How would you implement a secure static login credentials system in Java?
问题描述
我们最近进行了一次安全审核，它暴露了此处安装的系统中的几个弱点.由此产生的任务之一是，我们需要更新我们的合作伙伴凭证系统以使其更加安全.
We recently had a security audit and it exposed several weaknesses in the systems that are in place here. One of the tasks that resulted from it is that we need to update our partner credentials system make it more secure.
旧的"处理方式是生成一个(错误的)密码，将其提供给具有ID的伙伴，然后他们将发送该ID和该密码的Base 64编码副本以及其所有XML.通过https的请求.然后，我们对其进行解码并进行验证.
The "old" way of doing things was to generate a (bad) password, give it to the partner with an ID and then they would send that ID and a Base 64 encoded copy of that password in with all of their XML requests over https. We then decode them and validate them.
这些密码不会更改(因为我们的合作伙伴将不得不更改编码/配置来更改它们，并且在多个环境中与数百个合作伙伴协调密码到期将是一场噩梦)，无需输入密码由人类或人类可读.如果我们的合作伙伴有更好但相对简单的实施方式，我愿意对此进行更改.
These passwords won't change (because then our partners would have to make coding/config changes to change them and coordinating password expirations with hundreds of partners for multiple environments would be a nightmare) and they don't have to be entered by a human or human readable. I am open to changing this if there is a better but still relatively simple implementation for our partners.
基本上可以归结为两点:我需要一个更安全的Java密码生成系统，并确保以安全的方式传输它们.
Basically it comes down to two things: I need a more secure Java password generation system and to ensure that they are transmitted in a secure way.
我发现了一些手动生成的密码生成器，但是没有什么能真正成为实现此目的的标准方法(也许是有充分的理由).与通过https进行简单的Base 64编码相比，还有一种更安全的传输方式.
I've found a few hand-rolled password generators but nothing that really stood out as a standard way to do this (maybe for good reason). There may also be a more secure way to transmit them than simple Base 64 encoding over https.
您将如何处理密码生成器，并且您认为适当的传输方法足够安全?
What would you do for the password generator and do you think that the transmission method in place is secure enough for it?
XML出现在SOAP消息中，凭证位于标头中，而不位于XML本身中.另外，由于密码是对每个合作伙伴的一次性操作，因此在设置密码时我们不必太担心生成器的效率.
The XML comes in a SOAP message and the credentials are in the header not in the XML itself. Also, since the passwords are a one-off operation for each partner when we set them up we're not too worried about efficiency of the generator.
推荐答案
密码生成
就编码用于传输的密码而言，唯一能真正增加安全性的编码是加密.使用Base-64或十六进制并不是为了安全，而是为了能够以XML之类的文本格式包含它.
Password Generation
As far as encoding a password for transmission, the only encoding that will truly add security is encryption. Using Base-64 or hexadecimal isn't for security, but just to be able to include it in a text format like XML.
熵用于衡量密码质量.因此，选择带有随机硬币翻转"的每个比特将为您提供最佳质量的密码.您希望密码与其他加密密钥一样强，所以我建议至少使用128位熵.
Entropy is used to measure password quality. So, choosing each bit with a random "coin-flip" will give you the best quality password. You'd want passwords to be as strong as other cryptographic keys, so I'd recommend a minimum of 128 bits of entropy.
有两种简单的方法，具体取决于您要将密码编码为文本的方式(从安全角度来看，这实际上并不重要).
There are two easy methods, depending on how you want to encode the password as text (which really doesn't matter from a security standpoint).
对于 Base-64 ，请使用类似以下内容:
For Base-64, use something like this:
SecureRandom rnd = new SecureRandom();
/* Byte array length is multiple of LCM(log2(64), 8) / 8 = 3. */
byte[] password = new byte[18];
rnd.nextBytes(password);
String encoded = Base64.encode(password);
以下内容不需要您提供Base-64编码器.生成的编码不是那么紧凑(从26个字符代替24个字符)，并且密码没有那么多的熵.(但是130位已经足够了，相当于人类选择的至少30个字符的密码.)
The following doesn't require you to come up with a Base-64 encoder. The resulting encoding is not as compact (26 characters instead of 24) and the password doesn't have as much entropy. (But 130 bits is already a lot, comparable to a password of at least 30 characters chosen by a human.)
SecureRandom rnd = new SecureRandom();
/* Bit length is multiple of log2(32) = 5. */
String encoded = new BigInteger(130, rnd).toString(32);
创建新的SecureRandom对象的计算量很大，因此，如果您要频繁生成密码，则可能需要创建一个实例并将其保留.
Creating new SecureRandom objects is computationally expensive, so if you are going to generate passwords frequently, you may want to create one instance and keep it around.
在XML本身中嵌入密码似乎是一个错误.
Embedding the password in the XML itself seems like a mistake.
首先，您似乎想要在处理发送者发送给您的任何文档之前对发送者进行身份验证.假设我讨厌您的胆量，并开始向您发送巨型XML文件以执行拒绝服务攻击.您是否只需要解析XML才能发现我不是合法的合作伙伴?如果servlet只是拒绝未认证用户的请求会更好吗?
First of all, it seems like you would want to authenticate a sender before processing any documents they send you. Suppose I hate your guts, and start sending you giant XML files to execute a denial of service attack. Do you want to have to parse the XML only to find out that I'm not a legitimate partner? Wouldn't it be better if the servlet just rejected requests from unauthenticated users up front?
第二，合法伙伴的密码在HTTPS传输过程中受到保护，但是现在它们很可能以明文"方式存储在您的系统中.那是不好的安全性.
Second, the passwords of your legitimate partners were protected during transmission by HTTPS, but now they are likely stored "in the clear" on your system somewhere. That's bad security.
一种更好的方法是，当合作伙伴向您发送带有HTTP请求标头中的凭据的文档时，对他们进行身份验证.如果仅允许HTTPS，则可以将密码完全从文档中取出，并将其放入 HTTP而是使用基本"身份验证标头.它在传输过程中受到SSL的保护，不会以明文形式存储在您的系统中(您仅存储用于身份验证的单向哈希).
A better approach would be to authenticate partners when they send you a document with credentials in the HTTP request headers. If you only allow HTTPS, you can take the password out of the document completely and put it into an HTTP "Basic" authentication header instead. It's secured by SSL during transmission, and not stored on your system in the clear (you only store a one-way hash for authentication purposes).
HTTP基本身份验证很简单，得到了广泛支持，与SSL客户端证书相比，您和您的合作伙伴将更容易实现.
HTTP Basic authentication is simple, widely supported, and will be much easier for you and your partners to implement than SSL client certificates.
如果文档本身的内容是敏感的，则确实应该由发送者对其进行加密，并由您以其加密形式进行存储.最好的方法是使用公钥加密，但这将是另一个问题.
If the content of the documents themselves is sensitive, they really should be encrypted by the sender, and stored by you in their encrypted form. The best way to do this is with public key cryptography, but that would be a subject for another question.
这篇关于您将如何在Java中实现安全的静态登录凭证系统?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
