NYCPHP Meetup

[Aaron Fischer]

On Mar 16, 2004, at 9:23 AM, Jim Hendricks wrote:

> The purpose of encryption during the authentication process depends on
> when in the process you are encrypting, and what your underlying 
> application
> structure is.
>
> Back in the days of an application running on a standalone machine 
> where
> the password didn't transport over a network, the purpose was solely 
> for
> data security.  In today's applications where passwords are passing 
> over
> an insecure network you have the dual purpose of data security and
> application
> security.  If the password is encrypted on the client machine before it
> is passed to the webserver, you are attempting to keep you application
> secure
> from net lurkers who may scoop up the uid/pw and then gain access to 
> your
> application as a valid user.

Encrypting on the client machine is best done with SSL?

>  If the password is not encrypted until it is
> on the
> server you are fufilling data security.  If all the passwords are 
> encrypted
> in the
> database, you provide an additional security in that anyone who may 
> gain
> access to the db does not automatically gain access to the ability to 
> spoof
> your valid users.

These are great distinctions, thanks.

> My own pet choice of encryption is a simple RC4
> encryption
> where I generate a few random characters + password + personal key as 
> the
> data stream, then encrypt this with the users password.  In this case, 
> I
> need
> to be able to decrypt the password coming from the browser so that I 
> can
> attempt to decrypt the stored password.  On successful decryption of 
> the
> stored password the code can verify the success based on the password
> portion of the plaintext matching the password used to decrypt.
>
> The random characters serve to ensure that 2 users with the same 
> password
> do not generate the same ciphertext and thereby allow someone with db
> access the ability to guess at a password based on visual patterns in 
> the
> cipher text between users.   The purpose of the personal key allows for
> secure storage of a generated key for each user.  This key can then be 
> used
> to encrypt sensitive data that only the specified user may view.  Once 
> again
> the prying eyes of a db admin would not be able to view that sensitive 
> data
> because the key to decrypt is itself encrypted with a key with which 
> the db
> admin does not have access to.
>
> The downside to the approach I just mentioned is that if the user 
> forgets
> their password, they must be issued a new password, the old password is
> non-recoverable.  Any data encrypted with the personal key secured by 
> the
> old password is now also unrecoverable.  That is why when I need the 
> added
> security of personal keys and sensitive data encryption, I build an 
> admin
> store
> which contains all the personal keys encrypted with the admin's key.  
> Access
> to the data can still be lost, but it would happen only if the admin 
> loses
> access
> to their personal key which happens much less often than a user losing 
> a
> key.
>

Whew, at least some of that was over my head at this point, but it 
gives me something to chew on!

> Once again remember, this is my own design and is not based on years of
> experience in security, but in application development.  So far I have 
> never
> had
> a breach that I have been made aware of, now weather that is luck, or 
> luck
> in
> a good design, I couldn't tell ya'.
>
> Jim