Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am building an Android app - a key part of which will include integration with a server API. The app is just a side-project and I am really just looking for validation of my planned API security and suggestions of best practice and how other apps do it.
The application will be mobile only (to start with, no website) - I want to be able to create user accounts from the app, and once signed up, use the central web API to access/update secured user-specific content.
What I have started looking at is a basic hosted MVC web app (I'm JVM/Spring background, so will likely use those libraries, but the question here is tech agnostic) - the app will have no webpages and just expose a series of endpoints:
Publicly accessible POST endpoints to sign-up & sign-in
OAuth secured endpoints for user specific content (plus of course the normal OAuth dance endpoints needed)
Is that a reasonable approach? Does using OAuth make sense when I have control over the client and server sides?
I assume the official Twitter app just uses OAuth with its API that it exposes to other users? And Instagram was launched as mobile only platform at first, so I assume they must have had in app account creation & then some API security?
(I know there are further considerations/requirements - communication over ssl, protecting your applications oauth key from people de-compiling the application and then using the key in other apps etc, but really I just want some higher-level input if people have implemented these kind of systems before with success/problems etc)
Sounds good, but any token-based sessions would work. Don't store the credentials (at least not the password) on the device. Only store the token, which can be expired, and store it securely. Require HTTPS and use certificate pinning to prevent session hijacking.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
Numerous other questions on S.E ask exactly this same question.
Some of the highest rated questions are closed as Opinion Based, eg Best practice for storing and protecting private API keys in applications
Some best practices are published here:
https://support.google.com/googleapi/answer/6310037?hl=en
In summary:
Do not embed API keys directly in code
Do not store API keys in files inside your application's source tree
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile
apps that need them
(This is not possible if you do not know where the client running on a mobile app will be connecting from using the keys)
Restrict your API keys to be usable only for certain APIs
(When you are not the creator of the API this is not possible)
Delete unneeded API keys
Regenerate your API keys periodically
(Nr 5 and 6 is also not practical for Mobile applications, unless you force the user to Update the app every few days.)
If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.
Relying on obfuscation such as ProGuard or DexGuard does not void #1 or #2 above, so how does one solve this issue?
TL/DR: You don't.
Long answer:
Any key that is distributed with the app can be read by the app for it to use it. The app therefore has what it needs to read the key, even if it is encrypted or obfuscated. An attacker can use the same technique that the app would use, to obtain the key.
Equally, fetching the key form an external source does not protect it. Again an attacker can use the same channel to obtain a copy of the key.
Besides attacking the channel by which the app obtains the key (from an encrypted store inside the package, or from an external source), an attacker can also obtain it from the app's memory or by intercepting network transmissions.
The only secure solution is to never have a copy of the key on the end user device.
The key should be kept on a well secured server which will act as a middle-man between the user's device and the end service. Any requests by the client device to the end service needs to be routed via this server.
The server, having the "global project keys", should make the requests to the end service on the behalf of the end user, and return the result (and never any keys) to the client. For the client to use this server, a per-user authenticated session must be used. The server must validate this session for every request prior to forwarding the request on to the end service.
Summary:
Use a secure server between the client and the end service to make requests on behalf of clients using the global key.
EDIT:
Side note: There is a distinction that needs to be made between per-user keys and keys that are project-wide. It is acceptable to keep keys that are specific to one individual person on that user's device.
Hide that API Key
Relying on obfuscation such as ProGuard or DexGuard does not void #1 or #2 above, so how does one solve this issue?
While ProGuard or DexGuard don't solve the issue they will make it harder, by renaming the name that the API keys is associated with, while if the API key is hidden in native C code the string of it will not be associated with any reference when performing static binary analysis, therefore making it more difficult to extract as I show in my article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
While this solution makes it very difficult to extract the API key with binary analysis, doesn't make it impossible, but easier approaches exist to extract the API key, like by doing a MitM attack as I demo in my article Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
An instrumentation Framework can also be used in conjunction with the MitM attack to bypass certificate pinning when the mobile app is using it. A popular one is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Reverse Proxy Server
If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.
Another common approach to solve the issue of storing API keys in the mobile app code is to delegate the responsibility for accessing Third Party APIs to a Reverse Proxy like I wrote in the article
Using a Reverse Proxy to Protect Third Party APIs:
In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.
Now, this only shifts the issue from protecting the API key for the third party service, like the stock trading API, to protect the API key or any other secret/identifier used to access the Reverse Proxy, but with the advantage that you now have control of how the third party API can be accessed, while keeping the API key to access it out of reach of the mobile app attacker.
Using user authentication to protect access to the Reverse Proxy will limit the scope of the attack, but will not eliminate it, because the Reverse Proxy server needs to be able to distinguish the who from what is doing the request, and in my experience I have seen that developers of any seniority are not often aware of this difference or have a misconception about it.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your backend, be it an API server or a Reverse Proxy server. I will extract here the main takes aways from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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.
So think about the who as the user the Reverse Proxy server will be able to Authenticate and Authorize access to the third party service(stock trading API in your example), and think about the what as the software making that request in behalf of the user.
Hardening the Reverse Proxy Server
If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.
The Reverse Proxy server can be equipped with User Behavior Analytics(UBA) solutions to give it the ability to distinguish from who vs what is doing the request, but this will be done in a best effort basis, based on historical data used by the Artificial Intelligence algorithm to score the probability of being a human or not doing the request, aka the who.
While UBA solutions will reduce significantly the attack surface, it's still a negative identification model, due to the occurrence of false negatives and positives, and will require constant monitoring of the policies/rules being used by the algorithm to strike the best balance between not blocking too many legit users and not letting too many attacks pass by.
A positive identification model can be used instead, by employing the Mobile App Attestation concept as I recommend in this answer I gave to the question How to secure an API REST for mobile app?, on the section A Possible Better Solution.
So, the Mobile App Attestion in a nutshell can be described as a solution that will be able to lock-down, with a very high degree of confidence, the Reverse Proxy server with the mobile app, because the Reverse Proxy server will now be able to only accept requests from what it expects, aka genuine and untampered versions of the mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We're checking out Auth Providers and was wondering how FusionAuth compares to the others?
First of, FusionAuth is free. Developers can use it for any application and even deploy to production with any number of users. All of the features of FusionAuth are available for free as well.
FusionAuth provides all of the core features that an identity provider must provide. These include registration, login, SSO, MFA, password hashing, password constraints, password reset, email templates, OAuth, OpenID Connect and others. In addition to the core features, FusionAuth also provides localization features, reporting, analytics, user segmentation, user search and a user management UI.
FusionAuth is single-tenant and downloadable. You can download it to your dev box, deploy it on a bare-metal server, run it in any cloud or deploy it to Docker. This provides a lot flexibility and FusionAuth (the company) can host it for you in an AWS private cloud if you need.
Finally, FusionAuth is built to scale. You can spin up new instances of it to handle large login volumes (because password hashing is expensive). We've tested it with a few hundred million users and it performs nicely.
Here's a quick example of just one of the numerous of APIs that FusionAuth provides.
$ curl -H'Content-Type: application/json' \
-d'{"loginId":"test#fusionauth.io", "password":"password"}' \
https://localhost:9011/api/login
This is the Login API and you can find the full documentation here: https://fusionauth.io/docs/v1/tech/apis/login
There are comparison docs to other common solutions like Auth0 here.
https://fusionauth.io/blog/2018/10/19/auth0-and-fusionauth-a-tale-of-two-solutions
At the bottom are links to comparisons to Active Directory, Cognito, Firebase, Ping Identity, Okta, and OneLogin.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm working on a webapp that requires user account management and authentication. The users should be able to login to their account using different tokens - Email, Phone Number, Facebook id, Company account id etc. Same user might be using all of these different methods based on the entry point they choose to login.
From the backend, I should be able to retrieve the correct user account based on any of these tokens. Basically, multiple tokens (email, phone, facebook etc) should point to the same user account.
I have been looking into Firebase and Stormpath. From your experience, do you think Firebase or Stormpath are good options for me? I was wondering if there are good pre-build web solutions for this without re-inventing the wheel by myself.
Please feel free to suggest different web solutions and architecture tips.
Thanks for your time,
Iranga
Disclaimer: I work at Stormpath
Firebase is a platform/ecosystem for building web/mobile applications, and as such they offer an authentication and authorization solution. Building your app with them will require buy-in to their entire platform.
Stormpath is an authentication and authorization service that can be added to any type of application, regardless of where it is ran, where it is hosted, or what your fronted of backend is written in. Our API does allow you to manually link different types of accounts together, e.g. password-based accounts or social accounts. See Modeling Your User Base in our documentation.
We’re adding some support to make this easier and you can follow the Account Linking feature to know when this is available.
In sum: if you want an entire platform for your application, Firebase may be a good fit. If you prefer to maintain more control over your hosting (such as using Heroku to deploy your Nodejs application and have Postgres available), then Stormpath would be the better fit.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Internal to our work group we have a number of services running on our web server including build service, wiki, bug tracker, and some homegrown apps. Currently these all require seperate logins for each service.
The main choice i see to centralize user creation between all these services is LDAP, however i am not interested in doing the full enterprise system, attaching logins and shared directories etc all I want is a way of centralizing users in web services.
From playing with openLDAP this seems complete overkill and is a pain to set up. Is there a simpler method, perhaps speaking LDAP protocol or some other way of centralizing authentication without having to hack up custom external authentication scripts for my services?
A centralized authentication store accessed via LDAP is exactly the solution for which you seek. LDAP is
a small protocol from a wire perspective
most available LDAP servers are extremely fast
the protocol and implemented servers are simple
easy to understand
easy to administrate
easily securable
Add replication for redundancy and increased aggregate throughput and it is hard to imagine a better solution.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 10 days ago.
Improve this question
I've been doing a lot of studying and work recently related to WCF, web services and distributed computing in general, but most of the security concepts go over my head. Transport security, message security, encryption, certificates, etc. I understand the basics of symmetric and asymmetric encryption, but I don't really understand the real world application of them in a SOAP conversation.
I'd read the specs, but they seem a bit dense. Can anyone point me to resources that start with the basics and work up from there? I'm tempted to fish out the textbook from my networking course in college to get a better understanding of what's happening at the lowest level, but I don't know if this is massively inefficient or not. I'd prefer not to have to read a small library full of stuff - I just want to solidly grok the concepts and be able to explain them to the rubber duck on my desk.
Edit:
It's been several years since I first wrote the answer and the list is getting old. There have been some wide adoption of web-enabled APIs and token-based trust relaying.
I haven't read it, but Windows Communication Foundation Security would be a good place to start, if you're looking for something specific to WCF.
Also keep your eyes open for what major players like Facebook, Google, and Twitter are doing. They are using open protocols like OpenID and OAuth. At first, OAuth looks complicated, but you should understand the mechanism.
In my opinion earlier OAuth reinvents a lot of wheels that SSL has already solved, and leaves some security holes open. An interesting read is Compromising Twitter's OAuth security system. Facebook's OAuth 2.0 implementation and Google's OAuth 2.0 implementation simplify many of these issues by using https where it makes sense. These are must reads.
The basic concept around OAuth is trust relaying. You would want third-party developers to make apps against your API, but the end users cannot always trust these apps. Giving password to them, is like giving the keys to the kingdom. So the user types in the password into your UI, and your UI redirects to the third party with an access token.
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication is a good introduction to ASP.NET's security models. You can skip over the details because much of the technology is now obsolete.
A good overview specific to Web Services is Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. It says WSE, but basic concepts still remain the same.
To get more details on WS-Security, read Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption.
After reading above, what really helped me was looking at existing implementations like Amazon S3's authentication:
Amazon S3's authentication http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif
Flickr Authentication API:
Each authentication frob is specific
to a user and an application's api
key, and can only be used with that
key.
Authentication frobs are valid for 60
minutes from the time it is created,
or until the application calls
flickr.auth.getToken, whichever is
sooner.
Only one authentication frob per
application per user will be valid at
any one time. Applications must deal
with expired and invalid
authentication frobs and know how to
renew them.
Twitter REST API
Many Twitter API methods require
authentication. All responses are
relative to the context of the
authenticating user. For example, an
attempt to retrieve information on a
protected user who is not friends with
the requesting user will fail.
For
the time being, HTTP Basic
Authentication is the only supported
authentication scheme. When
authenticating via Basic Auth, use
your registered username or email
address as the username component.
Session cookies and parameter-based
login are known to work but are not
officially supported.
The OAuth
token-based authentication scheme will
shortly be offered as an experimental
beta release.
So it's nice to know the complicated certs and PKI stuff, but the world seems to operate without it just fine.
Additionally, there's also the WCF Security Guidance by Microsoft's Patterns & Practices group. Check it out.
Marc
Start with searching wikipedia for Public Key Infrastructure (PKI) and follow the links to understand the different pieces. You don't need to know the encryption algorithims for the various ciphers, but you do need to understand the concepts if you want to really understand how WCF uses it.