NYCPHP Meetup

[Michael B Allen]

On Sun, Feb 1, 2009 at 12:15 PM, Michele Waldman <mmwaldman at nyc.rr.com> wrote:
> I'm sorry for all these stupid posts.  I'm in the middle of a learning
> process.  It's always darkest before the dawn.
>
>
>
> I see cookies are viewable and editable.
>
>
>
> Does anyone know if any browsers allow the user to view and edit the request
> Authorization?

You have to assume that everything being transmitted by the browser
can be modified.

For example, there is a tool called "Burp Proxy" that allows you to
intercept regular browser communication, modify it in some way such as
by adding or removing a header like a cookie and then sending the
modified request to the real target. This is the sort of thing that
hackers use to find holes in web applications.

> If I hack the mod_auth_digest file to include mysql, which I haven't
> verified is totally possible, yet, am I wasting my time.
>
>
>
> Basic authorization isn't flexible enough.
>
>
>
> What I want is to use AuthType in a secure fashion.
>
>
>
> Does it work like that?
>
>
>
> Is that stupid, too?
>
>
>
> I'm not going to be using real Digest on my server, why does mod_auth_mysql
> have to be Basic?

I'm not really sure what you're trying to do but usually
authentication is built into the application where possible because
then you have control over how passwords are stored, managed and you
have script level access to user information and associated groups and
preferences. If you use mod_auth_something, you're just putting a gate
in front of a directory and you have limited your account management
options. Those modules are for throwing up protection in front of
existing applications that cannot easily be modified. If you're
writing something new in PHP that is quite the opposite case.

IMO everyone storing passwords in a database should associate them
with accounts and use a standard hashing method. For example, a very
common method is a base 64 salted SHA which is computed in PHP as
follows:

  $salt = substr(md5(mt_rand(), true), 0, 4);
  $ctx = hash_init('sha1');
  hash_update($ctx, $password);
  hash_update($ctx, $salt);
  $hash = hash_final($ctx, true);
  return '{SSHA}' . base64_encode($hash . $salt);

This will give you an ASCII based string like:

  {SSHA}7d819b5bab847634b091211de1ee6c587634

Put this whole string in the DB (including the {SSHA}). To validate a
password you need to retrieve the above hash string, base64 decode it,
extract the salt from the end, compute the hash and compare that to
the begging of the hahs. This method is strong because it's salted and
uses SHA and uses a standard hashing method which allows you to
transfer the passwords to other storages that are more likely to
understand them such that you don't need to have users change their
passwords after the transfer. Another developer can take one look at
the hash string and know exactly how to compute it.

This is how I would do it anyway. Most people actually invent their
own password storage method reasoning that the obscurity of it adds a
level of protection. That logic is incorrect.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/