NYCPHP Meetup

[Jim Hendricks]

Let me start by saying I am not a security expert, and therefore what
follows is just opinion based on my own 20 years of experience in
software development.

> My main questions revolves around encryption.  The sources that I have
> been referencing advocate for encrypting the password during the
> authentication process.  However, I've been frustrated by how briefly
> this topic is passed over in my books.  The little application that I
> am working on now only has fairly low level security needs and
> encryption may be overkill, but I have another project coming down the
> line where the security needs will be greater, so I might as well get
> started learning this stuff now!  Like, one question I have is, why
> encrypt?  What am I preventing from happening?
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.  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.  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.

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