Sending static registration links via email

Question

In our mobile application, users need to register first before they can use it. After successful registration, they an now login and use features of the app. Now we will have a feature in our application where all users who have records in the active directory and "master" database but not yet registered in the app would be sent sms with a registration link. The details are the ff.

1. A static link is sent (not the usual dynamic ones where a token is appended to the url)

2. When that link is clicked, an authentication page would show up in the machines internet browser and show a page where it asks for the user's company ID and birthday. When the entered information is valid, a one time password is sent via sms and if valid, the user can now proceed with registration

The question is, is this kind of process secure? there was a debate within our team whether the link sent via sms should be dynamic or static? what are the possible vulnerabilities of this kind of process? doesn't seem to violate any OWASP standard.

Edited: fields in the input page are the user's company id and date of birth

Answer 1

When that link is clicked, an authentication page would show up in the machines internet browser and show a page where it asks for the user's company ID and birthday.

This is not a safe on-boarding process to prove that a new app user is associated with an identity in active directory. Birthday and company ID are way too public, particularly to other users in the company. Another employee would easily have access to the on-boarding link from their legitimate account.

The best solution would be some kind of actual identity federation. Sending an email/text to the users contact information that is already in the user database with a unique link would at least prove that they control the phone or email account.

Answer 2

Assuming I'm understanding this correctly, your app works like:

1. A Company shares a list (possible) users with your app from their Active Directory or similar?
2. A user from that company downloads the app on their phone and their phone reports the mobile number? (or some other way of getting mobile?)
3. your app server sends an SMS with a static link in it to said mobile number
4. User goes to link and enters company email and DoB
5. one time password is sent via SMS etc

The first SMS step does nothing, since the link its static, it in no way verifies control of the mobile number (but the second one does). You may as well send users straight to the static page from the app and skip the SMS link there.

The big hole is an attacker submitting their own mobile somehow, and then guessing company emails/DoB until they get a hit. Company email is often something like firstname.lastname@company.com, so pretty easy to guess from a quick browse on Linkedin or something.

The two key things you need to look at is how the mobile number is set, and verifying control of the company email. You could make the first mobile link dynamic, to prove control of the number, then send the one time password via email instead of SMS to prove access to the email. Of course you could just send a registration link to the email in the first place.

Answer 3

A static link proves nothing. Once it's known by an attacker, it's is easily bypassed.

Consider this scenario:

1. Adversary signs up for your service using invalid@gmail[.]com.
2. Your server sends registration link to invalid email address. This email bounces or doesn't -- the results don't matter.
3. Adversary waits about 10 seconds, then navigates to your known static page and enters a random birthday.
4. Adversary now has a valid account with an invalid email address.
5. Adversary repeats this process one thousand times, and has one thousand accounts on your system, and uses them to "vote up" spam comments.

A dynamic URL solves this by being unguessable. Only the recipient of an actual email sent by your server would know the dynamic URL and be able to respond correctly to your service. But for this to work, the value in the URL must be truly unpredictable; not sequential, based on time or the user's data, etc.