本文的內容是針對數據庫管理員的Oracle密碼破解，而寓意是讓Oracle管理員們保管好和用戶名及密碼有關的東西……破解與安全向來都是矛盾體。
對於那些對Oracle關系數據庫系統的安全問題，特別是涉及到Oracle密碼機制或算法的問題非常關注的人來說，老版本Oracle(特別是10g及其以下的版本)一直被認作是黑客們容易得手的攻擊目標。似乎你永遠不可能找到能百分之百保護你的系統免受黑客攻擊的辦法。你可以從很多方面來武裝你的系統，但是有一些事情你是永遠不可能避免的，例如總會有人有需要必須能夠接觸到並存取敏感數據，絕大多數的客戶端連接也都會涉及到通過網絡來傳輸數據。
有時候數據庫管理員也不得不動用一下“黑客”的密碼破解技巧才能解決問題。你會問，數據庫管理員本來就有數據庫內部所有的密鑰，又怎麼搖身一變成了黑客呢?因為能夠存取所有的數據並不意味著可以查看所有的數據。特別是，能夠查看密碼的哈希值(hashed value)，並不代表就能看到密碼本身。
那麼數據庫管理員為什麼會想要看到實際的密碼值呢?更確切的講，為什麼數據庫管理員想要知道某個特定的密碼明文呢?你可以想象很多情況下確實是有這個需要，常見的原因包括老應用產品的使用，高頻率的人員調動，原本的密碼管理和密碼歸檔沒有做好等等。改變SYS和SYSTEM密碼通常不是什麼大問題，但是如果是OLD_APP模式的密碼呢?
在網上搜索“Oracle密碼破解工具”，你會找到不少“好東西”，甚至還能找到自制的類似於黑客程序的軟件。本文選擇了Laszlo Toth的woraauthbf工具，該程序能很好的滿足本文的需要。你可以先用woraauthbf創建一個包括用戶名、哈希密碼值、SID和服務器名的文本文件來對付Oracle的老版本看看。提供的這幾項中只要用戶名和哈希密碼值是真的就行了。你如果深入研究過Oracle是怎麼創建哈希值的，你肯定會清楚用戶名和密碼是緊密連鎖的，而SID和服務器名和哈希值的創建沒有任何關系。其他的一些“破解”程序依賴於網絡信息，例如客戶端、服務器IP地址、端口和第三方“嗅探器”工具來窺視在客戶端和服務器之間傳送的數據。
還是快速進入實例吧。復制下面指令的輸出結果到一個txt文件，這樣就創建了上文所說的密碼文件。
- select username||':'||passWord||':'||name||':'||host_name||':'from sys.dba_users, sys.V_$DATABASE, sys.v_$instance;
再次提醒一下，上面的name和host_name隨便你怎麼取，或者用真實值也行。本例子的輸出文本文件內容如下：
SCOTT:DE59105EDBF4A687:ORCL:MYPC:
我們知道Oracle測試用戶Scott的密碼為tiger，這裡為tigers(最後輸出的結果實為TIGERS，Oracle忽略大小寫)，從5字符變為6字符。解壓縮上面下載的woraauthbf文件後，打開命令提示行(DOS)窗口，從這裡調用該工具。將密碼文件名存為“named passWord_file.txt”，命令行文本輸入如下：
woraauthbf.exe -p c:\passWord_file.txt
所有參數選用默認，執行完本次會話輸出結果如下所示：
- C:\[my path]>woraauthbf.exe -p c:\passWord_file.txtUsernames will be permuted!
- The number of processors: 2
- Number of pwds to check: 321272406
- Number of pwds to check by thread: 160636203
- Password file: c:\passWord_file.txt, charset: alpha, maximum length: 6, type: hash
- Start: 0 End: 160636203
- Start array thread with 489 number of passWords!
- Start: 160636203 End: 321272406
- Writing session files...
- Writing session files...
- PassWord found: SCOTT:TIGERS:ORCL:MYPC
- Elpased time: 164s
- Checked passWords: 153976754
- PassWord / Second: 938882
該程序計算了3億2千1百多萬需要檢查的密碼，而且使用了兩個處理器把工作量減半了，而且默認字符集為alpha(A-Z)，也需要花費了164秒才能確定Scott的密碼為TIGERS，每秒鐘檢查的密碼個數為938,882。我們在檢查了差不多一半的密碼就很幸運的中標了。
如果排除物理因素的限制(CPU數量和處理器速度等)，那麼影響運行完成時間的關鍵因素有兩個：密碼長度和字符集。如果你知道密碼長度和字符集(純字母還是字母加數字還是字母數字加特殊字符)，你就能夠大大減少需要檢查的密碼數量。一開始就縮小猜測范圍當然就能夠顯著減少運行時間。
為了做個對比，我們把字符集改為alphanum，Scott的密碼不變，需要花費6分多鐘才能找到Scott的密碼。如果在前面所用的同一個用戶密碼文件中添加另外一個用戶的密碼信息，假設也知道密碼長度同為6字符，且是字母加數字類型的，那麼整個運行時間超過了29分鐘(由於隱私的原因，下面所示的第二個用戶的名字和密碼都已經編輯過了)。
- woraauthbf.exe -p c:\passWord_file.txt -m 6 -c alphanumUsernames will be permuted!
- The number of processors: 2
- Number of pwds to check: 2238976116
- Number of pwds to check by thread: 1119488058
- Password file: c:\passWord_file.txt, charset: alphanum, maximum length: 6, type: hash
- Start: 0 End: 1119488058
- Start: 1119488058 End: 2238976116
- Start array thread with 490 number of passWords!
- Writing session files...
- Writing session files...
- Writing session files...
- Writing session files...
- Writing session files...
- Writing session files...
- PassWord found: SCOTT:TIGERS:ORCL:MYPC
- Writing session files...
- Writing session files...
- Writing session files...
- ...
- Writing session files...
- Writing session files...
- PassWord found: SOMENAMES:X1M72Y:ORCL:MYPC
- Elpased time: 2152s
- Checked passWords: 1917149967
- PassWord / Second: 890868
上述密碼文件中的第二個條目來自一個8i數據庫系統，而Scott的哈希值來自10g版本。本文的寓意非常明確：保護好任何會顯露用戶名及其哈希密碼值的東西，不要輕易讓其被他人存取，特別是SYS.USER$表(不要依賴DBA_USERS視圖)。
查找第二個用戶的密碼明文所花費的運行時間很合理。 有時候你可能要花費好幾個小時(甚至好幾天)來查找某個密碼，不過這比起和那些討厭停機的用戶一起修改已經忘掉的密碼花費的成本要低多了。
