Yet Another 'Email Confirmation' Question: Encryption

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?
 
G

Guest

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
 
C

Cowboy \(Gregory A. Beamer\)

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top