passwords (a bit of a rant)
- From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
- To: oracle-l-freelists <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 13 Aug 2013 17:09:07 -0300
Hi,
passwords are stupid. And software that requires sys password to install
doubly so.
what I cannot fathom is why there is a limit in the size of a password in
oracle users... this seems like a strange security flaw. If I want to use a
300 character passphrase, why shouldn't I be able to do so? (maybe not 300
characters, but it would be far easier for me to remember groups of
completely unrelated words that the crappy 7331 passwords that IT Sec seems
to think are safer, and having upper and lowercase as well as spaces,
commas and dots and numbers (and the eventual apostrophe) would generate a
high enough cardinality so that a 60 char password is far harder to crack
(brute force would simply take too long and dictionaries would be
impractical given the the size of the password, it would essentially turn
into a brute force attack)
I will talk about productive environments only, since in non-productive
environments we *should* have scrubbed data so security is not that much of
an issue (I still think we should secure our QA environment the same way we
do production, though)
With task separation, passwords have become increasingly useless as a
security feature. I often find TOAD or SQL Developer from windows machines
on the OOB vlan connected to the database with the schema owner of an
application. This is bad, because not everybody bothers checking their
queries before executing them and this can lead to horrible, horrible
things running in the database (like a Cartesian join of two
multi-million-row tables). This happens when an app uses clear-text
passwords and clever developers have access to the server to read the logs
and review configuration and they have read access to the app server
password field or even worse, when the developer doubles as app admin and
the app requires the password to be entered at start time.
Furthermore, changing application passwords is usually very hard (and
more often than not it involves downtime of some sort), so if a developer
changes teams (or leaves the company) we have the production data exposed,
essentially reducing the VPN to our ONLY line of defense, which isn't very
good since should this person gain physical access to the building (even
the lobby) they could simply crack the wifi password and reach the servers
(why the wifi vlan even has access to the server network is beyond me)
Now we have an even worse scenario where there are two providers working
on the same environment (one operates the environment and the other one is
working on an upgrade) which means they have to send each other the
password via e-mail whenever the change one.
I seem to remember Oracle supports other types of authentication (other
than passwords) but they don't seem to cut it.
I know there's a couple of security experts on here, so my questions are:
What are your opinions on oracle authentication and where it lacks?
How do you handle password management, and application, developer and end
user access to databases?
I haven't looked through all the 12c new features, is there anything new
on this area?
as usual, if you can point me to any documentation, blog, dissertation on
this subject I'd be very grateful.
Cheers
Alan.-
--
//www.freelists.org/webpage/oracle-l
Other related posts:
