1

I'm making a Actix-web/Rust web-application where users are solely allowed to register and login with their mobile phone number. The login-screen consists of one input asking for the phone number. If a user with that phone number already exists in the database he gets redirected to the authentication-page, otherwise to the registration page.

The authentication-page has only one input asking for a authentication-code. This code is sent to the user by SMS as soon as he wants to login.

I want to verify that the system I am using is secure and valid.

This is a simplified version of the relevant MySQL tables: User authentication table

Steps of authentication:

  1. The user inputs his phone number in the login-screen.
  2. System checks and sees that a user with this phone number exists.
  3. In the table UserAuthenticationRequest we insert:
    • The ID of the User trying to authenticate.
    • A random generated number of 6 ciphers (hashed).
    • The timestamp of the insert.
    • The number of guessing attempts for this specific authentication request, default 0.
  4. Random generated number is sent to the phone number of the user through SMS.
  5. User is redirected to the authentication-page where he needs to insert received number.
  6. If the hashes of the given number and the number in the table UserAuthenticationRequest match, the user is authenticated.
  7. If not, the column attempts increases with one.

Extra info:

  • In the table UserAuthenticationRequest the column user_id is unique. So for each user there can only be one authentication at the same time,
  • A MySQL event will be configured to delete all rows older then 15 minutes.
  • If an authentication has more then 3 attempts the row gets deleted and a new code must be requested.
  • The authentication is session-bound so the generated number must be inputted in the same browser as in which the request was sent.

Is this a safe system to authenticate users?

Improve this question
3
  • Say I want to go abroad. My SIM won't work abroad, I will have to buy a new SIM with a new number when I land... so how would I use your service in this scenario? I guess it would be impossible to do since you can only have one phone number linked to the account? And even if I could add 2 how would I get the SMS to add the new number? Yuo'd have to allow a procedure to get a "registration code" that will work later when I land? IMHO: basing everything on the phone number is way worse than using email...
    – GACy20
    Commented Oct 27, 2022 at 8:48
  • There really isn't any such thing as "a safe system to authenticate users by phone number". Phone number security isn't good enough - too easy to port somebody else's number to another network, or claim you lost your (actually somebody else's) SIM, although carriers in some countries are getting better about it. Furthermore, SMS is often unsecured in transit (using a modified "femtocell" or similar you may be able to intercept SMS). It's not even good as a second factor - NIST recommends against it, in fact - and using it as a single factor is a very bad idea.
    – CBHacking
    Commented Oct 29, 2022 at 9:54
  • There's also the risk of people losing access to their number. Obviously this can happen when traveling (or when in an area without cell reception, though most phones support WiFi calling now), but it can also happen permanently if somebody changes their number. Not only do they then lose access to the account, perhaps somebody else gets it when the number is recycled (and if the new owner puts their number into your system, they'd get access to the old owner's account!)
    – CBHacking
    Commented Oct 29, 2022 at 10:00

4 Answers 4

Reset to default
2

No, it's not safe.

The reason is this:

If an authentication has more then 3 attempts the row gets deleted and a new code must be requested.

Although not as straight forward as a brute force attack against a single authentication token, you're still allowing unlimited attempts to authenticate. You should block/disable the account after 3 (or 5) attempts - no one should need more than a couple of tries to enter a number they read from the screen of their phones to the same or another device.

On the fact that you're using a mobile phone to authenticate users, aside from all the issues that others have mentioned, you should have in mind that authentication usually involves:

  • something you know: usually a password (this is the easiest to implement)
  • something you have: usually a security device or your mobile phone
  • something you are: biometrics

The more steps you involve to the authentication process, the more secure your system is and the more user unfriendly your authentication process is.

Using one way to authenticate (single-factor authentication, SFA) is what most people go to, but it's considered very risky by today's standards. Two-factor authentication (2FA) tends to become more common, by using a password and a mobile phone as a second step. Multi-factor authentication (MFA) can employ more advanced methods, such as biometrics.

What you've done is that you've replaced the password authentication with a mobile phone ("something you know" with "something you have"). Although more difficult to break, it's still SFA.

Is it safe? It depends on what you're trying to protect and by whom. Is it for a game account? Yes, it's safe. Is it health records of a hospital? It's probably safe against the average health professional. But it's not safe against knowledgeable adversaries.

Improve this answer
1

The security weaknesses with SMS are well documented (SS7 attacks, sim-swapping, compromised mobiles, etc), so whether or not this authentication system is "safe" depends on what you threat model is. If this application is used for online banking, the answer is probably "no"; if it's a browser-based game and you're just tracking high scores then the answer might be "yes".

It's also worth considering that by using SMS for authentication, you're making your application inaccessible to anyone who doesn't have a mobile phone, and also making it so that if someone is unable to receive an SMS at that point in time (not got their phone with them, no signal, flat battery, etc) then they won't be able to login. Storing mobile phone numbers may also have GDPR implications.

Improve this answer
2
  • 1
    An other con is that the phone number is the username... which means changing the phone number would break the authentication, so OP will have to implement some functionality to either "group" more than one phone number under the same user or to be able to modify the phone number while keeping the data. Regarding GDPR: I don't think there is any issue with storing the phone number if the only use is as (non-visible) username and to perform login, because this would fall under "necessary to make the service work". However OP won't be able to use those numbers for other purposes.
    – GACy20
    Commented Oct 27, 2022 at 8:45
  • @GACy20 good point about changing numbers. On the GDPR side this law stack exchange post suggests that phone numbers on their own are personal data under GDPR. But IANAL, so I'm not going to give any opinion on this, other than that OP needs to think about whether they have GDPR concerns.
    – Gh0stFish
    Commented Oct 27, 2022 at 9:16
1

I can see which of my friends (or enemies) is using your service by entering each phone number in turn and observing whether you offer an authentication code or display a registration screen.

For this reason, systems of the kind you are proposing usually say to the user, “If you are registered with us, we have just sent you an authentication code; if you aren’t, we haven’t.”

Improve this answer
0

By using SMS for auth, you are opening yourself to many threats.

For example any user can spam signup on your page with random phone numbers, leading to mass SMS spam on behalf of your app. That will lead you to spend quite a lot on SMS API provider, and can potentially mark your account as spammer.

Also consider people without phone number, or international users whom cannot receive SMS or receive them with large delay. Or users travelling, but roaming disable, so they can't receive SMS. SMS channel itself is not considered secure for serious applications that require high security.

If you app does not deal with money, it is probably okay.

Improve this answer

You must log in to answer this question.

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