FAQ: Frequently Asked Questions

I used Simply Sign In's authentication using an SMS from my phone. But it always times out! or it tells the time has slipped away Did you check your SMS in your phone? Most telephone networks will tell you if an SMS has been delivered from your phone. Also, while delivering the SMS it will give some indication of the SMS being sent (e.g. by displaying a spinning wheel, etc.) In some situations, the SMS being delivered may take too much time. Simply Sign In waits only for around 3 minutes to receive the SMS. So the short answer is to try again. Refresh the initial page. Make sure that the TOTP displayed is different from what you had seen last. If the TOTP had not yet changed, there is a chance the same error would repeat. Another reason for failure is when someone is attempting to send an SMS from a virtual phone number or a phone number which is NOT recognized as a mobile phone. Such messages are silently discarded by our SMS receiving server. A third reason is that the merchant may have implemented their own SMS receiving server. In such a case there may be a glitch in their SMS receiving server. Let us know which merchant's website you were trying to access -- and we'll inform them.

I used Simply Sign In's authentication using the email route. But it always times out! Currently Simply Sign In registration via emails are only allowed for business domain names. We do not accept registrations being done via free email addresses such as gmail, hotmail or from disposable email services. Note this is the explanation for our own registrations, as we know how our email receiving server works. If you were trying to get authenticated at some other merchant's site; then there is a chance that there is a glitch in their email receiving server. Let us know which merchant's website you were trying to access and we'll inform them.

Does this do authorization of data of the user? No. Simply Sign In is just a facilitator for only the authentication of any user at a participating merchant's website. It is NOT for transferring any information about the user itself. If a merchant uses our Simply Sign In fully; including our SMS receiving server, the merchant will not even get the phone number of the user. Simply Sign In just tells the participating merchant: "this particular unique user is now authentically wanting to use your system". Nothing more.

How do I know that my phone number is not passed on to the merchant I registered with? After all, I do send an SMS, right? True. When you send an SMS to our receiving server, that server would momentarily know your phone number. However, it is never stored anywhere and instead we create a SHA256 hash of the phone number and it is that hash (also called a "proxy" in these docs) which gets passed onto the merchant. Do not believe us? You can create a merchant account and try it out. We give some free credits for everyone who signs up. It is quite trivial to a mid-level programmer to write the code which will receive the data from us. Still do not believe us? If you are willing to deposit an amount of $1000 USD, and sign an NDA; we will give you a guided tour of our live server code. We'll return the deposit back to you after the tour. (after deducting a small $100 fee which also covers all payment-gateway and exchange charges we incurred) Why is the SMS that is to be sent so obtuse? Or: Why can't I just text the word "REGISTER" or something equally simple? We know typing the SMS takes a few seconds more and typos are simply not accepted. But all that is for your safety.

There is an important reason for the format of the SMS. Firstly, it contains a special 6 digit number -- which is time sensitive. It acts like a "captcha" too -- we know it was a human typing that. It is unique for each access. So a hacker cannot copy what was sent earlier from the message list and reuse the same again. Then, this kind of SMS handles situations where the user had left the phone unattended for a few minutes. In that period, someone should not pick up the phone and let himself enter one of your website. If the SMS to be sent was too simple; then the hacker can do this quickly. But in our case, the hacker would have to first visit the site where the user has an account, obtain the actual SMS message which has to be sent, and then type that message. All that would take time. By that time, its quite likely the actual user is back on his/her table and reaching for his/her phone. How do I change my password? The Simply Sign In authentication process itself does not use passwords at all. It just identifies that there is a unique user here who wants to use that merchant's website. However, each merchant's website can then decide to ask the user to set a username and password for himself/herself. If that be the case, the merchant would then have a separate login page; and in that login page you can expect to see a "forgot password" link as per the merchant's implementation. But all this additional implementation is left to the participating merchant. If you are taking an account of Simply Sign In itself, you would notice that we always would want new merchants as well as existing merchants to enter our website using the password-less route. We believe passwords are a big headache for everyone. But that's just us. We don't tell merchants registered with us also to do the same.

What if I change my phone number? We strongly suggest that you should contact all the merchants where you had used Simply Sign In and inform them to suspend your account (or protect it) ... BEFORE you switch over to a phone number. All merchants that use our system has been told to implement this temporary protection system. If they have followed our instruction, and you were able to suspend your account at those websites; then you are guaranteed that your old phone number (which you discarded) will not be used by someone else to get into your account. There is a possibility that when a person discards an old phone number; it is then given by the Telecom provider to another party later on. We think this is rare; but we have no statistics about this. We know this can happen. Can someone enter a website which has implemented Simply Sign In; one where I have registered, without me knowing about it?

No. This is impossible if the merchant is using our fully password-less solution. The reason being, that other person would necessarily need to send an SMS using your phone only; in order to access your account. It is extremely rare for even the most astute of hackers to spoof the sender phone number (explained in detail in the documentation) so that outside person has no way to convince Simply Sign In that he/she sent the SMS thru your phone. Having said that, there may be some merchants who decide to use Simply Sign In only for the registration of new accounts. Once the user enters such a website for the first time, the merchant would then ask the user to set a username and password for the account. Just so that the next time, the user signs-in using that username and password instead of using Simply Sign In.

In such specific cases, if there is a possibility that your username + password happens to be leaked out to someone else; then yes that person would get access to your account at that merchant's website; without your knowledge.

But that is the danger in all systems that asks the user to set a username + password; isn't it?

I started entering a website which uses Simply Sign In and gave my phone number on the entry page. The countdown started. But then I had to move away (for a toilet break) Will someone else get into my account, because the browser happened to be open with the details of the SMS there? If the phone is with you nothing untoward will happen. If you had forgotten to take your phone when you went to the toilet, there is a chance that someone else can use your phone (if it is unlocked) to type in the SMS and get into the website. Typing out the SMS does take a bit of care but; if it was displayed to all and sundry, typing it out wont be difficult. If the entry page was on your mobile itself; then it is even more easier: The hacker has to just copy paste it into the SMS application and send it off. We hope you will take care about where you leave your phone. Having said that; what will the hacker do after getting into that website; in those few minutes? You are returning back to your table, aren't you?

Can the merchant himself access the account of an account holder using Simply Sign In? If the merchant wants to enter an account holder's account; why would he want to hack into it via Simply Sign In? He already has the data of the user, and he can anyway examine the data inside all his accounts, no? Of course there are merchants who have developed end-to-end encrypted accounts where the account holder encrypts data before it reaches the merchant's server. Those companies are truly trying to protect their users. BTW, there also companies who claim they are doing end-to-end encryption but actually do not. But to get into discussing here the protection of data in someone else's system is not in our scope or responsibility.

I am a merchant. Can this work along with OAuth etc.? Simply Sign In only helps merchant website identify unique users. We do not store any user data at all. It is possible for a merchant to use Simply Sign In for registration and at the same time use OAuth to pick up the user's data from some other site which releases user information via OAuth.

For example; the user may already have their personal data at say; Facebook. Instead of typing that all again, the merchant's website can be programmed to pull in the data from the same user's Facebook account after registration. In fact the true use of OAuth was to authorize the use of user data in such a manner. It is really not good for authentication. But for simplicity's sake, many merchants use OAuth to do both authentication of the unique user as well as authorization of use of the user data. And there is a conceptual problem there... On similar lines, a merchant who uses our system can later on also implement OAuth for sending out data in that merchant's website which the user authorizes to other websites -- one that connects to the merchant via OAuth. All such use cases are beyond our scope.