By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,949 Members | 1,554 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,949 IT Pros & Developers. It's quick & easy.

Yet Another 'Email Confirmation' Question: Encryption

P: n/a
Hi.

I have got the email part working.

I have it set up so there is a temp_table of the registration.
There is a confirm_code column with an encrypted ID.

My question is this - it seems that a lot of online guides are
saying simply access the temp_table and look for the encrypted
id returned by the user (from the sent email). if the ID in the
returned query string matches the encrypted ID in the table,
then the user is validated.

But, I am wondering if i should be storing the unencrypted ID in
the DB and then encrypt the ID sent to the user. When the
user returns the key, I unencrypt it and if there is a match in the
table, the user is validated. This seems a bit more secure
to me because the key that gets transmitted will not be the same as
the access key in the DB (which is what the online errata seems to
prefer).

thoughts?

May 25 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On May 26, 1:13 am, pbd22 <dush...@gmail.comwrote:
Hi.

I have got the email part working.

I have it set up so there is a temp_table of the registration.
There is a confirm_code column with an encrypted ID.

My question is this - it seems that a lot of online guides are
saying simply access the temp_table and look for the encrypted
id returned by the user (from the sent email). if the ID in the
returned query string matches the encrypted ID in the table,
then the user is validated.

But, I am wondering if i should be storing the unencrypted ID in
the DB and then encrypt the ID sent to the user. When the
user returns the key, I unencrypt it and if there is a match in the
table, the user is validated. This seems a bit more secure
to me because the key that gets transmitted will not be the same as
the access key in the DB (which is what the online errata seems to
prefer).

thoughts?
I think, a random key (such as the System.Guid.NewGuid()) will be just
fine.

Anyway, you would ask for a username and password after that

May 25 '07 #2

P: n/a
If you want a user to confirm, fire off a random key that you store in the
database (can be in a table that is temporary (confirm user) where the
record gets deleted when the user confirms.

For this, you can use something like an encrypted string, or even a GUID, or
an encrypted or hashed GUID or a random string. Waht you send is not as
important as storing it so you can compare. I would not necessarily hash
their password, etc., as a hacker might be looking for patterns that
indicate secrets.

Once they click back, have them log in. When they log in, remove the record.
you now have the string (whatever type) and the successful login. With both,
you have a nearly 100% chance of having the correct user. I say nearly as
NOTHING is 100% foolproof.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************
"pbd22" <du*****@gmail.comwrote in message
news:11**********************@q69g2000hsb.googlegr oups.com...
Hi.

I have got the email part working.

I have it set up so there is a temp_table of the registration.
There is a confirm_code column with an encrypted ID.

My question is this - it seems that a lot of online guides are
saying simply access the temp_table and look for the encrypted
id returned by the user (from the sent email). if the ID in the
returned query string matches the encrypted ID in the table,
then the user is validated.

But, I am wondering if i should be storing the unencrypted ID in
the DB and then encrypt the ID sent to the user. When the
user returns the key, I unencrypt it and if there is a match in the
table, the user is validated. This seems a bit more secure
to me because the key that gets transmitted will not be the same as
the access key in the DB (which is what the online errata seems to
prefer).

thoughts?

May 25 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.