Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Secure oracle password length

Re: Secure oracle password length

From: Paul Brewer <paul_at_paul.brewers.org.uk>
Date: Mon, 25 Feb 2002 19:04:04 -0000
Message-ID: <3c7bda72_3@mk-nntp-1.news.uk.worldonline.com>


Howard,

I think the critical phrase here is 'across the network'.

Paul

"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:a5dsbf$a9$1_at_lust.ihug.co.nz...
> Correct away, and I'm happy to learn. But I was talking about what
happens
> within the data dictionary when you create a user "identified by...", and
I
> could have sworn that no encryption took place at that point.
>
> One of the things that persuaded me of that (apart from being told it by
> someone I have a lot of respect for) was reading the following from the
> Administrator's Guide, Chapter 19:
>
> Quote ON:
> ------------
> Secure Connections with Encrypted Passwords
>
> To better protect the confidentiality of your password, Oracle can be
> configured to use encrypted passwords for client/server and server/server
> connections.
>
> By setting the following values, you can require that the password used to
> verify a connection always be encrypted:
>
> a.. Set the ORA_ENCRYPT_LOGIN environment variable to TRUE on the client
> machine.
> b.. Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to
TRUE.
> If enabled at both the client and server, passwords will not be sent
across
> the network "in the clear", but will be encrypted using a modified DES
(Data
> Encryption Standard) algorithm.
>
> Quote Off
> ----------
>
> ...all of which implies (to me at any rate) that encryption is optional,
and
> not the default mechanism. But if I've mis-understood, I'm always happy
to
> be set straight.
>
> Regards
> HJR
> --
> ----------------------------------------------
> Resources for Oracle: http://www.hjrdba.com
> ===============================
>
>
> "Rick Wessman" <Rick.Wessman_at_oracle.com> wrote in message
> news:upu2ty2m6.fsf_at_us.oracle.com...
> > I hate to correct you, Howard, but Oracle passwords *are* encrypted. The
> > algorithm is modified DES or Triple DES, depending on the version.
> >
> > Rick
> >
> > "Howard J. Rogers" <dba_at_hjrdba.com> writes:
> >
> > > "Igor Laletin" <ilaletin_at_usa.net> wrote in message
> > > news:f9226414.0202250113.69df43d5_at_posting.google.com...
> > > > "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
> > > news:<a5cask$j6e$1_at_lust.ihug.co.nz>...
> > > > > Oracle passwords are *not* encrypted. They are hashed, which is
> quite a
> > > > > different thing altogether.
> > > >
> > > > ... and that's bad. The password security should not rely completely
> > > > on external protection like profiles.
> > >
> > > What do you mean 'external'? Profiles are as much a part of the
> database as
> > > passwords (or tables or indexes).
> > >
> > > >In the real world we should
> > > > imply that encrypted password is available to a hacker so the
> > > > encription must be strong enough.
> > > >
> > > >
> > > > > And yet again, you seem to imply a weakness where none need exist:
> it
> > > > > wouldn't matter if you threw a Pentium VI 92789468GHz processor at
> the
> > > job
> > > > > of cracking a password, if after three attempts the account is
> locked,
> > > would
> > > > > it?
> > > >
> > > > Profiles are not an excuse for the lack of a proper encryption.
> > >
> > > So you say. I can't see the difference myself. The point is to deny
a
> > > stranger the ability to crack your database. Encryption might do
that;
> hash
> > > function plus profile does the job equally effectively. Holding out
for
> a
> > > "purer" solution that achieves no added functionality seems to me
> perverse.
> > >
> > > If you are *that* concerned, spend the extra dollars and purchase
Oracle
> > > label security or Trusted Oracle.
> > >
> > > Remember too that Oracle has all the hooks you could ask for to
> implement
> > > Kerberos, RADIUS, DES or any other asecure networking technology.
> > >
> > > You simply cannot say that Oracle is, per se, insecure.
> > >
> > > >If you
> > > > have a hashed password, just create user .. identified by values in
a
> > > > private database and take your time. Pentium VI 92789468GHz would
come
> > > > handy :)
> > >
> > > You forgot the bit about locking the account.
> > >
> > > >
> > > > BTW account locking is not that great. I'd make those three attempts
> > > > and would lock all your db accounts. Simple DoS attack.
> > > >
> > >
> > > You'd have to know all my user names first. And DoS is not quite as
bad
> as
> > > having all my secret, sensitive data plastered all over the Internet,
is
> it?
> > >
> > > HJR
> > >
> > >
> > > > Cheers,
> > > > Igor
> > > >
> > > >
> > > > > HJR
> > > > > --
> > > > > ----------------------------------------------
> > > > > Resources for Oracle: http://www.hjrdba.com
> > > > > ===============================
> > > > >
> > > > >
> > > > > "Maxim Anisiutkin" <manisiutkin_at_grtcorp.com> wrote in message
> > > > > news:71ce14f2.0202241653.74d3a4e0_at_posting.google.com...
> > > > > > > I'm sorry, I give up. I haven't a clue what you're talking
> about.
> > > I've
> > > > > > > *told* you how to make it not 20000 connections a second. For
> the
> > > > > rest...
> > > > > > > well, yes... if you leave odd export files scattered around
your
> > > hard
> > > > > disks,
> > > > > > > you probably leave your front door keys next to your wallet on
> the
> > > bar
> > > > > of
> > > > > > > your local pub too. It's not really the key's fault when you
> next
> > > then
> > > > > get
> > > > > > > broken into, is it?
> > > > > >
> > > > > > Well... That's the good sample... Definitely, it's not the key's
> > > > > > fault. But several years ago (good old times) you could afford
> such
> > > > > > kind of careless for yourself without any impact on security.
Now
> you
> > > > > > cannot... What would you say if Oracle decided not to use
password
> > > > > > hashing at all and stored passwords as cleartext? Not very
> pleasant,
> > > > > > really... And now, if you have password shorter than 7 chars
it's
> > > > > > almost the same as store it as cleartext.
> > > > > >
> > > > > > When I started with Oracle it was version 6 and at that time I
> read
> > > > > > that they used "Modified DES" algorithm for password hashing.
So,
> I
> > > > > > felt quite reassured about ability of my Intel 80486 25MHz to
> perform
> > > > > > that "Modified DES". Many years have passed... And now we have
P4
> 2GHz
> > > > > > against the same "Modified DES" for Oracle9i, because Oracle
> didn't
> > > > > > change anything in that algorithm!
> > > > > >
> > > > > > Actually, I can say that this is not the key's problem (long
> passwords
> > > > > > are not convenient to use and often decrease the level of
> security).
> > > > > > But this is some lock's problem what is too old-fashioned for
> > > > > > novadays...
> > > > > >
> > > > > > Maxim.
> > > > > >
> > > > > > P.S. I might have been wrong...
> > >
> > >
> >
> > --
> > Rick Wessman
> > Security Assurance Group
> > Oracle Corporation
> > Rick.Wessman_at_oracle.com
> >
> > The opinions expressed above are mine and do not necessarily
reflect
> > those of Oracle Corporation.
>
>
Received on Mon Feb 25 2002 - 13:04:04 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US