Newsletter Secure Subscribe/Unsubscribe

[Angelos]

Hello...
I wrote a simple subscribe script that when a user completes the
subscription form he gets added in the database and then he receives an
e-mail where he/she clicks on the follow link :

<a
href=www.mysite.com?confirm&subscribers_id=mysql_i nsert_id($rs_subscriber_id)>Confirm</a>

and gets added in the newsletter subscribers.

The problem with that is that you can easily exploit it... if you start
subscribing and then just copy pasting the above url with ascending ids.

Same happens with the unsubscribe.
<a
href=www.mysite.com?unsubscribe&subscribers_id=$ro w_subscriber_id>Unsubscribe</a>
Exploit: just use random subscriber_ids and start unsubscribing people.

But if that Number was encoded somehow and then decoded... it would solve
the proble... or at least the chances would be less.
Could you please help me ???
Please !!!
Thanks.

[Peter van Schie]

Angelos wrote:

The problem with that is that you can easily exploit it... if you start
subscribing and then just copy pasting the above url with ascending ids.

Same happens with the unsubscribe.
<a
href=www.mysite.com?unsubscribe&subscribers_id=$ro w_subscriber_id>Unsubscribe</a>
Exploit: just use random subscriber_ids and start unsubscribing people.

But if that Number was encoded somehow and then decoded... it would solve
the proble... or at least the chances would be less.

Hi Angelos,

You could keep track of the IP addresses and allow only one subscription
and unsubscription per IP per day.
You'd get an extra db table, like:

ip | date | action
==========================================
123.450.123.450 2005-11-03 subscribe

HTH.
Peter.
--
http://www.phpforums.nl

[Angelos]

> You could keep track of the IP addresses and allow only one subscription

and unsubscription per IP per day.
You'd get an extra db table, like:

ip | date | action
==========================================
123.450.123.450 2005-11-03 subscribe

Thanks for your answer,

I thought about it but... IP address is not the best way to do it... Because
it changes.
I though using the date as a unique identifier... but what happens if two
persons subscribe in the same second.

The only way I can see is something like creating an MD5 from the users id
and then decoding it....
Ofcourse there is no way to decode an MD5... so that's my Question :-)

Cheers

[Peter van Schie]

Angelos wrote:

I thought about it but... IP address is not the best way to do it... Because
it changes.
True, but since it's meant to prevent automated scripts subscribing and
unsubscribing (right?) that wouldn't matter.
In case of an ISP using DHCP, the user would have to relogon to his/her
ISP to get the IP changed. So that's pretty unlikely.
The only way I can see is something like creating an MD5 from the users id
and then decoding it....
Ofcourse there is no way to decode an MD5... so that's my Question :-)

Decoding md5 is impossible. But you could use the md5 hash of the id
still. In your confirm script just get the md5 hash of the id and
compare it to the md5 hash specified in the subscribers_id GET-var.

HTH.
Peter.
--
http://www.phpforums.nl

[Angelos]

> Decoding md5 is impossible. But you could use the md5 hash of the id

still. In your confirm script just get the md5 hash of the id and compare
it to the md5 hash specified in the subscribers_id GET-var.

Thaaanks ... you just gave me an Idea/Solution

If at the time that I Insert the user in the databse I create an MD5 string
depending either on his e-mail or his id .... and store it in the database
and then compare that.

So Thats All I want !!!
THANKS

[Jerry Stuckle]

Angelos wrote:

Hello...
I wrote a simple subscribe script that when a user completes the
subscription form he gets added in the database and then he receives an
e-mail where he/she clicks on the follow link :

<a
href=www.mysite.com?confirm&subscribers_id=mysql_i nsert_id($rs_subscriber_id)>Confirm</a>

and gets added in the newsletter subscribers.

The problem with that is that you can easily exploit it... if you start
subscribing and then just copy pasting the above url with ascending ids.

Same happens with the unsubscribe.
<a
href=www.mysite.com?unsubscribe&subscribers_id=$ro w_subscriber_id>Unsubscribe</a>
Exploit: just use random subscriber_ids and start unsubscribing people.

But if that Number was encoded somehow and then decoded... it would solve
the proble... or at least the chances would be less.
Could you please help me ???
Please !!!
Thanks.

Create an extra table "verification" in your database containing:
user_id
verification_code

Generate a random number for the verification code and save both to the
verification table.

Now send the email with both the user_id and the verification_code in
the link. When the user clicks on the link, compare both fields. If
they both match, remove the entry from the verification table.

Alternatively - concatenate an internal (known only to you) string to
the user id and MD5 hash the result. Use this as the verification code
and send just that. When the code comes back in, check the hash against
the verification table to get the user id.

(Note: use the string concatenated to the user id instead of a random
number, because random numbers can repeat!).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Peter van Schie]

Angelos wrote:

Thaaanks ... you just gave me an Idea/Solution

If at the time that I Insert the user in the databse I create an MD5 string
depending either on his e-mail or his id .... and store it in the database
and then compare that.

So Thats All I want !!!
THANKS

No problem. :)
But if you choose to use the subscriber id, there's no need to write the
md5 hash to the database. You could just use the md5 function on the id
and compare it to the md5 hash that was sent by the user.

HTH.
Peter.
--
http://www.phpforums.nl

[Peter Fox]

Following on from Angelos's message. . .

Hello...
I wrote a simple subscribe script that when a user completes the
subscription form he gets added in the database and then he receives an
e-mail where he/she clicks on the follow link :

(1) As you know it is the *wrong thing* to use the user id. No problem,
as others have suggested you use a 'random' key.

(2) You could use a hash (with salt!) or a random number and search your
table for the key when you get the response.

(3) BUT there is a problem with hashing on ID and that is that the hash
remains constant over time. So let's suppose somebody subscribes, you
don't like their posts and 'suspend their account' all they have to do
is re-submit. (OK you could put in /some/ protective logic.)

(4) AND there are missed opportunities. For example "We have sent this
email 'cos you appear to have asked to subscribe... Click HERE to
confirm or HERE if this is incorrect" OK so your URL could be
....?id=1234&confirm=Y and .....&confirm=N. Now this encourages
experimentation and one day you'll get papa using mama's id to
'unsubscribe the bitch!'.

So here is (roughly) what I do: Set up a table with a 'random' key, the
command line string that would otherwise have been used, an expiry date
and a group id. Entries are removed when either they expire, or they
are used or one of the other entries in the group is used (so multiple
choices are one choice actioned only). Page logic goes 1-look up action
using big 'random' number on command line 2-If not found take
appropriate actions 3-If found return array of parameters and remove
this action and any in the same group 4-Continue processing according to
action.

This also means you have a single URL for email clicks which then farms
actions out to other scripts. All your security processing can be put in
one place. If the action is 'say look at our terms and conditions' then
there may be no need for a login but for 'look at my details' there
would be.

Basically this is a scheme for lending out keys to your site not giving
them away.

--
PETER FOX Not the same since the borehole business dried up
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>