3

By default, ASP.Net Core configures the login exercise with a couple of things that seem strange to me. I'd like someone who knows more about infosec than I to comment on these please.

First, it sends an email to a user upon registration containing a confirmation link. The confirmation link contains BOTH the user ID (the primary key of the user record in the database) and a "token" that expires by default in one day. My question here is: It seems like a bad idea to put the user ID in plain text in the confirmation URL. (It seems to me that, in earlier versions of the Identity framework, the token had the user ID encoded in it, all happily encrypted. I may be wrong about this.)

Second, if a user logs in with correct credentials (username and password), but hasn't yet fed the authentication token back into the system (via the link in the email), the login POST routine simply says "bad login attempt". It gives the user no clue that login failed because the user needs to find the confirmation email and deal with it. If I modify this code to tell the user "you need to find that email, or click here to resend the confirmation email", is that a bad thing for some reason?

Bob.at.Indigo.Health
  • 199
  • 8

1 Answers1

0

For the first look, the user ID included in confirmation email look potentially harmful but after a deeper investigation of the code, it looks quite compliant. You have to think of how disclosed user ID can be used in some exploit.

In the confirmation email, the user ID is one of the parameters of URL link to confirm user registration. The email confirmation endpoint uses both values (user ID and code) to validate if the request is legitimate. Looking at the possible responses from this endpoint I do not see any vulnerability like for example possible user enumeration.

According to your second question, I am sure it is also following the best practices of user login feature. The main rule is to not give any clue to the application user that can be used to check if the account exists or not. If you would implement your changed message, when user is registered but not confirmed, possible attacker could use the login endpoint to enumerate different account usernames. If he would get your message in the response, he would know that account exists. When there is only one message to all possible result, attacker is not able to distinguish if account exists or not.

Bartosz Rosa
  • 337
  • 1
  • 6
  • But the user would only get the "find the email" message if he actually logs in with BOTH a username and password, so an attacker (who doesn't know passwords) should never be able to see the message. – Bob.at.Indigo.Health Apr 26 '20 at 21:25
  • You have not stated that in your question. Nevertheless, in my opinion, such a message unnecessarily would complicate the login process. – Bartosz Rosa Apr 26 '20 at 22:24