NYCPHP Meetup

[Gary Mort]

I'm migrating some custom code for subscription management, and it brings up
some interesting issues with user logon trust.

Basically, because we are primarily dealing with user profile information
for email subscriptions, we have different "trust" levels of believing
someone is who they say they are.

For example, if someone is unsubscribing from a list and gives us their
email address and a selection of lists they no longer wish to receive - than
in that case we don't require a logon of any sort, we just immediately
accept the unsubscribe information, update the records, and send a notice
letting them know. [Legally you cannot require anything beyond a single page
unsubscribe from a user.  No captcha codes.  No second page confirmations.
 Etc.]

If, on the other hand, someone is SUBSCRIBING to a list and they don't have
an account, we need to confirm their subscription information with a double
opt in process.

Add to that if someone clicks on any unsubscribe link in an email, embedded
in that link are codes unique to them so we can pull up their entire
subscription list and let them opt out.  For convenience purposes[see 1] we
might as well accept that link as authorizing them to see the list
subscriptions associated with the account.

Additionally, if someone clicks on any link in an email, asking them to
authenticate again for MOST functions is undesirable, assuming it was a
recent email.

If however the mail is 6 months old, then we don't want to trust that link
as much.

Finally, since the same system can give one access to demographic data one
has entered, or in the case of clients, campaign data for their advertising,
at that point we don't want to give them access to those areas without an
extra confirmation[and note: not everyone has passwords, so some of these
confirmations will be yet more email links!]

Basically, what it comes down to is when someone tells us who they are,
there are different levels of "trust":

1) Unsubscribe, without showing them subscription info: trust anyone
2) Unsubscribe/Change subscriptions: any valid logon link from the past
month is sufficient
3) Demographic/personal details: Valid logon links from the past week
4) Company data of some sort: Password or specific logon link from today
only
5) Internal company data: Passwords only

Add to that that there are certain functions, such as FTAF where we want to
accept most people from category 2 for the first 5 people forwarded
to...after that, we want either option 3 OR prompt for a captcha code to
avoid being used as a FTAF spam source.

What this comes down to is that there are different levels of "trust" for a
logon[we could also add in a deterioration "remember me" cookie, so after a
few days someone at level 5 go to level 4 then level 3 then level 2 and will
be prompted to re-enter their password.

Most systems have a simple binary off/on...perhaps a link to something like
syslog and fail2ban in order to lock out repeated excessive logon attempts,
but no real definition of "trust".

I was wondering what others thoughts on this issue is...beyond that I am
overcomplicating things unneccessarily. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/joomla/attachments/20100628/c83e5d1a/attachment.html>