I currently have an iOS app that allows people to submit content to our server (twitter like). We don't have a login system, instead we rely on the UDID of the device to uniquely identify users (yes, aware that this isn't perfect but worth the tradeoff for users not having to create an account).
Requests from the iOS app are sent as POST requests to our server and are NOT authenticated in any way.
We are currently experiencing a lot of spam (obviously) and am looking for an easy method to verify that any request hitting our server in fact came from our app - and not some script that a spammer wrote.
We have tried using the user agent string which contains the app name but that is easily spoofed. Is there any way to verify that requests hitting our server is coming from our app?
One idea might be to include a random number as a parameter, and then encrypt that number with some private key. Have the server verify that the the encrypted version is = to the plain text version. (the private key would have to be on our server as well as embedded in the app).
I'm not looking for the perfect solution - a 90% solution thats easy to implement is def preferred.
Thanks!
I'd solve this by taking the message, salting it with a secret key known only to your app, and probably adding the username and UUID, then hashing them with a SHA-1. If the hash is presented along with the data, then it will act as a digital signature, and you can be reasonably sure that the message is authentic.
The shared secret key will have to be distributed with your app, so an extremely determined attacker will be able to reverse engineer it out of your app- but a casual spammer will be far more likely to just seek greener pastures.
Another approach would be to generate a pgp private / public key pair at registration- but this is a lot of work for this problem.
Related
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
my goal is to give my customers an option to lock their App's Data, so when they give their iPad/iPhone to someone else for an extended period of time, users can't access or accidentally look at confidential data.
[Some Background: It's a medical Application where physicians/staff-members would give iPads to patients. Now the patients are supposed to access some contents, yet shouldn't be able to look at other patients data]
So far, I have a password inside my App. But when a staff-member forgets and wants to reset it, the only thing I can do is "deletion of the whole database". I have a Disclaimer telling people to store their password somewhere, but this is still not the optimal user experience.
Is there anyway I could authenticate the user via his Apple-Password? This way only the person knowing the Devices-Account password can access the data and can always reset the Apple-Password with Apple.
PS: Server-Solutions, like having a User-Password pair with reset-via-mail on a server of mine is out of the question, since it would add to much complexity for the users and in many medical situations the Device shouldn't have access to the web.
Multiple thoughts:
I am not aware of any native public API to authentication using Apple password.
If your app is enterprise app, possibly you can use native private API. I would recommend to disassemble AppStore and check how does it do authentication then
You can also to try to access to some Apple web page which requires authentication and pass to it apple account and password and see what it will return. If it authenticated correctly, then you are fine and you can reset a password.
To make it secure, you will need to ask a user to enter it for a first time, so you can encrypt your encryption keys using authentication material (so you can decrypt encryption key later on).
However, I am not very big fan of this solution, since you can change Apple password and you will be stuck in such case.
Server solution is the best option and it's not that complex. Another option is Forgot password. You ask something what administrator know ("What is your first pet?") and he enters the answer when your application is configured and this answer could be used later to unlock your app.
P.S. And the best solution at the end (which is absolutely shameless self advertisement). A startup which I am part of (SpydrSafe) works on the product which solves exactly your problem. In fact, healthcare is one of the verticals which whom we actively works. If you are interested, contact me (my email is in profile)
if you authenticate the user via apple password, and they forget their apple password, then in order for them to retrieve that password is by reset-via-email .... so either way you are stuck with that dilemma.
As for actually using your apple password, no.
Best way to get what you want is to have the password stored somewhere in real life. Like another computer that the doctors can report to and ask for passwords or just don't forget the password.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
I have a web app that you can currently log into with either your email address or your username.
I'm developing an iPhone application and I'm just wondering if I should offer the ability to log in with your phone number. If this is the case, a user would first have to provide the service with a number on the web (an optional parameter).
I find it convenient on other services I use where I might not remember what email I have connected to it.
Is this a good idea?
Would you offer it in a service you were
building?
I'm trying to decide if its worth the trouble to build.
NOTE: This number would strictly be used for authentication.
I think that if your service is not about phone numbers (calling, texting, etc., e.g., whatsapp, etc.) I would not add phone number authentication for a few reasons:
Some users might be deterred to provide a phone number due to privacy concerns (no matter how hard you try to explain them that you will keep it safe)
With the phone number you will now have 3 options to login with, which is way too much. You want to keep your mobile login screen very simple
Some people may think that they might get SMSs from you or get their phone bill charged somehow
Overloads your backend
Just keep it simple...:)
To add to that, I personally prefer just email, without a user name. So many sites require user names AND impose restrictions on how this user name should be structured, so you end up with tons of them. With emails, you can't go so wrong - most people use a primary one to sign up for sites.
Hope that helps.
I know ASIHTTPRequest works perfectly well with HTTPS. All we need is this one line of code:
[myASIHTTPRequest setValidatesSecureCertificate:NO]
Here's my question, I don't have any HTTPS certificates approved by any authority, including the US government. And I am not a US citizen, and my app isn't targeted at the US market. When I submit an app containing the above HTTPS code,
Do I need to check the encryption box when submitting?
If I don't check that box, will the HTTPS code be detected? (Like an private API?)
If I check that box, will I get rejected? (since I don't have any certificates approved by any authority)
If I have to get a certificate approved by someone before my app get approved by the App Store, how long will this apply-and-get-approved process be, and what about the cost?
Thanks in advance!
Do I need to check the encryption box when submitting?
No. Your not encrypting any data on the device, it's only transport encryption provided by apple so don't have to tick the box.
If I don't check that box, will the HTTPS code be detected? (Like an
private API?)
As above, it doesn't matter.
If I check that box, will I get rejected? (since I don't have any
certificates approved by any authority)
If you tick the box you have to fill out a lot more information and your in for a long long wait just getting the legal stuff squared away before you even get to the app review..
If I have to get a certificate approved by someone before my app get
approved by the App Store, how long will this apply-and-get-approved
process be, and what about the cost?
You buy a certificate from any root certificate authority. Certificates expire, so you have to renew it when it runs out. The cost depends on who you buy the certificate from. I would recommend that you shop. You can also get wildcard certificates e.g. *.example.com that would allow you to setup any site ending in .example.com.
The accepted answer is simply wrong, and following its advice puts your app in danger of being removed from the App Store. You should look at the FAQ for Worldwide Trade Compliance on the iTunes Connect site. It clearly states that even if you use iOS-provided HTTPS, you still need to submit an ERN request to the US government. Also, it does not matter that you live outside the US, as your app is distributed by a company (Apple) in the US.
See this blog post for more details, especially the comments, as BIS has recently made it easier to apply.