Cross-Application User Authentication

Question

We have a webapp written in .NET that uses NTLM for SSO. We are writing a new webapp in Java that will tightly integrate with the original application. Unfortunately, Java has no support for performing the server portion of NTLM authentication and the only library that I can find requires too much setup to be allowed by IT.

To work around this, I came up with a remote authentication scheme to work across applications and would like your opinions on it. It does not need to be extremely secure, but at the same time not easily be broken.

1. User is authenticated into .NET application using NTLM
2. User clicks link that leaves .NET application
3. .NET application generates random number and stores it in the user table along with the user's full username (domain\username)
4. Insecure token is formed as random number:username
5. Insecure token is run through secure cipher (likely AES-256) using pre-shared key stored within the application to produce a secure token
6. The secure token is passed as part of the query string to the Java application
7. The Java application decrypts the secure key using the same pre-shared key stored within its own code to get the insecure token
8. The random number and username are split apart
9. The username is used to retrieve the user's information from the user table and the stored random number is checked against the one pulled from the insecure token
10. • If the numbers match, the username is put into the session for the user and they are now authenticated
    • If the numbers do not match, the user is redirected to the .NET application's home page
11. The random number is removed from the database

Answer 1

1) Having a pre-shared key stored in a file (even a program file) is theater and not security.

2) Your tokens (random numbers in the database) should be set to expire. I suggest expiring after one attempt, but a time limit should be set too. Otherwise you could end up with thousands of leftover tokens that provide access with the right guess.

3) If all you need to do is verify from the Java tool that access is permitted, you can use public key cryptography and not pre-shared keys. That way you only need to protect the private key. Of course, protect includes: "don't put it in a file accessible by the user you are protecting it from," and without that protection, this approach is no different from pre shared keys.

4) It seems ot me that the java tool could be easily modified to ignore the authorization step and just perform whatever sensitive task you are trying to protect.

Take all of this with a grain of salt, as I know relatively little about Java and .NET. I do know a bit about cryptography though.