فرض کنید فردی تنها پسورد یوزر sys را از بین یوزرهای بانک در اختیار دارد و در عین حال قصد دسترسی به یوزر دیگری را دارد تا برای آن یوزر، تغییراتی را اعمال کند

به طور مثال می خواهد برای آن یوزر، job ای را که با dbms_job تعریف شده را broken کند، بدون تردید با قابلیت یوزر sys این فرد می تواند پسورد آن یوزر را به راحتی تغییر دهد اما این تغییر ممکن است سد راهی برای برنامه کاربردی خاص و یا افراد دیگری که از طریق این یوزر به بانک وصل می شوند، شود و در این صورت با تغییر پسورد این یوزر، تغییرات دیگری هم باید انجام شود که ممکن است پرهزینه باشد.

برای حل این مساله روشهایی مختلفی وجود دارد که از جمله آن، می توان به تغییر لحظه ای پسورد و بازگردانی مجدد آن از طریق فرم hash شده پسورد قبلی، اشاره کرد.

در ادامه نحوه انجام این کار، آورده شده است:

فرض کنید یوزر usef با پسورد Ab ساخته شده است:

SQL> create user usef identified by Ab;

SQL> grant connect , resource to usef;

همان طور که می دانید، پسورد همه کاربران به صورت hash شده در جدولی به اسم user$ ذخیره می شود البته در نسخه 10g در ستون password ویوی dba_users هم موجود بود که در نسخه 11g، این ستون خالی می باشد:

SQL> select password from user$ where name=’USEF’;

6F67A235CECE7A81

 

حال با فرض اینکه از یوزر usef تنها این پسورد hash شده را در اختیار داریم، می توانیم با حفظ آن، ابتدا پسورد را به صورت دلخواه تغییر دهیم و به آن یوزر وصل شویم و در نهایت از طریق فرم hash شده پسورد، تغییرات را به قبل برگردانیم:

SQL> alter user usef identified by newPASS;

SQL> conn usef/newPASS

بعد از اتصال به sys، پسورد را به همان مقدار قبلی برمی‏گردانیم:

SQL> alter user usef identified by values ‘6F67A235CECE7A81’;

با این دستور، کاربران می توانند با همان پسورد قبلی به یوزر usef وصل شوند:

SQL> conn usef/ab

Connected.

SQL> conn usef/Ab

Connected.

همانطور که می دانید، در نسخه 11g پسورد می تواند به حروف بزرگ و کوچک حساس باشد حال با توجه به اینکه پسورد قبلی در مثال ما، از حروف بزرگ و کوچک به صورت همزمان استفاده کرده است، باید مشخص شود که بانک هم به حروف کوچک و بزرگ حساس است یا خیر؟!

SQL> show parameter sensitive_logon        

NAME                        TYPE        VALUE

————————- ———– ——–

sec_case_sensitive_logon   boolean     TRUE

همان طور که می بینید، با اینکه پارامتر sec_case_sensitive_logon به true تنظیم شده است، توانستیم با پسورد ab به جای Ab به یوزر usef وصل شویم!!! برای رفع این مشکل، نیاز است تا در ابتدای کار، مقدار فیلد spare4 در جدول user$ را هم در جایی نگه داریم و برای بازیابی پسورد به مقدار قبلی، از آن هم استفاده کنیم:

SQL> select password,spare4 from user$ where name=’USEF’;

PASSWORD	SPARE4
6F67A235CECE7A81	S:4B07D79966A8B62B0ED7BC6220B8E38F44F024408313C97B2071C144821D

SQL> alter user usef identified by newPASS;

SQL> alter user usef identified by values ‘S:4B07D79966A8B62B0ED7BC6220B8E38F44F024408313C97B2071C144821D;6F67A235CECE7A81’;

SQL> conn usef/Ab

Connected.

SQL> conn usef/ab

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

توضیح اینکه با توجه به نبود این ویژگی در نسخه 10g، بعد از ارتقا نسخه اوراکل به 11g، ستون spare4 فاقد محتوی می باشد تا زمانی که این پسورد تغییر کند. این نکته را از طریق پرس و جوی زیر هم می توان دریافت:

SQL> select USERNAME, PASSWORD_VERSIONS from dba_users;

در صورتی که PASSWORD_VERSIONS تنها به 11g اشاره کند، یعنی ستون password در جدول user$ خالی می باشد و تنها spare4 مقدار دارد.

ستون password در جدول user$ برای backwards compatibility کاربرد دارد.

نکته : برای تغییر کاربر جاری یک session روشهای دیگر هم وجود دارد:

SQL> alter session set current_schema = usef;

Session altered

نکته 2: ویوی dba_users_with_defpwd اسامی تمامی کاربرانی که پسورد پیش فرض دارند را مشخص می کند.

نکته 3: برای حفظ همه پسوردها، می توانیم از اسکریپت زیر استفاده کنیم:

select ‘alter user ‘||name||’ identified by values ”’||password||”’;’ from user$ where spare4 is null and password is not null

union

select ‘alter user ‘||name||’ identified by values ”’||spare4||’;’||password||”’;’ from user$ where spare4 is not null and password is not null;