Would a GUID be a good idea to use for a random generated account code.  The
user will be given a link to pass the GUID and then be prompted for a
password.

Ex.
http://domain.com?id=0D1CB84F-82C0-4097-BA84-8B22B41FA005

TIA...

Personally, I don't like GUIDs because they're a pain.  Many links you
create will wrap because of this long string if you send the link in an
e-mail, and nobody wants to try and type out a GUID to fix it (never mind
commit the value to memory).

Some other pros/cons:

http://www.aspfaq.com/2504

Why does it need to be random?



Show quoteHide quote

Better random than sequential.  I've been testing and most mail, if
wrapping, will do so at 72-80 characters.  I'm within that range.
Typing in the GUID would be a negative, hence the link.
And if able to commit to memory, that person has less on their mind than I.
So, marking you down in the 'no' column.

What do you suggest as an alternative?

Why is that better?  Again, why does it need to be random?

It's an absolutely meaningless surrogate value.  If you want to take
guesswork out of it then use a bizarre increment, like 326 or 127.

"Aaron [SQL Server MVP]" wrote in message
Thanks for responding.

Because I have security in mind.  Being able to figure out an account code.
leaves you to work on just the password.

Ex. Why does it not pay to rename the administrator's account in NT?
Because the sid always ends with 500.
Ex. Why should a username/password logon never state a different response
for username vs password but should instead include them as one?  (The
username/password you are using is not valid.  Please try again or go
______/call ______ for support.)  It lets the attacker know one of them is
correct, usually the username.

Even if the increment is obscure, if it is not random, it has a pattern and
can be known easily.

It doesn't have to be a GUID but I would prefer it to be random and not just
numeric.  I have already written a password creation routine which has
optional punctuations and optional random lengths between 8-15 characters.
Perhaps I will consider doing the same for the account code.

BTW... just asking but is this your alternative, a bizarre increment?

No, actually, I am not sure the user ever has to know the surrogate and
meaningless key you've applied to identify their account.  Whether they use
?somePage=367 or
?somePage=big_long_stupid_string_here_that_WILL_wrap_in_some_clients_no_matt
er_how_much_you_tested_it, they still have to map that to the e-mail address
that specific identifier was sent to.

You asked if it was a good idea, I think I've pointed out a couple of issues
with it, you're going to ignore those, so go ahead, use GUID, it must be a
fabulous idea.  *sigh*

"Aaron [SQL Server MVP]" wrote in message
Show quoteHide quoteAnd those were excellent points too.  (O:=

You shouldn't take this personal.  I respect your opinion(s).  I may not
always agree but getting opinions of others helps me to make a decision and
generally provides knowledge of something I may not have considered.  You
have valid points.  I also never said I was going to ignore them.  And, I
don't particularly like the GUID idea although I do use it to eliminate SPAM
(another discussion).

The email address is not relevant here because it is not the sending to the
user I am concerned with, in this discussion, but rather the attempt to
visit the link with a valid account and then attempt to brute force the
password.  My goal was to make it difficult before they ever got to attempt
attacking the password.

I also stated in my last post, I would consider using my password creation
routine.  A randomly sized alphanumeric case-sensitive account code might be
a strong enough defense, at least for the account code.

Perhaps I should explain what this is for...

The account is for subscriptions for fuel surcharges in my shopping cart.
Without the subscription, merchants will have to keep track of this
themselves to avoid losing money re: shipping should the price rise.  With a
subscription, which will require the account code/password and known link,
the merchant will "Set it and forget it."  Annual renewals will require a
logon, so only during the initial setup and renewal will this issue present
itself.  Surely people will be able to copy/paste at a minimum once a year.

I wasn't taking it personal.  It just started sounding an awful lot like,
"I've already made up my mind, but why don't you waste some time trying
anyway."

"Aaron [SQL Server MVP]" wrote in message
Sorry.  If I had already made up my mind, I would not have asked.  I am
always open for suggestions.  I may be over thinking it because now I'm
considering an MD5 hash of various things which means the account can be
pretty much anything.  The other goal is to make it difficult for my
customers to pay once, use many times.  I know this is an impossible task
for some and will only have our agreement to protect me somewhat.

The difficult part is I am limited because I believe most of my customers
will have hosted web sites.  Not all, like discountasp.net, will allow you
to have scripts scheduled.

dictionary within dictionary
Avoidinig globals
xml, character encoding, asp question
IE DOES NOT SUPPORT COOKIE on WIN2K and XP
Stopping running code at a certain point