0

I am intrested in creating a login mechanism which would create a user and validate his account, without using any of his details such as email, phone number etc.

Here is what I can think of :

  • Allow user to sign up from a website. This uses their browser
  • Make them download an application on their phone/desktop
  • They then sign in using ther username and password as defined in step 1
  • In the app, they click a button to verify their account

Some problems that I can think of

  • If using the desktop version instead, they could create an auto click/type bot in order to validate
  • User may have forgotten their username/password and they are signed out on their phone/desktop application, meaning they have no way to reset their account

To fix the password reset issue, I could use Google's authenticator application to create a one time code. The problem with this is if the user does not have accsess to their phone

Would this be a viable method for creating a web/app based service without collecting the users personal information? If not, are there any other ideas or is this not realy posible?

If this is not needed in order to validate a users, would this work by securing an account (by using the phone app)

  • What do you mean by "validate his account"? – Anders Dec 16 '16 at 18:43
  • What I mean is, you sign up to a website, they then send you an email asking you to click on a link. You click on the link once you recieve the email and the site verifies you. – iProgram Dec 16 '16 at 18:49
  • In your solution it is easy for the attacker to impersonate a user, there is no guaranty that the right user is using the application to validate the account creation, contrary to phone or email that are in hand of the right user in the most time. – elsadek Dec 16 '16 at 18:52
  • @iProgram Thats how you verify that it is your email, not how you "verify the account". Is verify the email what you mean? In that case your question seems to be "How do I verify the email without using the email?" – Anders Dec 16 '16 at 18:53
  • 1
    Here, download this random app on your phone/computer, run it. I would rather not create an account on your site... – ThoriumBR Jan 15 '17 at 23:39
1

If the focus of the solution is on a mechanism to authenticate a user without collecting any of their personal info (like email id), then using a delegated authentication mechanism is one way to go. For example, OpenID could be used to leverage an external auth server for our authentication needs. This way, we don't have to store any personal information of the user. More information can be found here.

Now, if the focus is to implement an authentication mechanism yourself, and you do not want to use any recovery back-channel (such as email or phone number), then a multi-factor (MFA) option is the way to go - Google Authenticator, sending a push message to your phone app and so on. MFA for a desktop solution could be achieved via a 'soft token'. There are a few well known providers, such as Entrust or AuthAnvil.

  • Thank you for replying. This is close to what I want (I would like to create a backup without collecting data myself). However, would it be posible for the user to create a unique username for my website? – iProgram Dec 16 '16 at 21:14
  • Delegated authentication is typically designed so the application doesn't have to do that. That said, since you are writing the application logic, you could map these OpenID tokens to unique user IDs on your side when you consume them. Bear in mind that this is more of a short-circuit than an intended use case. – katrix Dec 16 '16 at 21:22
  • Additionally, please note that since you are delegating authentication to another entity, "creating a backup" may not serve much purpose, since the actual auth workflow is not done on your side. The most you could do is log user actions etc. – katrix Dec 16 '16 at 21:24
  • So if I want to have a custom username, creating my own login is best? If I dont care about a custom username, then use OpenID? – iProgram Dec 16 '16 at 21:25
  • 1
    What you would store is a piece of information that, in combination with your own application secret key and a few other bits make up the request for the OpenID token. That said, yes - since something has to be stored on your DB side for the mapping, the onus is on you to secure them. – katrix Dec 16 '16 at 21:52
0

The email or phone number is mainly a security in case where the user forget his password. How can you identify whether the guy saying that he has forgotten his password is the true owner or a pirate if you have no second way to join the original user? Secret questions have proven to be either unrememberable by the user or guessable that some one knowing him. For example they were used to gain access to Sarah Palin's email during the campaign of 2012 simply because the answers could be found on internet...

  • Thank you for your reply. I wanted to know this for resetting somones password (as I said that was an issue in my post). I have updated my post to make it clearer. – iProgram Dec 16 '16 at 18:52
0

An option to reset password without an email or phone number from the user may be providing the user a OTP to reset his password generated upon account creation, similar to the ones given in password reset emails. A long enough code with good randomness that makes it imposible to guess, changes once used, and previously used tokens aren't accepted can satisfy your requirement

This solution has two main problems:

  • Doesn't solve the problem when the username is forgotten
  • Has the same problem as non-expiring OTPs for password resets sent through email, if an attacker is able to compromise users computer or gets the token by other meanings then the user is impersonated. And in this case will never recover his account as he has no other way to change the password

If your requirement for privacy is prioritary enough to accept this issues it may be a way to do it

0

We have implemented a password reset solution which helps to reset the password without any network connectivity. Here I am just sharing the idea, not exact logic as it is protected by IP.

The solution consists of a password reset server and a mobile client application. After downloading the application to the smartphone, the user registered to the password reset server and creates a shared secret. The client application is personalized with the shared secrets and this one time activity.

One the website or any other login page, when user clicks on Forgot Password link, password reset API is called. Server responds with a encrypted message in form of QR code, which can be decrypted correctly only by the personalized client app. The decryption logic is written inside the client application which is computed locally, so no network connectivity is required. This decrypted text is used as OTP during password reset.

The shared secret plays the key role here to encrypt the OTP on the server and successfully decrypt on client the device.

Same concept can be extended for account verification also. Now the challenge is to decide the logic which may depend on application design or organisation.

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.