RE: Interesting Hack
Date: Thu, 17 Jul 2014 17:15:34 +0000
Message-ID: <1405617334991.81065_at_austinisd.org>
Good topic. We've started using 12c Cloud Control to manage all the DBs we've moved to our new ODAs. We're also wanting different, stronger passwords for the various groups of DBs, if not every DB.
I've been experimenting with using LastPass for this. I've been using it for over a year for my personal accounts and love it. Don't know how you feel about a cloud-based password manager, but the reviews I've seen make me very comfortable with the security of it. I now have different long and complex passwords for every single account and can easily change them regularly.
Using LastPass in Cloud Control is not quite as straightforward since everything is under the same URL. However, with the right folder naming and organization, it's not too many clicks to get the Sysman or System password for the DB of interest.
With the basic, free version, you can share entries with others who use LastPass. Also, there's an Enterprise edition that I looked at but have not yet gotten my associates to embrace.
I'm continuing my experimentation.
Jack C. Applewhite - Database Administrator Austin I.S.D. - MIS Department
512.414.9250 (wk)
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of MacGregor, Ian A. <ian_at_slac.stanford.edu> Sent: Thursday, July 17, 2014 11:00 AM
To: oracle-l_at_freelists.org
Subject: RE: Interesting Hack
I found it strange that Oracle went to the trouble of removing passwords from the dba_users table, but gives the troublesome accounts like dbsnmp access to the sys.user$ table. It's good to know they have fixed this is 12.
It has been longp assed time since passwords have needed to be longer than eight characters. Length and complexity are both important, however when passwords become very long and complicated they become extremely difficult to enter correctly or to remember. This may in users keeping their password's written on a cheat sheet. The long complicated password may have guarded against cracking, but provided no protection against surreptitious entry using the cheat sheet. That is why pass phrases may be better than over complex passwords. Phrases such as "Hear6Parrotsskwawk." are better than "X%2+<935()pw0ncD*?V" Seth, you used the term complex. That term needs to defined. Both the above passwords use lower case letters, upper case letters, digits, and special characters. Both may use any of those at a particular position in the password, however , one need not spell out or even purposely misspell out a phrase. The second style of password has this freedom. It therefore allows for more permutations than the first. However the first password is enterable by a human.
Let's say a site has 100 databases to look after, and I want to use Enterprise manager. Let's also say that passwords need to be changed every six months. Changing the dbsnmp password for 100 databases and entering those passwords into Grid Control is time consuming. However long passwords of the first style can be used. The dbsnnp password is usuallynot entered each time, so it is possible to have a 30 byte password composed of any permutation lower case letters, upper case letters, digits, and special characters allowed by Oracle. Now it isn't as safe as having 100 different passwords, but is it safe enough to be reused at all? As you add databases the prospect of different passwords everywhere becomes difficult in practice. If not at 100 databases than perhaps at 1000 or 10000. In these cases databases may be assigned to a group, and members of a group would share the password. However not every database would have a different password.
Ian MacGregor
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Seth Miller
Sent: Wednesday, July 16, 2014 3:15 PM
To: De DBA
Cc: Oracle-L Freelists
Subject: Re: Interesting Hack
Tony,
We can safely give Oracle credit on this. They've done a very good job in making sure the passwords are well encrypted while stored in the database. The table that stores this data is only visible to users that need access to it. In fact, 12c has revoked access to user$ (among other sensitive tables) from the "SELECT ANY DICTIONARY" role to which DBSNMP is still granted.
"For better security, the SELECT ANY DICTIONARY system privilege no longer permits you to query the SYS schema system tables DEFAULT_PWD$, ENC$, LINK$,USER$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, and XS$VERIFIERS." <http://docs.oracle.com/cd/E16655_01/network.121/e17607/release_changes.htm#DBSEG672>
One way hashed passwords will always be brute force crackable given a system that has already been compromised and a weak password. This is precisely why passwords should NEVER be reused anywhere, ever, under any circumstances, no matter what, given any situation, under any scenario...ever. And, they should be something <http://arstechnica.com/security/2012/08/passwords-under-assault/> that will never be in a "Rainbow Table". I could post the user$.spare4 of all of my databases and the shadow file of all of my servers on the internet and sleep well knowing they will never be cracked. If any DBA or sysadmin can't do the same, <insert offensive sarcastic statement here>.
Seth Miller
Confidentiality Notice: This email message, including all attachments, is for the sole use of the intended recipient(s) and may contain confidential student and/or employee information. Unauthorized use of disclosure is prohibited under the federal Family Educational Rights & Privacy Act (20 U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you may not use, disclose, copy or disseminate this information. Please call the sender immediately or reply by email and destroy all copies of the original message, including attachments. †Ûiÿü0ÁúÞzX¬¶Ê+ƒü n– {ú+iÉ^ Received on Thu Jul 17 2014 - 19:15:34 CEST