We have a server with services and client side mobile app (Android, iOS). User authenticates with username/password but what about app itself? I want to limit access to server just to my app and I don't want to involve user in it, I want to keep it separated from user login process.
First idea is to keep some kind of key, password, certificate or the like in app (and use it to encrypt random challenges from server) but because it's hardcoded it can be taken out from code and used by some other app.
If phone has some security storage to keep certificate, password for accessing it will be kept in app so again it can be digged out.
You can have a database of "trusted" app devices and link that to your user or device database (a.k.a. who's using who). You can try the one-time password approach (behind the scenes with the app code) and authenticate every time the user interacts with the app.
I also agree that everything (hardcoded / stored) in the device may be obtained so time-based solutions may be effective in reducing attempts to do unauthorized actions.
Related
We have an application with a script that create a conceptual model and a login role in a PostgreSQL database.
This login role will be used by the application for everything, independent of the logged application user.
How can we protect this login role password inside the application code?
Consider using a yaml file to store your credentials or alternatively place them in a .pgpass file.
The main three authentication mechanisms you could use, roughly in order of popularity, are:
Password. Here you somehow load a password in your application, and use it whenever you connect to the database. One easy way to store the password is in a text file protected by filesystem permissions (similar to how you protect SSH private keys).
LDAP. This requires an LDAP server on your network, but that is commonplace in corporate environments. It also requires loading a password in your application. The difference from the regular password mechanism is that the database server doesn't store the credentials or verify the password directly--it delegates these to the LDAP server.
Kerberos. This requires a Kerberos server on your network. Here, the application does not need to load a password; instead the user (or service account) which will run the application must first authenticate using Kerberos (either by typing in a password to kinit, or loading a credential file).
Of these, my personal preference would be Kerberos if that service is supported on the network in question. Second best would be LDAP, because it allows centralized control over things like password changes and revocation. And third would be the regular password mechanism, which works in any environment.
Details on all of the available mechanisms are here: https://www.postgresql.org/docs/10/static/auth-methods.html
You cannot.
If the user has a direct access to the application (they can directly launch it) everything that is hardcoded in the application should be seen as accessible to the user. Whatever obfuscation you can use, a determinated attacker will be able to find it (through decompilers an debuggers).
If a break point exist, all is different:
front end application back end application
launched by user --/--> launched with a sytem user
local machine local or remote machine
This is typically the use case for web applications: the user has no access to the application code, and does not launch it, so the database password can lie in a configuration file - it will always be accessible to administrators. Even when all runs on the same machine, decent OS allows for access protection to prevent unprivileged users any access to the backend program. For that latter case, the front end and backend can communicate through sockets, named pipes, messages or almost any other IPC mechanism.
TL/DR: only secure way:
split the application into a front end running under user account with no knowledge of the database server, and a back end running under a system (non admin) user
ensure that normal users have no access to the backend application files
store the database password in a configuration file of the backend (never in a source file)
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
So I want to do the following:
A person registers online and selects their login and password for a desktop and web application (same login and password for both applications)
They then download the desktop application (written in C++ with Qt as it's cross platform)
Then the login and password is automatically passed to the desktop application without the person needing to enter this data. The login and password is used to authenticate with the server.
Each version of the desktop application needs to be individually coded with the person's login and password based on the fact that they signed up on the web page.
So here is a more simple explanation:
1. The user signs up on the web site and choose login\password
2. The user download desktop client on his computer
3. The user runs desktop client (C++ binary) and it asks for a login/password from the step
I would like that software fill in login/password automatically on step 3 for the first time. Is it possible? How would it be done without security risks?
The main problem is, that anyone could execute the program and gain access to a user account. I would suggest using a one-time login for first authentification with random tokens and after the first start, get the user/password information through an ssl-connection. After that delete your one-time login token and replace it with the actual login.
I don't really know whether you're asking for precise code examples or just want to have a basic concept... But anyway, storing login-data in the application itself is a security risk.
Have you look at HTTP Authentication?
I do not fully understand the download process of the QT app, but, if you use a Basic/Digest Authentication on your web server, propagating the authenticate token will be easy and safe.
Basic use a 64 base encoding, Digest a MD5 hashing. A lot of library implements those steps out there (Spring Security and Shiro in the Java world).
I saw two ways:
the server can provide a user with unique link for downloading installation package. The server patches that package by unique one-time password. So client will be able to login for a first time
the browser collects some information about a user's computer. For example, IP, MAC, OS Version, etc. Then it calulate digital sign of the computer based on these data. The C++ binary do the same. You can use that digital sign as one-time password.
I am building an application that has a web front end and a desktop client application. The web front end allows users to login using Facebook. It exposes a web service to the Desktop application for uploading data. The web service needs to insure that the desktop application uploading data for a user is really from that user. I have already implemented Facebook login on both the client and web interface using the Graph API. How would I go about using Facebook to validate that the user using the desktop application is who they say they are? Also, how can I make it so the user can login once and not need to login again on the desktop application?
After much struggle I figured out that it's possible to receive a session key that does not expire. You can do this by requesting offline access to a user's profile. I stored this in the database on the web side and retrieved and stored it on the desktop side. The only problem is the session key technically can be viewed and used by someone other than the user to make requests. Any other suggestion would be appreciated.
I want to upload a file to a website via a desktop app and then take the user to the website. The website has a web service, but requires authentication as does the web site. Is there a way to do this without forcing the user to authenticate twice (once in the desktop app and once in the web browser)?
Unfortunately, you can't prefill an input of type file for security reasons, which makes sense since the user won't want you uploading arbitrary files from his/her computer. But if they have a desktop app, is there some way around this?
Or maybe make the user log into the web app first and then the authentication cookie can be reused?
Any other ideas?
Thanks,
Ben
I would use the dekstop app as a client to the website app via an api.
So, login via the desktop app. The api returns a authentication token (as Carlos suggested) which might be a md5 hash stored in your database for a certain period of time, possibly matched to the clients ip address.
The desktop app can then make calls on the api (like uploading a file) as a authenticated user (by using the auth token).
When loading the website, perhaps the url is http://website/login/{auth_token} where the auth token is added to the url. The api can check to see if its a valid auth token and consider the user logged in.
You could generate an authentication token that could later be used on the website.
It all depends on the type of authentication of the service and the site. Is it integrated Kerberos, WS-Auth, is it Basic/Digest HTTP, is it forms/cookie ?
This answer will most likely not work in the very general users-on-the-wide-open-web scenario, but in intranet contexts, using Windows Authentication (on an ASP .Net solution), would provide this.