Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Storing encrypted strings in a password column
Instead of storing encrypted binary passwords, you can store password hashes in hexadecimal form (hashed using, say, MD5 or SHA algorithm). This makes passwords irreversible, which is actually the only way to protect them. If your application can decrypt a password, be sure that some cunning person will, too. Storing hashes of 'salted' passwords, where salt is well-hidden, makes it almost impossible to recover the password, even using brute-force attack (since you modified (salted) the original password, and the way you did this is not known to attacker, the attacker will not be able to construct properly salted password to verify its hash.) Of course, this way you will not be able to reveal a forgotten password to its owner since you can't decrypt it, but you can change it on request and provide owner with changed password along with request that he changes it again really soon (possibly enforcing him to do so by also setting very limited password life duration).
-- Vladimir Zakharychev (bob@dpsp-yes.com) http://www.dpsp-yes.com Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications. All opinions are mine and do not necessarily go in line with those of my employer. "Jurgen Lindt" <nospam_at_nospam.com> wrote in message news:58gg9.10921$1C2.877880_at_bgtnsc04-news.ops.worldnet.att.net...Received on Fri Sep 13 2002 - 03:40:28 CDT
> Hello,
>
> I am trying to store an encrypted string into a VARCHAR2 column in Oracle 8i
> for Solaris. The problem is (without actually having the string to show
> you), when I do a:
>
> SELECT '<binary character string>' FROM DUAL
>
> ...the result comes back with "?"s at specific points in the string - always
> at the same location. If I store the binary string in the column using an
> UPDATE statement, upon running a SELECT, it comes back as showing the same
> string.
>
> If I run:
>
> SELECT ASCII( SUBSTR( PASSWORD, 1, 1 ) ) FROM <table> WHERE <criteria>
>
> It shows me 63, which is the ASCII value for a question mark, not the same
> character that I originally stored. So from what I can see, something
> (SQLNet, OCI?) is translating certain characters in the string to "?"s
> before Oracle gets it, then Oracle is storing the translated version.
>
> Has anyone experienced this?
>
> JL
>
>
>