0

I develop a web and mobile Application, managed by my REST API server (SSL with Strict-Transport-Security enabled). I don't believe anymore in the classic login/password authentification method (1)(2)(3)

Could you tell me if my idea is less secure than the authentification used on important websites like FaceBook, Slack ... ?

On account creation, an email and phone number are requested. The server send a link by email (https://server/email/confirm/:UUID) that need to be clicked. The server send a link by SMS (https://server/phone/confirm/:UUID) that need to be clicked. Theses links only said: "Thank you, the email/phone is validated. You can close this page.". (no user information, no login, just a dumb page)

If the user currently use the desktop browser to create the account, we propose him to use SMS link to be logued. If the user currently use the mobile app to create the account, we propose him to use email link to be logued. The user could choose another transports method (sms, email, iMessage, Signal, Telegram, Slack, Messenger... ) Finally, we ask the user if we need to auto-logout when he close the web|app or if we keep it logued until he click on "logout". On the device (mobile app or desktop browser), we also create a deviceID, a random UUID, we never delete it.

Now, imagine the user want to be logued (from the same device).

  • The user open the web|app, we ask his email (the field could be pre-filled if he has previously checked [x] remember my email)
  • When the "Submit" bouton is clicked, a long-polling connection is created to the REST API ( /auth/ { login: email, deviceID: uuid } )
  • A magic link is sent
  • The screen change on « Waiting you open the magic link sent » (still connected with the long-polling connection)
  • The magic link could be clicked by anybody and from any device, there is no risk, this will simply return a dump page: « Thanks, you can close this page » (long-polling prevent some MITM attacks)
  • Then, the server close the long-polling connection (of the device where the authentification have been requested) by returning the user identity, app data, and the necessary JSON web tokens for next communications.
  • If the user close the web|app, without logout and without auto-logout option enabled, next time he come back, the data and JSON web tokens are still there and could be used to continue without authentification.
  • If the user logout, we destroy data and tokens, but we keep the deviceID.

Now, imagine the user have created his account on his mobile app, and want to connect from his desktop browser.

  • There is no deviceID found, so we create a new one
  • When the authentification request is done, the server detect the deviceID wasn't used before, so, this require a 2-factor verification.
  • 2 different magic links are sent by email and by SMS, the 2 links need to be clicked to be logued and to accept this new deviceID.
  • When logued, the user need to setup his preferences for this new device (which transport method for this device and autologout option).

I haven't explained it to keep the description simple, but a user could setup his preferences to request by default 2x or more magic links from differents transports ( sms + email + Telegram + SMS to another phone... ), for the new device request, and/or any login request. Of course, if the device support fingerprint or FaceID, theses methods could be added to the list of transports to use.

So, please, do you think it's a secure system?

(1) Too many people use the same password on multiple websites, so when one website is hacked, it's easy to connect to other websites. (2) Too many people use a weak password, and if we force them to use a strong password (by calculate entropy), they forget it easily. (3) It's not user-friendly to fill a password on a mobile.

EDIT: Thank @vidarlo for your reply, here is my answer:

  • The magic link can be clicked by any device or IP. This only permit to authorise the already known deviceID who have requested the authentification. If the user open the mobile app and click on the email link from his mobile mails application, this will also give the authorization.

    • The greylisting will occur only at registration time, because it's the first time the MTA see our SMTP server/sender. After it's could be very quick, and users could also choose another transport rather email if they have problem with their e-mailprovider. We will also ask to user on registration to add our email address in their contacts list.

    • Yep, the entire security could rest with e-mailprovider, like 99% of current websites (they all propose an « forget link » to be sent by email and to connect when you forgot the password )

EDIT: Thank @Mike Scott for your reply, here is my answer: I agreed, and may be no existing transport could be secure, even SSL/TLS had security issues... but, I would like to known if my system is worst than current websites authentification. So, I have updated my subject/question.

3

No, it's not secure. Users may lose control of their email accounts, especially if they use the same password on a website that's breached, and it's disgracefully easy to social engineer a mobile phone company into transferring control of a mobile phone number. Neither email nor SMS can be regarded as a secure delivery channel.

Edited to add: The answer to the revised question is that it depends on the users. A user who uses a unique strong password will be more secure with password authentication than SMS/email authentication. A user who re-uses a weak password will be more secure with your method, but that doesn't mean they'll be secure, because they probably have a weak password for their email account as well. If you really want security, enforce 2FA. Google Authenticator is easiest for the users, and is reasonably secure, but U2F is best. However, that requires the users to purchase a hardware device and greatly restricts their choice of browsers. Only you can decide which is the best trade-off.

  • I agree with your added note, a user with a strong unique password will be better but in the reality, common users don't uses unique password and have a weak password. This is exactly why I search an alternative, secure enough and user-friendly :) – lakano Sep 16 '17 at 15:03
0
  • What happens if a user clicks the link in error? I.e. gets the mail on his phone, and clicks in error?
  • You should as a minimum ask for a explicit action on the web page, and also announce a session identifier, so that the user can be certain that they authenticate the correct session.
  • E-mail has no delivery guarantee. What if the mail does not get delivered in a timely fashion? Think of greylisting, which typically delays mail for five minutes. This is irritating to the user.
  • Your entire security will rest with the e-mailprovider.

In short, I think it will confuse users. Users are used to passwords, and to some extent 2FA. 2FA removes the problem of users writing down their password, or using the same password everywhere. Heck, you could probably skip password, and only go with 2FA if you want. Time based OTP is secure, and only requires a cell phone.

Another alternative would be to use facebook or google authentication. You externalize it, and people are typically logged into their google and facebook-accounts, so it's just a click to authorize to your site.

  • And the simple answer is that greylisting does not work like you assume. In short: do not reinvent the weel. – vidarlo Sep 16 '17 at 13:50
  • Could you precise your explaination about greylisting please? I have my own mx server with greylisting enabled on 15 minutes but this only occur the first time. I have some knowledges about maximize delivery email (1 million emails sent/month on another project). – lakano Sep 16 '17 at 14:57
  • Commonly a whitelist indication will be stored for some time, for instance two weeks. A users address book will not influence greylisting. Anyway, e-mail does not have a guaranteed delivery (time), and relying on it for logging in may be inconvenient for users. – vidarlo Sep 16 '17 at 15:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.