CTAP2 allows apps on mobile phones to act as roaming authenticators. An app may implement the protocol over one or more of the supported transports.
However, there are use cases where the web or native app being accessed would be run on the same mobile device as the roaming authenticator. Can this use case be supported by CTAP2?
PS: Why is there no ctap or ctap2 tag? I used 'fido' as a proxy.
However, there are use cases where the web or native app being accessed would be run on the same mobile device as the roaming authenticator. Can this use case be supported by CTAP2?
CTAP defines a protocol that is used between devices. For apps to provide credentials on the same device, the OS of that device would need to support them plugging into the standard APIs.
We (Google) said yesterday, “Please stay tuned for more updates from us in the next year as we introduce changes to Android, enabling third party credential managers to support passkeys for their users.” But I believe that's the most that any of the platforms have said on this point so far.
I am working on an android and iOS application that needs to have a password-less solution for login. We are trying to implement WebAuthn/Fido2 device.
The problem is that Fido is still new and there is no React-Native library that implements that. So I have a few questions regarding it.
Can we read and write our own key in the Fido2 device?
=> Till we get a proper library, I want to store an encrypted password on the fido2 device as a key, read it every time on login, and decrypt it. Is it sounds good to implement and is it possible to do?
#DevPy
To support WebAuthn/FIDO2 from your React Native iOS application, the recommended solution is to integrate one of two Apple iOS system browsers (ASWebAuthenticationSession or SFSafariViewController) that support WebAuthn APIs. ASWebAuthenticationSession would be my first choice as this browser is for authentication through a web service, specifically the OAuth 2 flow. This provides the interface, built-in APIs for interacting with the FIDO2 authenticator, like the YubiKey, and gives the developer control with callback to the session and authentication token. Another way to integrate WebAuthn is to utilize a third-party SDK for communicating with OAuth 2 providers. For example, AppAuth for iOS has a React Native bridge, available here. I believe the AppAuth SDK uses the ASWebAuthenticationSession.
As for the initial question of writing/reading your own custom key, the FIDO2 devices are limited in storage space but the YubiKey offers two options that may work for you. One is the option to create a static password (not encrypted) or utilize the Yubico OTP. Both options use the system keyboard to type out the password or OTP into any text/password field within your app. No SDK or system browser required.
FIDO2/WebAuthn is specifically a browser API. Since you're talking about authentication within a (React) native app then you'll probably want to fall back to equivalent native OS API's instead.
For Android you can use the Fido2ApiClient, which will let you leverage existing FIDO2 credentials on your server for in-app authentication:
https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/Fido2ApiClient
I think the equivalent on the iOS side of native app development is Authentication Service. They have a page specifically about leveraging "passkeys" in your app that will probably help get you started:
https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication
I am using the Goodreads api to get book data for my react native app. I have to use a key for using the api. Is it OK for me to store the api key on the app itself or should I put the key on a server that redirects all the data to the app?
Is it OK for me to store the api key on the app itself
No, because as I demonstrate in the article How to Extract an API Key from a Mobile App by Static binary analysis it can be extracted with the help of several open source tools, like by using the Mobile Security Framework, but you can also grab the API key with a MitM attack, as I show in the article Steal that API Key with a Man in the Middle Attack, that uses the open source tool MiTM Proxy.
If you leave a third party API key in the mobile app, then they are up for grabs from attackers, and when they start using it without your knowledge your bill in the third party provider may go through the roof before you acknowledge that something is wrong, and on that time the only solution is to revoke the API key, thus shutting down the use of the mobile app, and if you make a new release of your mobile app with a new API key it will be just a matter of hours until the attacker come back and steal the API key again.
or should I put the key on a server that redirects all the data to the app?
Yes, and this is a good approach, because now you have only one place to store and protect all third part API keys. This have the benefit to let you control and throttle the use of them as you see fit.
With this solution you still need an API key in your mobile app to allow access to your API server, but while you continue vulnerable for attackers to steal it, you are now in direct control of throttling the access to your API server and if you identify in each access the WHO and the WHAT is accessing the API server, then you have a more fine grade control, but attacker will continue to be able to slip between all our defenses, because is very hard to know WHAT is accessing the API server.
You may be thinking by now... do you mind to explain the WHO vs the WHAT?
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
Your problem is not solved yet
Now that you know the difference between WHO and WHAT is accessing your API server you must have realized that your API server is still vulnerable to be abused by attackers.
You can resort now to employ several layers of defense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by using a Mobile App Attestation solution that guarantees to the API server that the requests can be trusted without the possibility of false positives.
Mobile App Attestation
Use a Mobile App Attestation solution to enable the API server to know is receiving only requests from a genuine mobile app.
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
Summary
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a backend under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
For react native use react-native-config library. While using this library you can secure your api keys as well as you can save more secret keys which use in the native code. Like we can save onesignal, codepush etc keys.
https://github.com/luggit/react-native-config
Store them in a .env file like this API_KEY=yourKey.
Install npm package react-native-dotenv.
Then import to to files as needed with react-native-dotenv package;
import { API_KEY } from 'react-native-dotenv'
The .env file should never be committed to Github.
i'm building a website that uses WebRTC to share audio and video. Now i'd like to access WebRTC features on Android devices so i can create an app that can receives audio and video streams from the website.
I've looked for a technology allowing me to do that and I've found SkylinkJS.
It looks great but i'm wondering something. Can i build a custom authentication system on top of SkylinkJS logic. What i mean is that i'd like to make sure the connection to SkylinkJS rooms are initiated by users actually authenticated on my platform.
At the moment, i do that using socket.io but i can do it since i'm using raw WebRTC. How can i do that using SkylinkJS? Using the REST API?
Thanks.
PS: i cannot tag this question with 'skylinkjs' since it's a new tag, but it mights be cool if someone could do it.
Yes you can integrate that with the REST API in this Applications REST API link here - . You can generate your own credentials.
You can generate the connecting credentials from your server and then when the User logs in, generate the credentials for Users to connect to the Room. See more in their support article.
SkylinkJS uses key based authentication mechanism to authenticate against the Temasys signaling servers. This ensures that any application using Skylink can only connect to calls in your application if the app can provide the same secure keys (from your Temasys developer account).
Your best bet in looping in Android would be to use the android counterpart. http://skylink.io/android/
This questions does not pertain to a specific OS (iOS, Android, WP8), but is about programming in general.
I have an app on a mobile device, that requests information from my web server. I want to ensure that my server returns data only to MY app, and not to third party apps.
Here is what I have so far:
Solution: Have the app encrypt the requested data, and use a nonce and timestamp to prevent replay attacks. Connect to the server using HTTPS, to prevent eavesdropping on the returned data.
Problem: The encryption key used by the app will have to be stored in the app, which presents a problem itself, since it can be extracted from the app.
How have other people solved this problem?