"The password is saved to file in your directory and it is encrypted so saving it is not a bad thing"
If I can copy the whole sqldeveloper directory tree onto a USB drive (or the relevant IDEConnections.xml file), move the copy to another PC, and just click the sqldeveloper.exe to get access to the database with that username/password then it doesn't really matter whether I can decrypt the original clear-text password, I've still got access to the database account.
Also, there's SOMETHING in all that java code that can decrypt the password to send it to the database, so I suspect it isn't impossible to dig it out and reverse it back into a readable bit of source code. [Somewhere, I've still got a bit of code I wrote to break the encryption of TOAD's encrypted passwords, though they may have made that harder in newere releases.]
It really does not matter if this option is default. If user has security paranoia, he will disable this option, otherwise it will anyway enable it for convinience reasons regardless of initial state. Another reasoning is that target audience is developers, not DBAs and access rights policy to development/test environment usually more relaxed then in production one.
But having a global setting for default value of this option in Tools/Preferences/Connections may be convinient. Be "default" I mean the initial value that is shown while connection creation.
If you have a database in a bank environment, it is so secure that the physical access to the database server is controlled. The risk to have some -even encrypted- password saved locally is simply unacceptable, also because the physical access to the client harddisk is not controlled.
Well, we could teach the employees to be sure to never forget to uncheck save password... but you know, it does not sounds right.
1 - do not save passwords per default
2 - have a preference setting for saving the password per default
If someone like to have them locally, it is fun. If someone does not want to have them locally, it is a security matter.
You debate and we listen. I spoke with the developer of this and he will change the default of save password to no for new connections. He said he had been on the fence about it - now the debate will begin to put it back ...
Can you explain me what ad-hoc tool like Raptor does in bank environment? Would you allow to users uncontrolled inserts, updates, deletions and so on in bank DB?
It is much higher security risk as any stored passwords. It seems that security concept in this environment is flawed. As absolute minimum you need tha tool with centralized security configuration that user can not change by himself. Raptor just not falls in this category.
On the site, the raptor is not supposed to be used by "users" but by "dbas". Like oem9. With oem10g grid control, it is terribly messy to find out if a table is missing, to check the code of a package, to compile a procedure and find out the error, to verify a public synonym exists, ...
A kind of "read-only" (almost) utilisation.
My need is to provide an "object browser" to the DBAs.
The password and the username is known only by the dba, it is not saved on the disk.
At this time, we are actually not targeted at DBAs but Database Developers (not saying we are not very useful to DBAs). Raptor only gives you the ability to see exactly what you can via SQL*Plus.
In a bank environment, you would most likely only be given limited access to objects. In that case, the navigator would not be as much use but you could run reports and use the SQL Worksheet. If you have central schemas that own objects and you are granted access, you can create views against the central tables that you would own and then you could view the details via the Connections navigator.
There is no security risk with raptor, we grant you nothing special and don't show you anything that you could not access if you just knew the proper SQL.
There is something I particulary appreciate in raptor : the user-defined reports.
Instead of running the query in sqlplus, the dba can have a graphical interface (with colors), to see the result of a report. I already migrated our 50+ reports from sqlplus command line format to a XML userdefined report. Really great way to distribute generic reports.
We have a dozen of dbas, most are not as confident with command line as with the mouse (sic)
I want to have more features for the dba (like a DBA-Module), to create users/profiles/roles and grant privileges!
I hear you - we hear you - those capabilities are definitely on our list of things to add in a post v1 release.
For your reports, check out the new click-through capability added in the last release. Run the standard User Tables reports, pull it into a Worksheet and see the last three columns ( sdev_link_owner, sdev_link_name, sdev_link_type). If you define these in your User Defined reports (with the same aliases), you can click a row and it will popup the appropriate detail tab.