[Xylakant]

You're right, I was thinking login forms.

But the same trick works for signup forms as well: I could get an email to my mailbox "hey, thanks for registering again but you already have an account. If you forgot the password, click here." That plugs that hole. Note that this won't work with usernames, but usernames are far less tied to a specific person than email addresses. (apart from some people that have very specific and well known usernames).

[mootothemax]

But the same trick works for signup forms as well: I could get an email to my mailbox "hey, thanks for registering again but you already have an account. If you forgot the password, click here." That plugs that hole.

But how would that work for users who aren't you? My name is - surprisingly, to me - quite common, and the number of registration signups I receive at my [firstname][lastname]@gmail.com email address is really quite surprising.

[Xylakant]

The point is that you know that you own your email-address. Nobody else could have registered with that address and (rightfully) expect a confirmation email. If somebody else tries to register in error it's the same as with a fresh account at service x: The mail goes to digital nirwana.

So if you suddenly get a flood of "hey, thanks for registering again" mails you'd at least know that somebody is trying to tamper with your account. The email could even say so and add a "please notify us if you think somebody is trying to play tricks on you" link.

[mootothemax]

I'm sorry, I think that I may not have communicated my point as clearly as I would have liked :)

Nobody else could have registered with that address and (rightfully) expect a confirmation email.

I regularly receive confirmation emails from websites where the user believes their email address to be john.doe at gmail, instead of johnathan.doe at gmail. If this is common enough for my name, it must be really common for more popular names.

So, following your example through, john.doe receives the "Hey, you're already registered!" email, and johnathan.doe first thinks they have registered successfully, and later on thinks that my service sucks because they can't log in, reset their password... and registering appears to do nothing at all. User confusion - and support headaches - ensue.

[Xylakant]

You communicated your intend clearly, I guess I failed on that. Let's take HN as an example. john.doe actually owns johnathan.doe at gmail. He now registers at HN with john.doe at gmail where no john.doe at gmail is currently registered. The real john.doe gets an email saying "oh, you're now registered to HN" and poor jonathan waits for his confirmation and won't ever get a password reset mail. At some point he'll remember that he actually doesn't own john.doe at gmail and register again, with the correct email. That means that the issue you're bringing up already exists, independent of how you design your signup process [1]

So the variant of always sending an email and always accepting the registration provides the required benefit with a minor drawback.

[1] Unless you don't send confirmation addresses at all which would be pretty much illegal for most services in germany since double opt in is required for pretty much everything of interest.

edit: Since this was regarded as a statement on legal matters I herein clarify to mean "pretty much anything of interest": I loosely intended to say "most things a commercial service might want to do with data, including but not limited to sending me emails which might be regarded as an offer or an incentive to buy any paid service or any promotional email." As has been stated further down it's not a legal requirement to confirm email-addresses in all cases.

[mootothemax]

So the variant of always sending an email and always accepting the registration provides the required benefit with a minor drawback.

Ah OK thanks, I understand now. (have a headcold that is confusing me right now, so if in doubt, it's my fault ;)

I think that the only thing were quibbling about is what a "minor drawback" is to each one of us. For me, it's not such a minor issue, but it's been an enlightening conversation with you, so thanks :)

[Xylakant]

> I think that the only thing were quibbling about is what a "minor drawback" is to each one of us.

I agree. But that's always the case with security and I think in this case you can easily fix the drawback with a clear messaging such as "This is what you entered: (replay form data). You should receive a confirmation email within (x) minute. If you don't make sure the email you entered is correct." You'll need that message anyways to catch those users that enter a completely false email address anyways.

[papsosouid]

You don't need double opt in unless you are sending them emails. Assuming we're talking about a typical web app, this isn't the case. The method you propose actually has a pretty massive usability flaw. When someone signs up on my site, they are immediately logged in and free to use it. Content they upload/create isn't made visible to other until they confirm their account registration via emailed link. The email verification is to prevent spammers. Signups occur almost always directly because "I want to do X", and if you put a barrier between the sign up and the "do X" like waiting a half hour for an email confirmation, then a significant number of people will simply give up and never complete the signup.

[Xylakant]

Yes, true, there are some cases where you don't need double opt-in, but we're in trade-off territory here [1]. If you decide that your customers value privacy less than usability, fine with me. The point is: It can be done.

[1] Most services that I've signed up to lately log you in once you confirm the email. That's what I regard as the best compromise and for that case, the scheme works perfectly without leaking information.

[pbreit]

I have _never_ seen a site do that. I think your original point was weak and now you're needing to resort to weak attempts to support it. The original point stands: it's almost always unnecessary during password recovery to try to hide that an email address is in the DB.