Results 1 to 9 of 9
  1. #1
    Join Date
    Dec 2003
    Location
    Gandhinagar India
    Posts
    22

    Question Unanswered: storing passwords securely in oracle

    If i store password simply in a table, it oculd be viewed by anybody. One way is that i encrypt the password and then store it table. Is there any in-built package or something else in oracle so that i could store passwords securely in the tables. it must not be read giving
    "select password from tablename".
    Thanks

  2. #2
    Join Date
    Feb 2004
    Location
    Eternity
    Posts
    31
    The easiest way is not to allow select on the table to other users.(This is the default setting when a table is created)
    To explain it clearly user A creates a table TABLEA,then when the user B uses fires a query say " select * from A.TABLEA" ,then the error
    ORA-00942: table or view does not exist is displayed.
    Hence your requirement of not to allow the users to select from the table with passwords doesnt work.

  3. #3
    Join Date
    Dec 2003
    Location
    Gandhinagar India
    Posts
    22

    Clarification

    but user A can still see it. I want that the creator should also not be able to see the passwords because he/she may misuse it.
    Thanks

  4. #4
    Join Date
    Oct 2003
    Posts
    87
    Here's what Tom Kyte, of AskTom.oracle.com has to say:
    go to asktom.oracle.com and search on "password hash"
    Last edited by N-ary; 02-23-04 at 09:24.
    Oracle - DB2 - MS Access -

  5. #5
    Join Date
    Oct 2003
    Posts
    87
    oops . . .
    Oracle - DB2 - MS Access -

  6. #6
    Join Date
    Dec 2003
    Location
    Oklahoma, USA
    Posts
    354
    There are a couple of solutions you can try.

    First, look at the Oracle documentation for the OBFUSCATION TOOLKIT. This toolkit will allow encryption of strings which you can store in columns in your tables.

    The second option, is to do something like remove all privs to the password table, but create a view that does not include the password column. For people who need it, grant select privs to the view, not the table.

    JoeB

  7. #7
    Join Date
    Oct 2003
    Posts
    87
    Tom Kyte, of AskTom fame, says:

    I am currently starting a project to "encrypt" passwords and store them in
    the database. You mention on your website this should never be done and hashing
    is the way to go.

    What benefit does hashing have over encrypting? How is hashing safer by not
    using a "key"? Can the hash just be reverse engineered?

    Thanks for your help as always.

    and we said...

    hashes cannot be reversed.

    if you store encrypted passwords -- you have to do key mgmt. if the key gets
    compromised, you have just given away all passwords.

    since you do NOT need to know what the password is -- only verify if the correct
    one is given -- you should use a hash.

    hashed_pw = dbms_obfuscation_toolkit.md5( username || password );

    save that -- then when someone presents you a user/password -- all you need to
    do is hash it, compare it and let them in (or not).

    It is the way Unix and Oracle work.

    Reviewer: Invisible from UK

    Just to add to what Tom already said...

    Hash functions are SPECIALLY DESIGNED to be very very VERY hard to reverse. This
    is design goal #1. (Design goal #2 is to make it really unlikely that any two
    things will ever have the same hash.)

    The MD5 algorithm is here:

    http://www.faqs.org/rfcs/rfc1321.html

    MD5 produces a 128 bit hash value. That is, there are 2^128 different possible
    output values.

    Is 2^128 big?

    Look at this:
    2^10 = one thousand (approx)
    2^20 = one million
    2^30 = one thousand million
    2^40 = one billion (1 + 12 zeros)
    2^50 = one thousand billion (1 + 15 zeros)
    2^60 = one million billion (1 + 18 zeros)
    ...
    2^120 = (2^60) x (2^60) = (one million billion) x (one million billion) = one
    billion billion billion. (1 + 36 zeros)

    2^121 is TWICE AS BIG as 2^120.
    2^122 is TWICE AS BIG as 2^121.

    Get the picture? It's a BLOODY BIG NUMBER! :-)

    In fact, 2^128 is a 38 digit number! To be exact, it is approximately

    340,282,366,920,938,463,463,374,607,430,000,000,00 0

    (as near as the standard Windows Calc.exe program will tell me)

    To give you some idea of the vastness of this number, imagine 12 grams of carbon
    (i.e., a small lump of coal). The number of individual atoms in that is 6.022 x
    10^23. In other words, roughly 6 followed by 23 zeros.

    Using this, you can calculate that 2^128 carbon atoms would weigh

    565,065,372 tonnes (!!!)

    Think about how unimaginably TINY a single atom is, and how many trillions of
    them fit on a pinhead. NOW think about how HUGE 500 megatonnes is...

    It's so huge it's beyond imagination... beyond comprehension!

    SO, the number of possible MD5 hash values is equal to the number of atoms in
    500 megatonnes of carbon. Finding two things with the same hash isn't so much
    "finding a needle in a haystack" as "finding a single atom in [literally] a
    MOUNTAIN of carbon"!

    In practice, the only way somebody can get from a hash value back to the
    original password is to just try every password you might have used, put it
    through the same hash function, and see if the result matches your password
    hash. It takes a LONG time.

    Of course, with the system Tom suggests, it doesn't MATTER if the password they
    find really is your password or just hashes to the same thing. However, we
    already said a hash function is designed so that it's highly unlikely (virtually
    impossible) to find anything else with the same hash!

    In practice, you will usually find that any OTHER text that hashes to the same
    thing as your password would be
    -> very very much longer
    and / or
    -> not printable ASCII
    Chances of two SHORT, PRINTABLE text strings giving the same hash value are
    TINY. It's one of the design goals of the hash function. And MD5 has been around
    long enough to have been analysed and tested by SO many experts, I think we can
    safely say it does that it's supposed to very well indeed.

    Just my comments :-)

    [Tom - you're welcome to add all or some of this to
    http://asktom.oracle.com/~tkyte/Misc/Passwords.html
    if you feel inclined.]

    PS. Guess what MY hobby is. ;-)

    PPS. It took me all morning to reasurch this. It would not have been possible
    without the Google search engine - www.google.com

    PPPS. Tom is great!


    Followup:
    forget windows "calc"

    ops$tkyte@ORA920PC> set numformat 999999999999999999999999999999999999999999999

    ops$tkyte@ORA920PC> select power(2,128) from dual;

    POWER(2,128)
    ----------------------------------------------
    340282366920938463463374607431768211456
    Oracle - DB2 - MS Access -

  8. #8
    Join Date
    Sep 2003
    Location
    Virginia, USA
    Posts
    246

    to be safer, include the db ID in the hash

    one of the best ways to crack a password is to get the hash onto your own system then run all possible values at it to see if you get a match. The hash therefore needs to be based on something the hacker does not have, such as the database ID number.

    If I "select username, password from dba_users" on my first database and then go to my second database and "create user 'same username' identified by values 'same hash';" it will create the same user but with a differnt password. Eventhough the hash values are exactly the same on both servers, they are technically different and cracking one does not crack the other.
    MarkRem
    Author, Oracle Database 10g: From Nuts to Soup
    http://www.remidata.com/book_nuts2soup.htm

  9. #9
    Join Date
    Oct 2003
    Posts
    87

    Re: to be safer, include the db ID in the hash

    Originally posted by markrem
    one of the best ways to crack a password is to get the hash onto your own system then run all possible values at it to see if you get a match. The hash therefore needs to be based on something the hacker does not have, such as the database ID number.

    If I "select username, password from dba_users" on my first database and then go to my second database and "create user 'same username' identified by values 'same hash';" it will create the same user but with a differnt password. Eventhough the hash values are exactly the same on both servers, they are technically different and cracking one does not crack the other.
    Hmmm, if I'm a haxor, I'll probably already have your database ID number along with a lot of other system level IDs. You might consider using something else.
    Oracle - DB2 - MS Access -

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •