passwords (a bit of a rant)

From: Guillermo Alan Bort <cicciuxdba_at_gmail.com>
Date: Tue, 13 Aug 2013 17:09:07 -0300
Message-ID: <CAJ2dSGTYQ9tQu66inpaF0m0VhY4Fz7JQw7c2EhmYtVDT61Ggvg_at_mail.gmail.com>



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.-

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Aug 13 2013 - 22:09:07 CEST

Original text of this message