I'm trying to add OTP functionality for sign in, in my android app. I'm using node.js for the backend. Now, first I thought about generating random numbers like math.random().
I can easily generate PTPs on my server side and I will store them in my MongoDB datastore then I'll match them when user enter the OTP, but now I came across these prebuild modules for OTP this one Speakeasy https://www.npmjs.com/package/speakeasy.
There are two types of methods HOTP/TOTP. I am asking why would anyone use these two and just not using random numbers.I mean what are the use of HOTP/TOTP? If anybody has designed OTP functionality in any app/website please enlighten me.
UPDATE
What is the general way of OTP authentication on any android device from the server I mean apps like zomato, Airbnb how do they do OTP verification of the user?
These OTPs prove "I am in possession of this device that generates OTPs."
In the broadest sense, it could be a statement involving a device that doesn't even have Internet access. HOTP and TOTP are algorithms that you can use offline. Both the device and the server generate the code independently:
code = f(shared secret, common info)
That shared secret only has to be set up once, e.g. by being baked into a hardware dongle or scanned in a QR code when you set up two-factor authentication. The common info is something that both the server and the dongle can determine each time you log in, e.g. the number of times you've logged in before or the current time and date.
Using an actual random number would require your service to deliver that random number to the device. Which if you're developing for an audience that has smartphones, isn't too wild of an idea. Google's two-factor authentication, for example, supports sending a notification to your phone and you just click a button to allow the login.
One more thing, a practical consideration: using an existing scheme like TOTP makes it easier for anyone trying to reason about how secure the system is. If they already understand TOTP, they can move on to examining other parts of the system you're building.
Related
Currently I'm working on the MQTT based Chat application where I need to assign
Unique Topics to Users dynamically.
So, I thought of using their IMEI/MobileNumber. But in iOS, we cannot get the IMEI Number so we thought of generating a random IMEI from the backend and assign it to the Users.
Now, My problem is whenever user changes his mobile, the IMEI Number changes and it will be fresh profile again to that user.
If I use based on his Mobile Number, there is a chance when the user doesn't use the sim for 3 months. The connection automatically terminates from the network provider and the same number will be assigned to another new customer(atleast here in india).
Can anyone suggest me a good approach for the Topic Generation?
BTW, I need a Web Chat also and that need to be fetched from database. that is the only reason, I'm focusing on the Topic Generation. So, I will fetch messages based on his topic and show them in the Web Chat.
Do anyone know, how whatsapp maintained their topics?
I thought of using their IMEI/MobileNumber.
Bad design. Have the user create an account (i.e. email) with a password for your service that way no matter what phone or phone number they have, they can still log in and use your app. And make sure you ENCRYPT the user credentials in your database. Start FIRST by building an app with proper security or else you will be hacked 5 minutes after you launch it.
Do anyone know, how whatsapp maintained their topics?
Just because Zuckerberg copies everyone else, doesn't mean you need to copy them. Also, I believe whatsapp created there own version of a MQTT Broker. Hence, it will have an entirely different set of functionality from a regular MQTT Broker.
I am making an app and I want to know the overall jist to make it so you can sign in with your phone number. For example, in the app Down to Lunch (an app to invite your friends to get food), once you download it, the first thing you do is sign in with your phone number. From then on, your number is how you are identified in the app. What I want to know is once you submit that number, is it added to a table in a database? Then when a new user registers, that number must go through and check against every number in that table to make sure it is different? If so, wouldn't that take long for a large user base (like a social network) or is that just what databases are capable of doing? (more specifically amazon web services, because I would use their relational database service, im guessing)
You can use library called DIGITS and which is available on Fabric
Digits lets people create an account or sign into your app using nothing but their phone number on iOS and Android. Built using the same global, reliable infrastructure Twitter uses, Digits will verify the user’s phone number with a simple customizable user interface that easily integrates into your app.
Refer below links:
DIGITS - Sign in with Phone Number
How to configure to app
Technical answer
Facebook, Twitter and Truecaller provide free SDKs which you can include in your app to provide phone number based login into your app. What these SDK do is to authenticate an entered phone number (via OTP verification) and nothing more. Hence you can have a phone number OTP verification gateway as soon as user start your app. Using any one of these SDKs, you can know if the phone number verification happened successfully or not. From here on, you have the control of the application. You will be handling user base. You will keep track of user profile, friends, redundancy check (returning user check), etc.
Business answer
For developing something humongous like a social network, you would want to segregate user ids from the start. You would also want to study more on computer science subjects like Data Structure. Obviously, you can never develop a perfect application. Even if you try doing so upfront, there's a greater chance that new technologies have come up and your perfect solution isn't perfect anymore -- within 2 months. Hence, implement a feasible solution first, which is a perfect tradeoff between perfection and time remaining for your case and your predictive growth.
Important links
Phone number OTP verification services:
Twitter Fabric Digits: https://get.digits.com/
Facebook's OTP verification: https://developers.facebook.com/docs/accountkit
Truecaller: https://www.truecaller.com/developer
I am making a webapp which will coordinate with an iOS and Android application. There will be a two types of accounts. One will be primarily on the website and the other will be primarily on the Android or iOS app. This question may be too broad, but I'm looking for an authentication pattern which will work for this setup and make sure that the right web account is pairing with the right mobile account. Here's what I've got so far and am hoping you can provide some feedback...
When a mobile app is installed, it will reach out to the server with information such as name and phone number to which a UUID will be returned.
If the web account wants to link with a mobile account, the web account must enter the phone number of the mobile app they want to link to. The server then sends a message to the mobile device so that user can confirm the pairing.
Are there drawbacks to basing the account id on a phone number? Is there a better way to do such two factor authentication? Sorry if this is too vague or undirected and thanks for any help!
Phone number is a bad UUID because there is no way to get the phone number. Other than asking the user. Not reliably. Also, some devices allow dual sims (home and work) and thus would have multiple phone numbers.
A better way is to use the android device id. But even that isn't that great- I could write an app that calls your service with whatever id I want. There's a reason RSA keys use a cryptographic token that changes every minute- it requires you not only to know the id, but to know what the id is now. Otherwise you'd just need to have found out the secret id once and you're in for life.
Hello I am developing an application that will exchange unique groups and messages belonging to them between peers within a local network without any servers. Each of the peers should be able to create a new message and associate it with an existing or new group. Since messages and groups should be unique I have implemented a hash algorithm creating the ID of those messages from static values like, content, date of creation, author, title (messages are not editable). The ID I am using is helping me check the integrity and possible duplicate when the message/group is sent to another device. But since there is no server to store accounts and check for credibility of each of the peers I cant think of a way to implement a mechanism that will check whether a given message is genuine from a specific author. At the moment anyone can publish messages adding a false author name, which is something I want to resolve. How can I do that?
PS. My application might be similiar to how Twitter works but it has no accounts and no main servers to store them. It is developed on android and it cannot use the internet simply because it is using wifi to connect to LAN only routers and I wouldn't want the users to have to use 3G/edge.
Possible solutions:
Use the phone's special ID (IMEI) , but also how do I get that programatically and is it really unique?
Use MAC Address of the phone (actually hashed concatanation of Bluetooth and WiFi MAC Address), is that unique per phone?
The problem with this and the above is that the genuine author might change his phone over time.
If the genuine author has logged on with his Google Account previously is it stored in the phone's memory and can I programatically get this information in offline mode?
The use of Digital Certificates to sign messages could also be a solution. Although its use may raise some more questions like "Who's the issuer?". Well, it could be an "entity" created by you if the authenticity of the messages are only important inside your own application.
Just something to consider if you haven't already.
I don't think you can do anything about a false name, but in most cases fake names are okay - what you want to protect against is one user posing as another. Digital signatures would be the way to go - ensure that everyone has a randomly-generated secret they can use to sign all their communications.
For mobile-based comms, you could go one step further and get people to certify they know another person, using short-range communications. For example your app could do a Bluetooth exchange with another phone, and that would modify each profile to say "trusted person X certifies they have met untrusted person Y". Since it would require the consent of both parties, if one party is trusted, the other one likely can be too. The short-range comms would ensure that the parties have met (and perhaps are certifying that a person is like their profile picture).
You could also do a similar thing to Gravatar - use a hash of the name and the secret to choose from a wide range of avatars (or, generate a random image using a very long hash). This way, two people posting under the same handle will have very different avatars, and they can easily be told apart by the user community.
I'm looking for suggestions for ways to share Android app data between phones running the same app. For example, lets say I have an app that stores a database of book reviews. If person A has a book review that person B doesn't have, what are the options for getting that information from person A's phone to person B's phone?
Currently, I'm aware of the following options:
- Upload data from person A's phone to a server, then download data from server to Person B's phone.
- Write code to have the phones sync up using bluetooth
- Write code to send SMS messages
I'm wondering if there are any more options besides these, and if there's actually a best-practice for accomplishing this?
Ideally, I want the users to simply click a button in the app to make the sharing take place, so I don't want to go down the bluetooth route because that requires the user to do a bit of setup (or assumes they already have set things up in the form of bluetooth settings).
Since the data can be of variable length and potentially large, I believe that would rule out text messaging.
As far as the server route goes, from what I understand this seems to be an ok way of doing things, but my problem is that I have no experience with having users potentially sign in to a server and then uploading data. I don't know of the cost concerns (if any), or of potential security concerns (allowing just anyone to upload data, I'm not sure if I would have to take steps to ensure someone couldn't bypass the app and upload malicious data).
So, can you guys give me suggestions and point me in the right direction? Thanks.
I'm wondering if there are any more options besides these
You could try generating a QR code and scanning it on the other phone. Beyond that, I think you have it mostly covered.
and if there's actually a best-practice for accomplishing this?
That is impossible to answer in the abstract.
Keep the database server side and interface with it via a web service
I too am looking for a solution to this very problem. I'll throw it out there that a fourth, or rather extension of your first option, is to use the Cloud to Device Messaging Framework, though it still requires (as best I can tell) having your own server, though I suppose you wouldn't need to store the database server-side longer than it takes to send the message, provided you keep it under 1024b (or whatever the actual size is).
I don't believe there is a convenient way to monitor/send email in the background. If I could have my app monitor email messages looking for a key subject, then parsing the body, I could probably accomplish what I'm looking for using email as the transport.
The problem with maintaining a server, is that you probably would need to build in a subscription fee to your app to cover the costs of maintaining a server, as one time sales may not be able to cover the ongoing expense.