Author |
Topic: Oracle 11g Authentication (Read 5087 times) |
|
Pete Finnigan
PeteFinnigan.com Administrator
Oracle Security is easier if you design for it
View Profile | WWW | Email
Gender: 
Posts: 309
|
 |
Oracle 11g Authentication
« on: Sep 13th, 2007, 5:28am » |
Quote | Modify
|
hello,
well I have been trying to understand oracle authentication protocol and now i'm confronted with some issues that i'm not able to resolve. Does anyone have answers to these questions.
- where does oracle get password hash and spare4 from for authentication? it can't be sys.user$(i suppose) as it allows u to modify the entries(from sys account) and they restored back to original once the user tryies to log in again.
- the new sha1 based password changes everytime the same user is created. so how is the client able to generate the correct password for decrypting the auth session key everytime the user logs in?
- is there a way to use the old 10g passwords(case insensitive) for authentication in 11g also?
please reply if u know the answers?
|
|
 IP Logged |
Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
|
|
|
Pete Finnigan
PeteFinnigan.com Administrator
Oracle Security is easier if you design for it
View Profile | WWW | Email
Gender:
Posts: 309
|
|
Re: Oracle 11g Authentication
« Reply #1 on: Sep 17th, 2007, 5:35am » |
Quote | Modify
|
I'd say sys.user$ is used for the password hashes (it would be silly to have it there if it wasn't), but there's probably a cache.
"the new sha1 based password changes everytime the same user is created. so how is the client able to generate the correct password for decrypting the auth session key everytime the user logs in? "
Based on
http://www.petefinnigan.com/weblog/archives/00001086.htm
One guess is the CTIME (user creation time) is used as a salt. That could be verified by cloning a database and then changing the password for both users and seeing if the SHA values are consistent.
Alternatively, it could be PTIME (Password change time). An ALTER SYSTEM SET FIXED_DATE... may be able to verify whether changing the password of same user at the same (Oracle clock) time (to the same password) gives a consistent SHA.
In which case, I'd further guess that the DB server sends the appropriate date/time (or hash of it) to the client. The client can then hash the user's password accordingly.
You can retain case-insensitive passwords with
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE
|
|
IP Logged |
Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
|
|
|
|
