Re: Interesting Hack
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: "jack.applewhite@xxxxxxxxxxxxx" <jack.applewhite@xxxxxxxxxxxxx>
- Date: Sun, 27 Jul 2014 16:01:39 -0400
I enthusiastically second the idea of a password manager and random generated
passwords. I use lastpass for personal & family stuff an I'm a huge proponent.
However I think keypass might be a little more appropriate for small business
environments, with a carefully thought out (and properly approved) plan for
where you store the password file and how you share things. Or if you want
something more like cloud, I worked with one medium sized company that
standardized on thycotic (on prem version I think) and I was impressed.
Lastpass is marketing to businesses but do a quick google search for enterprise
cloud password vaults to check for alternatives too.
--
http://about.me/jeremy_schneider
Sent from my iPhone
> On Jul 17, 2014, at 1:15 PM, Jack Applewhite <jack.applewhite@xxxxxxxxxxxxx>
> wrote:
>
> 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@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf
> of MacGregor, Ian A. <ian@xxxxxxxxxxxxxxxxx>
> Sent: Thursday, July 17, 2014 11:00 AM
> To: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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.
> !¶Úÿ 0~·ž–+-²Šàÿ›¥¨ þŠÚrW¥
--
//www.freelists.org/webpage/oracle-l
Other related posts:
