2

About one year ago, for about two months, lots of user accounts with unverified login email address started to pile-up.

All addresses belonged to @yahoo.com. It appears (don't know for sure) some sort of Yahoo! Messenger vulnerability allowed some hackers to spread to many systems and then create accounts on our website.

Some users clicked on the activation link, although the email was correctly informing not to take any action if they did not request an account.

The only thing that could be deduced as usefull for the attackers, was that they knew the passwords for the new accounts, and were hoping to create as many accounts as possible (from different IP addresses) with an automatic effort from different locations, while avoiding captchas or other rate limiting protections.

This same type of attack can be used to impersonate someone with elevated access to some services (me thinks).

The only protection I can think of is asking the user to choose a password after clicking the account activation link, which will also perform auto-login. To create an account, the user will only be asked for his email address. I haven't seen this done anywhere else at all, is there a security drawback I am missing?

Improve this question
5
  • 1
    This question is written really oddly. You use "them" and "they" often, but it's not really clear who you mean by that. You also don't describe the new account creation process at all, so I'm also having difficulties understanding what you're actually asking. Could you please try and rewrite it for clarity?
    – TildalWave
    Commented Feb 11, 2014 at 12:26
  • "Them" is not used often, it is used once. And it clearly refers to the attackers. They are the only party involved in knowning the passwords, as they are creating the accounts. The entire post is about impersonation. I have edited for the sake of obviousness.
    – oxygen
    Commented Feb 11, 2014 at 12:52
  • Simply have the user solve a capcha when they click the activation link. Capchas are annoying enough, most people who didn't request an account wont solve it.
    – Daisetsu
    Commented Feb 11, 2014 at 17:53
  • Be offended all you want, but @MarkC.Wallace's point stands. It's not clear at all what the threat is you're trying to defend against.
    – Stephen Touset
    Commented Feb 12, 2014 at 5:49
  • @StephenTouset The post has been edited since then, including the title (by @MarkCWallace). It is clear what threat I am defending against and how. Since the solution is not widespread (haven't seen it anywhere) I am suspicious of it. If you can understand a widespread classical account activation method then you understand the variant I am proposing, and why.
    – oxygen
    Commented Feb 12, 2014 at 13:58

2 Answers 2

Reset to default
1

So if I'm reading your question correctly, you're concerned about attackers creating accounts using e-mail addresses they did not own.

The first question would be "why is this a problem?" I'm guessing that only a small percentage of the people who's e-mail addresses were mis-used would have clicked a sign-up link for an account they did not request?

Also it's generally possible for anyone to create an account on a site which just requires a valid e-mail address. If you have your own domain name you can use [anything]@domain.name for as many accounts as desired and also there are services which provide temporary e-mail addresses explicitly for the purpose of signing up to things.

If the problem is that you don't want these accounts cluttering up your system, then I'd suggest that the best way to prevent it is to make them take some action after they click the link in e-mail, before you activate the account.

For example ask them to log in with the credentials they used to sign-up, and tie that to the one-time code in the link.

Improve this answer
7
  • Asking them to login using the sign-up credentials is equivalent in effort to asking for password creation after sign-up. Your alternative works fine (except it completely disables auto-login, which is desired to ease the ordering process, etc.). My question was: "is there a security drawback I am missing" in setting-up the password after clicking the verification URL? Not a yes/no question, as it requires some sort of demonstration for both cases, or reasoning of the rest of the world for asking password always before email verification.
    – oxygen
    Commented Feb 11, 2014 at 16:04
  • Don't think I'd agree that they're equivalent. in your scenario anyone who can intercept the e-mail and click the link gets the account (even if they didn't do the initial sign-up), in my scenario the person clicking the link needs to know the password used during sign-up.
    – Rory McCune
    Commented Feb 11, 2014 at 16:11
  • The problem and question isn't about mailbox security, it is about a very specific impersonation scenario, where clicking is accidental. You solution is good (as I already said), except it is asking for the password twice which is undesirable.
    – oxygen
    Commented Feb 11, 2014 at 22:05
  • What if the user forgets the password before activation? How will password recovery work, if not by trusting the same verification URL method used in my scenario?
    – oxygen
    Commented Feb 11, 2014 at 22:29
  • @Tiberiu-IonuțStan If the user has already forgotten the password before activating the account, they should scrap it and open a new account. Asking for the password twice doesn't strike me as bad here, and it may already be in the browser's password wallet anyway.
    – Gilles 'SO- stop being evil'
    Commented Feb 12, 2014 at 18:55
0

The first drawback I can think of is that if your service is used a lot, someone only needs to guess one of the currently active links and they will then be able to choose a password for it and take control of the account, particularly since you intend to auto-log them in which would give them the username and the password they selected.

You really need to have the user create a username and password when requesting the account and then confirm it when they click the validation link (unless their session is still valid.)

Improve this answer
2
  • The links are sufficiently secure and random to prevent guessing (and also expire after some time). It is not guaranteed to have the session still active, because you cannot control which is the default browser, or browser mode (when using a non-web email client). I'm not sure what you mean in the last paragraph.
    – oxygen
    Commented Feb 11, 2014 at 16:44
  • I get that you can't rely on the session remaining current. I'm saying they should be required to login with the original username and password in order to verify their account if the session isn't still current. The random value may not be easily guessed, but they only have to guess a working value. It would be best to lock each code to a particular user. It may be an acceptable risk to you compared to the usability, but it is a risk (I'll be it a very small one.)
    – AJ Henderson
    Commented Feb 11, 2014 at 16:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .