Safe Design? Dangerous Design?

[YuenLian Wu]

Dear all,

I am currenting maintaining an existing web application, and I am suspecting if it is safe enough to prevent hacker.

My database contains a lot of user information such as user_id, user_name and user_password as well. The user_password stored in the DB was encrypted by some Java Security program(3DES). A key file(stored at the server side, let say c:/key/mykey) will be used to pass to the Program in order for Encryption and Decryption.

The client side will use the plain text password requested from browser to verify with Decrypted password in the DB by JDBC. Servlet will get the plain text and then ENcrypted it with using a keyfile. If it is matched with the Decrypted password in DB, then it's a correctd password, vice versa.

However, I think it's easy for hacker to hack it since it's a HTTP transmission. ActuallY I am not quite familar that how hacker can hack the request. If you guys know, please answer me since I am just a poor beginner.

What do you think? Any better solution? Any loophole for the current design?

Transistor
[ May 04, 2006: Message edited by: YuenLian Wu ]

[Ulf Dittmer]

Internet traffic is generally public, so someone might listen in to your connection. Because of that you should not transmit passwords in the clear - use HTTPS for encryption.

Keeping the password encrypted in the DB, but the key on the app server suggests to me that you think your DB is more likely to be hacked than the app server. In my experience it's more likely to be the other way around, but that depends on your circumstances.

[Robin Wilson]

Generally it is not necessary to 'decrypt' passwords. A better approach is to encrypt them when they are first gathered from the user, and then compare the encrypted values for all future requests.

The previous poster was correct though, you really need to use HTTPS for any password enabled systems. Otherwise, the user is being asked to transmit their password in clear-text across the Internet. You can never be sure who is examining your data packets, meaning that they are considered "not secure" for transmitting private information. (Nothing is more private than a 'password'.)

HTTPS uses a trick to get around sending unencrypted data... The browser sends a clear-text request to the HTTPS server, and gets the server's digital certificate. Included in the certificate is a public key to use to encrypt a subsequent transmission. The public key allows one side of the connection to encrypt the transmission, but only the 'private key' (held by the other side of the connection) can decrypt it. So even if someone sees the key, all they can use it for is encrypting stuff to the server, not for seeing what a given browser is sending back and forth from the server. The first encryption channel (public-key based) is used to setup a secure connection - which is used to transmit symetric encryption keys. This is probably what you are familiar with - that is, the same key is used to encrypt and decrypt the data. Each side of the connection then has a privately held "key" to encrypt all subsequent traffic over a given connection. This means that nobody else can determine what is being sent by snooping on the transmissions, since all of the data in the transmission (save for the target host's IP address and a small amount of routing information) is encrypted.

I hope this helps some...