Yet Another 'Email Confirmation' Question: Encryption

  • Thread starter Thread starter pbd22
  • Start date Start date
P

pbd22

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?
 
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?
Click to expand...

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
 
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!
************************************************
 
Back
Top