Prevent re-use of previously selected passwords

[Friend33]

Hi Friends,

Have 2 queries and hence was wondering if you could answer them.

1 A form must be designed to prevent users from reusing
passwords that have been used in the last 12 months.

2 Also, since the password is stored in a Oracle table
as plain text, how can we encrypt it ?

Thank You,

Friend

 

[sem]

Where did you find Oracle password as a plain text???

Regards, Dima

http://seminihin.narod.ru

 

[Friend33]

Hi Dima,

Is the password encrypted while it is stored in a table ?
Pl. confirm.

Thanks,

Friend

 

[Thargy]

Friend33,

You are getting into deep waters here. Security is one of those hoary subjects that start RDBMS and system design 'wars'.

On the basis that I can already feel the incoming bombshells, here goes.

First of all, the questions seem slightly contradictory. In item 1 you state that the form must be designed to prevent password re-use, but in 2, go on to say that they are stored in the database. Is the form responsible for password management, or the database? If (as seems highly unlikely) it's the form, then it's up to the experts in whatever front end technology you're using to design a secure form. This is nothing to do with the database, ergo nothing to do with Oracle, so I'll say no more.

If, as I suspect, you are using a form to allow users to enter their username/password combination, and the form is connecting to Oracle to check up on the validity of the password, then the form just needs to forward the password to the database for validation. This implies that you have database managed security, and not form managed security. If your security is database managed, then several different things apply.

First of all, storing passwords in plain text is barking mad. Oracle automagically obfuscates password info, specifically to prevent the happy hacker from gaining simple plain-text access to the crown jewels. By having a system which does this, your database security has already been severely degraded, and I strongly recommend that you do something different. Since, by your own statements, you are in the process of designing this thing, now is a golden opportunity to do so.

The art of password hashing (which is one possible solution) is covered by others far more knowledgable than I at

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:95412348059.

A second possible solution is to use password checking routines. By the use of profiles it is possible to enforce password quality and expire passwords etc. This is a subject in its own right, so I can't cover it here, but you should look at the documentation.

W.R.T. actually checking passwords and the use of the PASSWORD_VERIFY_FUNCTION, there are elegant solutions and advice available from

http://asktom.oracle.com/pls/ask/f?p=4950:61:15468414540126688::::P61_ID:258715248980.

All this referring to other sources may seem like a cop out, but believe me, database security is a vast subject area, and you just have to do some homework, before implementing the solution. I've spent ages reading documentation, so I know how it can seem like drudgery, but it does sort the men from the boys.

Please let me know how you get on, particularly with the elimination of plain-text passwords.

Regards

Tharg



Grinding away at things Oracular

 

[Friend33]

Hi Tharg,

Thanks for your prompt reply.

When you mention 'Oracle automagically obfuscates password info', can you tell me asto how Oracle recognizes that the
text is a password column ?

Also, can you tell me the steps to store the password in a table and keep it encrypted ?

Thank You,

Friend33

 

[Thargy]

Friend,

I suspect that I have time zones working in my favour here, but I was pleased to respond rapidly.

Oracle stores the hash value of passwords, so that it never stores the password itself, thereby improving security. This assumes that you use Oracle's built in security. Hash values are generated using the dbms_obfuscation package.

Native Oracle security has no 'knowledge' of your table, and is therefore 'unaware' of the nature of a column, password containing or otherwise.

By having your own password table, it is implicit that you are implementing DIY security. This is discussed in the Ask Tom pages which I have posted earlier. DIY security naturally offers greater flexibility of password control, but is more work. I have implemented DIY security and I don't store my passwords encrypted, I store the hash value of the user name and password. To generate the hash value I invoke dbms_obfuscation_toolkit.md5. I am using 9i2, but I believe 10g has some other algorithms (such as SHA-1) in its excellent dbms_crypto package. I recommend you peruse the overview documentation for this package to see if it does what you want.

The problem with encryption is that if someone finds the key, they gain access to every password. With hashing, they have to brute-force attack the hash space every time, which is computationally infeasible.

So, to store values in a table safely, hash the user name and password, and store the resulting hashed value. When you want to authenticate/validate the username/password combination when users attempt to log on, hash the two values and see if the result is identical to your stored hash value. If it is, the user is authenticated and should be granted access to the database. If not, return a single-finger salute.

I hope this helps, and that I haven't gone into too much techno-babble.

Regards

Tharg

Grinding away at things Oracular