Is it imperative that you encrypt and store the password? In other words,
is it absolutely necessary for application to be able to decrypt a password?
If not, then you will save a lot of processing power by not encrypting the
password and storing its hash instead. And it'll be more secure, too.
In your current implementation, once someone figures out how the
encryption key is generated (by reverse-engineering your code, for
example), they can decrypt all your users passwords in one run and
use them as they see fit. If you store a one-way cryptographical hash of
the password it is nearly impossible to reconstruct the password from it
and it's very hard to brute-force it, especially if you 'salt' it some way
(you are actually doing this when computing the encryption key). As a
rule of thumb, if security is your concern, never store user passwords in
any reversible form, or you're opening doors for hackers (anything that
can be reversed - will be reversed.) In your case, your own encryption
function may be used to decrypt the password as well - just feed it
login ID and encrypted password, and you get decrypted password
back thanks to symmetric nature of 3DES and the fact that encryption
key depends on login ID and a constant - and not on anything else,
like password itself (but making it dependent on password will actually
prevent you from decrypting it without knowing it - same effect as if
you use hash on password alone, same strength, but a lot more work
to do.)
--
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:Q1wg9.27849$jG2.2034165_at_bgtnsc05-news.ops.worldnet.att.net...
> Good ideas there. The password hash is generated from a login ID and a
> constant in the code. The hash is then used to encrypt the data (password
> in this case) and the hash is not stored. The hashing mechanism in this
> case is MD5 (192-bit key), the encryption used is Triple DES.
>
> So the sequence for encrypting a person's password is:
>
> (a) Grab the login ID (text string of 8 long) & password
>
> (b) Run it through the encryption function (generates hash from login ID and
> constant in the code - concat, then encrypts the password using the hash and
> Triple DES algorithm)
>
> (c) Store the encrypted password in the database
>
> May not be the greatest way of doing it.
>
> JL
>
>
>
Received on Mon Sep 16 2002 - 04:32:38 CDT
