Secure transfer of username and password

[Nepomuk]

Hi everybody!
For a current project, I have a Servlet and a Client and they communicate via HTTP. Now the Client has to login and therefore must send a username and a password.
I have 3 questions:

1. How much (if at all) does HTTPS encrypt data, which is sent to and from it?
2. Can HTTPS be accessed in the same way as HTTP? (With a java.net.URLConnection)
3. Which java-classes can be used to manually encrypt and decrypt the password and how are they used? (Small examples would be great!)

[Nepomuk]

A partial answer would be fine too! ^^

[Nepomuk]

Hm, as nobody seems to be answering, I'll just change the question (although feel free to answer the original questions ^^):

Does anyone have any experience using the javax.security package? Is that package a good idea or are there better solutions, when all I want to do is encrypt a password within the client and decrypt it in the server?

[JosAH]

Why don't you use a one-way encryption? Let E(x) == y be a one-way encryption
function, i.e. given the key x it is quite easy to produce an encrypted version y,
but given y it is (almost) impossible to find x again.

Your database/server stores the y values, while the client produces a value y
given a value x and sends y over the wire to the server.

The MessageDigest class can be of help here for the encryption purposes.

kind regards,

Jos

[Nepomuk]

Why don't you use a one-way encryption?

The username and password should be checked by an external application and there will be loads of users. As I have no influence on the external application, I have to decrypt the password within the Server. Or did I misunderstand your suggestion?

[JosAH]

The username and password should be checked by an external application and there will be loads of users. As I have no influence on the external application, I have to decrypt the password within the Server. Or did I misunderstand your suggestion?

Is that external application capable of adding new users? If so, you feed it with
the values E(user), E(password) and simply do the one-way encryption on the
clients. The external application couldn't care less what exactly it compares
and the user,password pairs are send encrypted over the wire. There's no
need for decryption.

kind regards,

Jos

[Nepomuk]

Is that external application capable of adding new users? If so, you feed it with the values E(user), E(password) and simply do the one-way encryption on the clients. The external application couldn't care less what exactly it compares and the user,password pairs are send encrypted over the wire. There's no need for decryption.

Hm, it's a thought, but I don't know, if it's possible. The external application already has a database and having every user twice (as it is used by several other applications) wouldn't be optimal. Also, adding every existing user with encrypted data would probably be a time consuming task, as it is a format specially designed for this particular database (as far as I know) and probably the application doesn't implement adding a series of users. I'll just have to find out about all of this.
Anyway, further suggestions are welcome! ^^

[JosAH]

Hm, it's a thought, but I don't know, if it's possible. The external application already has a database and having every user twice (as it is used by several other applications) wouldn't be optimal. Also, adding every existing user with encrypted data would probably be a time consuming task, as it is a format specially designed for this particular database (as far as I know) and probably the application doesn't implement adding a series of users. I'll just have to find out about all of this.
Anyway, further suggestions are welcome! ^^

Well, you could try to use a secure socket layer or the https protocol ...

kind regards,

Jos

[Nepomuk]

Well, you could try to use a secure socket layer or the https protocol ...

...which brings me back to the questions:

1. How much (if at all) does HTTPS encrypt data, which is sent to and from it?
2. Can HTTPS be accessed in the same way as HTTP? (With a java.net.URLConnection)

And no, I don't think, that I could use SSL, as the server runs as a servlet on tomcat and I'm not surposed to use any other Ports than the http standard 80 and possibly the tomcat standard 8080, as others are often blocked. (And, although I guess, people could change those settings, those people often don't.)

[JosAH]

...which brings me back to the questions:

1. How much (if at all) does HTTPS encrypt data, which is sent to and from it?
2. Can HTTPS be accessed in the same way as HTTP? (With a java.net.URLConnection)

And no, I don't think, that I could use SSL, as the server runs as a servlet on tomcat and I'm not surposed to use any other Ports than the http standard 80 and possibly the tomcat standard 8080, as others are often blocked. (And, although I guess, people could change those settings, those people often don't.)

Well, then you're stuck with doing the encryption yourself then. Tomcat can do
a bit of encryption for usernames and passwords (base64) but the encryption
is almost decyphered when you even look at it for a bit.

If the Servlet is yours keep track of an ever changing magic number and send it
to the client when it hits the login page (hide it in a hidden field). The server keeps
that number in its session object. The client uses that number to encrypt the
data and send it to the server; the server also knows that number (its in the
session object) and decrypts the data again.

That magic number could be any random number supplied by, say, the Random
class. If the data happens to be incorrect, the server destroys the session object.

kind regards,

Jos

[Nepomuk]

Hm, I guess so. Is org.apache.commons.codec.binary.Base64 a good choice? I will however encrypt it further, and as nobody knows, what algorithm I'm using (while anyone can use the Base64 codec), that should enhance safety quite a lot, shouldn't it?

[JosAH]

Hm, I guess so. Is org.apache.commons.codec.binary.Base64 a good choice? I will however encrypt it further, and as nobody knows, what algorithm I'm using (while anyone can use the Base64 codec), that should enhance safety quite a lot, shouldn't it?

You'd better. Base64 encrypting isn't really encrypting; it's merely encoding the
data into readable (ASCII) characters. See my previous reply for a nice encrypting
trick (if applicable to your situation).

About that Base63 stuff: there are lots of en/decoders available; everybody seems
to find it interesting to build that functionality.

kind regards,

Jos