NYCPHP Meetup

[Chris Shiflett]

--- Aaron Fischer <agfische at email.smith.edu> wrote:
> My main questions revolves around encryption. The sources that I
> have been referencing advocate for encrypting the password during
> the authentication process.

This is probably because they recommend storing the digest of the password
in the database, so that you must compare the digest of what the user
enters to authenticate him/her.

For example:

1. User registers for an account:
   username: myuser
   password: mypass
2. You perform md5($password) to get a029d0df84eb5549c641e04a9ef389e5.
3. You store the account in the database:
   username: myuser
   password: a029d0df84eb5549c641e04a9ef389e5

So, when you authenticate:

4. A user wants to login as myuser and provides mypass as the password.
5. You compare a029d0df84eb5549c641e04a9ef389e5 (what's in the database)
   with the md5 of what the user entered to validate the credentials.

> The little application that I am working on now only has fairly low
> level security needs and encryption may be overkill

Encryption is a helpful thing when it comes to security, but only if you
understand how it's helping. Just randomly throwing encryption into the
mix rarely does you any good.

An example (I think David mentioned this) is a replay attack, and I can
give a hypothetical (but quite common) example.

Some people have this strange idea that they should reauthenticate the
user every visit instead of using sessions to track the user's state. So,
to be safe, they store the user's username and password in a cookie (or a
couple of cookies), and they encrypt the username, password, both, or some
cool string they think of that also contains secret words. They may end up
with one crazy looking cookie:

mycookie=q234c5?R~@r451xc3C%!R3ctr512%T%C

"That's GOTTA be secure," they think to themselves. Keep in mind that they
are authenticating on every visit, so this cookie doesn't require an
active session or anything. Now, imagine that a poor user uses IE (users
don't know any better), and their cookie gets exposed to whomever wants
it. Now, a bad guy visits the site with:

mycookie=q234c5?R~@r451xc3C%!R3ctr512%T%C

Oops, not only did the bad guy just impersonate the poor IE user, the bad
guy can do this anytime he/she wants. There's no need to even bother
capturing this cookie ever again. Good thing it's encrypted, huh? :-)

> Like, one question I have is, why encrypt? What am I preventing from
> happening?

Exposure. People often use sniffing as an example of what bad things can
happen from exposure, but it's really just one example (and there's no
need to brainstorm examples, since they're irrelevant in terms of
determining whether exposure is bad). For any bit of data within your
application, you want to keep up with:

1. Where the data is kept, where it travels, etc. Know your data.
2. Whether it *really* matters if the data is captured by a bad guy.

For example, if your session mechanism is session_start() and nothing
else, it does matter if the session identifier is captured. For a lot of
data, it probably doesn't really matter, so exposure isn't a big deal. The
worst that can happen from exposure is that the data is captured by a bad
guy, so don't bother worrying about how the bad guy does it (unless you're
just curious).

> I'd also be interested in hearing references for good books that
> deal with security (shameless plugs are welcome).

I hope to have a shameless plug later this year. :-)

I do have a monthly column in php|architect called Security Corner, and
you can find a few articles on my Web site:

http://shiflett.org/articles

> 1.  MySQL encryption via "password" function:

MySQL's password function is version-specific, so this can be a problem. I
think it's 4.1 where it changes, but maybe it's 5.0.

> 2.  Encrypt using php, which can use the available encryption methods
> which are available on the server operating system. In the book that 
> recommends using crypt()

crypt() is DES, and you might be interested in this book:

http://www.amazon.com/exec/obidos/tg/detail/-/B00005R08F/qid=1079453570

Hope that helps.

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
     Coming mid-2004
HTTP Developer's Handbook - Sams
     http://httphandbook.org/
PHP Community Site
     http://phpcommunity.org/