I think in some cases links in email are opened automatically by virus scanners, and or email clients, so some people use javascript on the opened page to invalidate the token, to make sure it was truly opened by the end user.

It should be invalidated server-side at the end of the procedure.

@beppe9000 you still need to ensure that the virus scanner or email client can't complete the procedure. Using a push form should suffice, and so should any javascript that runs on user interaction.

@JohnDvorak captcha ?

@beppe9000 that might be overkill

@beppe9000 Probably don't need a full captcha- just enough to verify that some interaction was actually done. I.e. don't invalidate the token when they visit the "set password" page, invalidate the token when they actually finish setting their password. Via a post request on the form (scanners/clients generally consider GETs safe, but POSTs out-of-bounds)

@Delioth yeah even a simple one like 1+1=?, but I believe the fact that a password field must be filled same value (twice, possibly) to be a sort of captcha in itself.

"ensure that the link cannot be used for account takeover" - what's the difference between such a signup link and a normal password reset link?

You should also really make sure the links aren't predictable

I think this answer is rather terse. "This is best practice" ... okay, why?! Randomly generated passwords are almost always stronger than user-chosen ones. Users can always change their password if they want to, but why not encourage a random password by making that the default? My girlfriend's university did that and she just memorized the random password (her other, self-chosen passwords are much weaker), so that's a really positive effect. Your answer is not quite convincing, and I'm wondering if it might be wrong.

This will also serve as the page to reset a forgotten password, so having it will be necessary anyway.

@Luc even if you think the user should set a randomly-generated password rather than choose their own, a link to a page on your website where they can set the password (and in this case view it so they can w̶r̶i̶t̶e̶ ̶i̶t̶ ̶o̶n̶ ̶a̶ ̶p̶o̶s̶t̶-̶i̶t̶ ̶o̶n̶ ̶t̶h̶e̶i̶r̶ ̶m̶o̶n̶i̶t̶o̶r memorise it) is still the correct way to deliver the generated password. Designed properly, this kind of link is essentially a time-limited one-time password. Anything else creates additional opportunities for accounts to be compromised.

@Will "even Stack Overflow, a link to a page on your website where they can set the password (and in this case view it [...]) is still the correct way to deliver the generated password." I think we agree about that. I did not mean to send a random, forever-valid password by email. It should be behind a link and the link should invalidate after user interaction (and the link expires if unused). I just think it might be good to have a randomly generated password be the default, rather than just landing users on a page where they are forced to design their own password.

@Luc if you force a password upon the user it is like the pinnacle of annoying password requirements which have been proven to be problematic since in the end users will be forced to write the password on a post-it note and stick it on their screen. The account shouldn't be activated yet before the user confirmed their email anyways, and you need a captcha to avoid automation. If you want secure passwords then implement a policy which shouldn't be toooo strict.

@Luc There are so many reasons why this is not a good idea. If you don't set a password for them you don't have to show it to them - because that would be a risk (ALL password-input boxes do NOT show the password for a reason, it would have to be put in the DOM). I don't want to comment further, just know that it is a bad idea, and I have never seen any modern, secure website recently who works like this. Your password-generator could be predictable. You are suggesting to implement 100 new potential attack vectors to mitigate one other, where a best practice has long been established!

@MartinFürholz I am interested in your hundred new attack vectors, though. If you don't want to further this comment thread (which makes sense), let's continue in this room: chat.stackexchange.com/rooms/95410 | tmp - discussion about answer 212319

@MartinFürholz The value of input[type=password] is in the DOM, masking or not.

@MartinFürholz Pinging you here since you probably did not see my previous message