I'm developing a simple iPhone app where users register, and sign in with their email/password. These values are stored in a remote database.
I'm using Cloudant to store this information (CouchDB is great), and have granted read-only privileges to a new user (created API key/pass). In order to communicate with Cloudant, you obviously need a URL to access it (eg https://user:pass#db.cloudant.com), which is stored in the app as a string.
Now, while I know this is pretty unsafe, I can't think of any other alternatives in order to keep the db URL safe (specifically the username/password for it). I've seen people talk about using another server to proxy through to obtain the credentials, but it seems a little awkward.
Any help or thoughts would be really appreciated!
Are you trying to make a connection from your iPhone app directly to the database? You shouldn't give your app read access to the whole remote user table / database. Sooner or later someone would find out and would have read access to your data. No matter how you try to obfuscate it, the user/password combination would need to be stored somehow in your app.
What you should do is build a web service that connects to your DB and verifies your users. The database password stays on a server. This proxy-approach is not awkward, it is the only way to keep your database logins away from your users.
One option is to create your own service in the cloud that abstracts away your storage. That also has the benefit of allowing you to change your storage without updating all your devices.
In that model, the service stores the credentials to access the storage and you implement user security in your application layer. I also wouldn't think of it as a proxy layer - that implies that it's a thin pass through. If you develop a service, you should define a web interface (rest, soap) that's agnostic to the storage. In that case, it's a service, not a proxy.
EDIT:
Typically the web service authenticates the user (don't write your own). Basic Auth with SSL is typical. Then, in that services context API, you get access to the username. From there, you do you what you need. Your storage is accessed with the one storage account that has full access to all content.
Another auth option is OAuth which allows them to authenticate with someone like google - you never get the password - just a token from google letting you know they authenticated and they are who they claim to be. For example, that's how stack overflow works.
Related
So I have a standard Rails app running on ec2 that needs access to s3. I am currently doing it with long-term access keys, but rotating keys is a pain, and I would like to move away from this. It seems I have two alternative options:
One, tagging the ec2 instance with a role with proper permissions to access the s3 bucket. This seems easy to setup, yet not having any access keys seems like a bit of a security threat. If someone is able to access a server, it would be very difficult to stop access to s3. Example
Two, I can 'Assume the role' using the ruby SDK and STS classes to get temporary access keys from the role, and use them in the rails application. I am pretty confused how to set this up, but could probably figure it out. It seems like a very secure method, however, as even if someone gets access to your server, the temporary access keys make it considerably harder to access your s3 data over the long term. General methodology of this setup.
I guess my main question is which should I go with? Which is the industry standard nowadays? Does anyone have experience setting up STS?
Sincere thanks for the help and any further understanding on this issue!
All of the methods in your question require AWS Access Keys. These keys may not be obvious but they are there. There is not much that you can do to stop someone once they have access inside the EC2 instance other than terminating the instance. (There are other options, but that is for forensics)
You are currently storing long term keys on your instance. This is strongly NOT recommended. The recommended "best practices" method is to use IAM Roles and assign a role with only required permissions. The AWS SDKs will get the credentials from the instance's metadata.
You are giving some thought to using STS. However, you need credentials to call STS to obtain temporary credentials. STS is an excellent service, but is designed to for handing out short term temporary credentials to others - such as the case where your web server is creating credentials via STS to hand to your users for limited case use such as accessing files on S3 or sending an email, etc. The fault in your thinking about STS is that once the bad guy has access to your server, he will just steal the keys that you call STS with, thereby defeating the need to call STS.
In summary, follow best practices for securing your server such as NACLs, security groups, least privilege, minimum installed software, etc. Then use IAM Roles and assign the minimum privileges to your EC2 instance. Don't forget the value of always backing up your data to a location that your access keys CANNOT access.
According to this post, it's possible to decompile an iOS application.
How can I prevent an attacker from gaining access to my AWS DynamoDB database? Just having the access keys out in the open like shown on the Amazon developer guide doesn't seem like it would be very safe.
I would think that I could use keychain to store the keys, but I feel like there would be an easy way to get past this for a motivated attacker, given they have the app's assembly source code.
Currently, I connect using Amazon Cognito. All I have to use to connect are the identity ID and the role name. I don't see anything stopping an attacker from simply getting those values and connecting to the database.
For example, what stops an attacker from decompiling the Facebook iOS app code and deleting all of the users?
How can I prevent attackers from decompiling my iOS application and getting access to the database access keys, or at least prevent them from doing any major damage, such as deleting users?
Based on my admittedly limited experience, I'd say that a really motivated attacker will always be able to retrieve the credentials you use to access your database regardless of what you do to your executable. I would, however, question why you application needs to have direct access to your database in the first place.
The usual way to safeguard your serverside data is to use a web service to access it. App contacts web service with request, service contacts db, gets data, sends it back. Since the web service and the db are both hosted on your server and only the web service needs direct access to your db, there is no need to store db access info in your app. Problem solved.
It's impossible. In order for your program to do something, it must contain the instructions that allow the computer to follow to do that thing, which means anyone else can also follow those instructions to learn how to do the exact same thing.
You can use SQLCipher and use your auth's userToken and/or userId as cipher keys.
I'm developing an application which lets users upload pictures. I'd like to use Google cloud services to store these pictures. I am creating a unique GUID for each image in database and would like to store the images in the cloud with that name. It makes sense for me to make an ajax request for a GUID and then upload the image from the same page directly to google cloud services.
https://github.com/GoogleCloudPlatform/storage-getting-started-javascript/blob/master/index.html
Like shown in this example.
My first question is, should I be sending this to my back-end(C# code) and uploading it from there? Or is this the correct approach?
And my second question if this is the correct approach is, wouldn't exposing my details like that in javascript allow other people to upload from outside my application as well?
An API key, by itself, identifies a call as being associated with a certain project for purposes of billing. It's only necessary for anonymous calls. An API key does not grant any sort of authorizations. If there's an object in a bucket in your project that only your project members can see, the API key won't give anyone permission to read it.
That said, it's not a great idea to share your API key if you can help it, and if you need to share it, you should lock it down as much as possible. API keys can be limited to use with only certain IP addresses, only with certain web referrers (for instance, it will only work with JavaScript clients on www.yoursite.com), or only when run from a particular iPhone or Android app. These precautions aren't cryptographically fool-proof (there's no reason a hacker couldn't spoof a referer header), but they do make them pretty much useless for someone else who just wants to paste an API key somewhere to enable a web app and doesn't want to pay for it themselves.
The problem with using the javascript client's approach for your application is that individual users would either end up uploading objects completely anonymously or with their own Google accounts. Neither is super great, since the anonymous option would basically require you to create a bucket with anonymous writes enabled, and you don't want to do that.
There is a great approach to letting users upload pictures, though: signed URLs. Signed URLs allow your server to securely sign, in advance, a request to upload an object with your credentials. This is your best option for letting anonymous end users securely upload objects to your buckets.
Documentation on signed URLs: https://cloud.google.com/storage/docs/accesscontrol#Signed-URLs
I have been working on an Angular/Ionic application and am using the OAuth.io plugin to handle a facebook login to gain a user's information. From that I derive a simple database name based on the user's firstname and their Facebook ID number.
What I am wanting to do would be to sync this local pouchDB instance to an online CouchDB instance (currently using http://iriscouch.com) for replication to a desktop app, or something similar. The piece I am missing is how to handle user authentication/authorization to be able to only read and write to their own database and no one else's as all of the code currently lives on the client side with no app server to handle any login aside from the OAuth.io plugin.
Is this possible to handle without adding an app server layer, and without manual intervention to create a user on the CouchDB instance?
Currently you can only do per-user read-write permissions in CouchDB by having an additional process on the server side (details), which would be troublesome for you since you're using IrisCouch, so you'd need a separate server somewhere to host this process.
A few alternative options are available to you right now:
Couchbase, which has per-user databases
Janus, which works using Mozilla Persona rather than Facebook ID, and isn't ready yet, but should be unveiled shortly
I'm just starting reasearch about the best way to implement user authentication within my soon-to-be app.
This is what I have so far:
A desktop (Windows) application on a remote server. That application is accessed locally with a browser (it has a web console and MS SQL Server to store everything).
The application is used with local credendials stored in the DB.
This is what I'd like to accompllish:
Provide access to some information on that SQL Server DB from my app. That access of course must be granted once a user has id himself with valid credentials.
This is what I know so far:
How to create my PHP web service and query info from a DB using JSON.
How to work with AFNetworking libraries to retrieve information.
How to display that info on the app.
What I don't know is which could be the best method to implement user authentication from iOS. Should I send username and password? Should I send some hash? Is there a way to secure the handshake?
I'd for sure appreciate any advise, tip, or recommendation you have from previous experience.
I don't want to just implement it but instead I want to do it as good as possible.
There have been books written on this, so any answer given here is necessary incomplete. So, I'll give you an outline of the simplest thing that actually works. The bare minimum for securing a service like this is to use HTTP Basic Authentication (supported natively by both AFNetworking and PHP) secured by SSL/TLS.
Basic Authentication is a way of hashing (not encrypting) credentials in a standard way and sending them as one of the headers in your request (Authorization: Basic <Base64-encoded concatenated credentials>). AFNetworking supports this as part of its AFHTTPClient class (see the -setAuthorizationHeaderWithUsername:password: method). PHP parses the authentication header into a pair of server variables ($_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW']). From here, you just check the username/password combination against your user database and allow or forbid access to the resource.
The reason it's crucial to pair this technique with HTTPS is that the credential hash is easily reversible; you're basically sending the password in the clear, so it can be grabbed by anyone listening to your traffic. Setting up a certificate and sending your requests over the secure channel prevents this type of vulnerability.
If you want to be a little more sophisticated, two-legged OAuth is also a viable choice for this scenario.