Storing passwords in an encrypted manner

[Mainak Sikdar]

Hi,I have a table in Oracle which stores the loginid and password of users.But the password can be seen in the database by a select statement.All I want is to encrypt the password and store it.I am actually developing a site for my college project.I desperately need it for my database security.I searched across the net but everyone's writing to use an encryption algorithm.I don't know which algorithm to use and how to use it.I am using JDBC to connect to my database.So if please someone helps me out with how to implement the code in Java and encrypt the password column.??

[Wendy L Gibbons]

just did a quick google found this:

using dbms_crypto package

[Martin Vashko]

There are at least two levels at which you can encrypt the password:

1) In your application. That is, you'll take care of protecting the password and you'll write the data into the database in a format which won't be obvious to someone who can see it. If you only need to authenticate your users, you should actually store only password hash (possibly salted), not he password itself. If you do need the password to use it with another service, then this is not feasible, of course, and you need to encrypt the actual password. You should try to avoid this, however, because if your data gets stolen, your users' password might become compromised and since users tend to reuse passwords (against the best advice and common sense), this could be a serious problem for you.

If this is what you want to do, it would be probably better to ask the question in our Security forum. We can move the discussion there if you wish.

2) At the database. If you don't mind being tied to Oracle, you can use various tools provided by the Oracle database. A good starting point is here. The available options include (among others): hiding contents of a column from unprivileged users (so that someone doing a select * on your table won't see the sensitive data), using existing database procedures to encrypt or hash the passwords, or encrypting the sensitive data transparently by the database.

I might be able to help a little with these topics, but my expertise here largely ends at knowing that these options exist. There are other more experienced Oracle users active in this forum, though.

[Mainak Sikdar]

Martin Vajsar wrote:There are at least two levels at which you can encrypt the password:

1) In your application. That is, you'll take care of protecting the password and you'll write the data into the database in a format which won't be obvious to someone who can see it. If you only need to authenticate your users, you should actually store only password hash (possibly salted), not he password itself. If you do need the password to use it with another service, then this is not feasible, of course, and you need to encrypt the actual password. You should try to avoid this, however, because if your data gets stolen, your users' password might become compromised and since users tend to reuse passwords (against the best advice and common sense), this could be a serious problem for you.

If this is what you want to do, it would be probably better to ask the question in our Security forum. We can move the discussion there if you wish.

2) At the database. If you don't mind being tied to Oracle, you can use various tools provided by the Oracle database. A good starting point is here. The available options include (among others): hiding contents of a column from unprivileged users (so that someone doing a select * on your table won't see the sensitive data), using existing database procedures to encrypt or hash the passwords, or encrypting the sensitive data transparently by the database.

I might be able to help a little with these topics, but my expertise here largely ends at knowing that these options exist. There are other more experienced Oracle users active in this forum, though.

It would be helpful If you elaborate the 2nd topic.Like using existing procedures to encrypt or hash the password,encrypting the sensitive data transparently by the database.