Category Archives: rest

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.

Continue reading Is this passwordless authentification system is less secure than big websites authentifications?→