How will you implement a secure static login credential system in Java?

We recently conducted a security audit and exposed some weaknesses in the system here One of the resulting tasks is that we need to update our partner credential system to make it more secure

The "old" processing method is to generate (bad) password and provide it to the partner with ID, and then they will send base 64 encoded copy of the ID and password and all XML requests via HTTPS Then we decode them and verify them

These passwords will not change (because at that time our partners must make coding / configuration changes to change them, and coordinating with hundreds of partners in multiple environments, password expiration will be a nightmare) and they do not have to be entered or readable by humans If our partners have better but still relatively simple implementation, I am willing to change this

Basically, it boils down to two things: I need a more secure Java password generation system and make sure they are transmitted in a secure way

I found some manual password generators, but nothing really stood out as a standard way to do this (perhaps for good reason) Transmitting them may be more secure than simple base 64 encoding over HTTPS

What will you do with the password generator? Do you think the existing transmission methods are safe enough?

Edit: the XML is contained in the SOAP message, and the credentials are in the header, not in the XML itself In addition, since the password is a one-time operation of each partner when we set the password, we don't worry about the efficiency of the generator

Solution

Password generation

In terms of coded password transmission, the only code that really increases security is encryption Base - 64 or hexadecimal is not used for security, but to include it in text formats such as XML

Entropy is used to measure the quality of passwords Therefore, selecting each bit of random "coin flip" will provide you with the best password You want your password to be as strong as other encryption keys, so I recommend using at least 128 bit entropy

There are two simple ways, depending on how you want to encode your password into text (which doesn't matter from a security point of view)

For base-64, use the following:

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);

The following does not require you to provide a base-64 encoder As a result, the encoding is not so compact (26 characters instead of 24), and the password does not have so much entropy (but there are a lot of 130 bits, which is equivalent to a password of at least 30 characters selected by humans.)

SecureRandom rnd = new SecureRandom();
/* Bit length is multiple of log2(32) = 5. */
String encoded = new BigInteger(130,rnd).toString(32);

Creating a new securerandom object is computationally expensive, so if you want to generate passwords often, you may need to create an instance and keep it

Better way

Embedding passwords in XML itself seems to be an error

First, you seem to want to verify the sender before processing any documents sent to you Suppose I hate your guts and start sending you huge XML files to perform a denial of service attack Do you just want to parse the XML to find that I am not a legitimate partner? Would it be better if the servlet had just rejected a request from an unauthenticated user?

Second, your legitimate partner's passwords are protected when transmitted over HTTPS, but now they are likely to be stored in a "clear" location on your system This is bad security

A better approach is to authenticate a partner when it sends you a document with credentials in the HTTP request header If you only allow HTTPS, you can completely remove the password from the document and put it in the HTTP "basic" authentication header It is protected by SSL during transmission and is not stored on your system in clear text (you only store one-way hash for authentication)

HTTP basic authentication is simple, widely supported, and easier for you and your partners to implement than SSL client certificates

Protect document content

If the contents of the documents themselves are sensitive, they should indeed be encrypted by the sender and stored by you in encrypted form The best way to do this is to use public key encryption, but this will be the subject of another problem