I am developing an app that requires a user to register and log in. Currently to date I have been storing their userID (retrieved from an API), username and hashed password (plus a few other bits of information) in user defaults however after doing some research on security, users are able to modify these defaults as they are stored in a text file.
My concern is that I would not want a user to change the userID and access other users information. What would be the best way to secure the data in the app?
All information is retrieved from an online API and I am not using Core Data.
I have looked in to Keychain but would this be overkill to store userID?
The keychain would not be overkill, that kind of thing is what it's for.
Really though it sounds like a bad security problem in your API. If the user can login and can then access the data of every other user via the API and then if they fiddle with some values, that's no good.
Related
I’m new in iOS development and I want to create an application that a user needs to login to do payments and other actions that involves sensitive information, thus I want to know the best practices for storing user login credentials on data base. I know that when you use “Stripe” to do payments no credit card data is stored on your data base or app. But I have a doubt in storing other sensitive data such as passwords, directions and other info. I’ve looked in the internet for the best practices of storing this kind of information and came to the conclusion that I need to apply the following:
• Encrypting passwords in the Data Base
• Use Keychain
• Use HTTPS
I’m I in the correct path? Is there a standard way of doing this?
Google for something like 'salting password hashing'
Regarding Stripe, it should be okay to store the last4 digits of the credit card (but even this can be extracted from Stripe, using the customer-id or charge-id).
Im building an application based in Ruby-On-Rails that facilitate users to obtain their information from different websites into one centralized dashboard. To do that, at the beginning the app asks for their login information (user+password) of every website.
Because we are working with sensitive information we have to save the users data encrypted in our database. Afterwards, to login into the users account, we decrypt the password in the database and login to the webpage using his/her info.
We want to avoid to see the user private information at any moment during the web-scraping.Is there a way to use their information to login into their account and obtain the data that they are looking for, avoiding any chance for us to see their private information ?
I'm developing an iOS app that uses Cognito User Pools / Federated Identities, Mobile Analytics, and S3 to manage various features of the app, and recently I have become concerned for the security of these features. I already use IAM roles to control the services unauthenticated vs authenticated users have access to, but most of these services use strings (e.g. user pool app client id or user pool app client secret for User Pools, or app id for Mobile Analytics) to give the app access to that service.
What are the best practices to securely store these strings on the device to be used when necessary? Is it even necessary to secure these strings since the app is using IAM roles?
If it is necessary to securely store the strings, I have read that using the CommonCrypto library to encrypt strings before putting them in the keychain is best, but I'm not sure what key to use for encryption since my user needs unauthenticated access to those services. Any advice would be tremendously helpful.
This is a common problem to any mobile app. If someone really wants to, it's not difficult to decompile the app and scrape the keys from it. It's great that you are using IAM roles to restrict feature usage. This will limit the blast radius of attackers, but not necessarily prevent them.
Wth user pools you also get a globally unique identifier which can be used with IAM to restrict what S3 you can use key pre-fixes (which act similar to folders) to limit the objects that users can access to pre-fixes with their unique identifier. You can refer to https://mobile.awsblog.com/post/Tx1OSMBRHZVM9V0/Understanding-Amazon-Cognito-Authentication-Part-3-Roles-and-Policies (Using user pools as the provider, which will use the identity id as the prefix). Depending on how you structure your app you could use this so each user can only modify their own objects. I don't think Analytics has any way of restricting like this... because it wouldn't really make sense for it.
As far as securing your ID's there are things you can do to help mitigate, but there is no fool proof way to prevent someone taking it. You could for instance have the app make a call to your server for the ID... but then an attacker could just call the server. You could encrypt it, which might make it more difficult for an attacker to get, but you have to keep the key somewhere and if the app could get it so could someone who decompiles the app. Unless your app users get some sort of password from outside the app and put it in there isn't a complete way to lock it against attackers.
Hope this helps.
I am currently uniquely identifying a user by storing the FacebookID of that user. I recently read around and I saw that this is incorrect usage and that Facebook ID's can change for some reason, all in all that I shouldn't use them. Is this true? If so, is a AWS Cognito ID that is derived when a new facebook user signs in and authenticates themselves a viable way to uniquely identify a user? If not, How would I uniquely link a facebook account, with apparently no variable that is stable enough to store, with a unique identifier to store in my database?
Check the following statement (from the official documentation: https://developers.facebook.com/docs/apps/upgrading):
No matter what version they originally used to sign up for your app, the ID will remain the same for people who have already logged into your app. This change is backwards-compatible for anyone who has logged into your app at any point in the past.
So, you can use the Facebook ID to uniquely identify your users.
However, depending on your use case and the way you plan to manage security, you should consider a few more things. The purpose of AWS Cognito ID is not to be communicated between users, it is kept between your app and Cognito. So if you want users to communicate using their accounts (sending text messages for example), the Facebook ID is more suited for that. Nevertheless, I am experiencing this problem when trying to achieve fine-grained access control using DynamoDB.
As Hatim said, the Cognito identity id is not meant to be shared between users.
That being said, once an identity id has a login associated to it, it could only change on merging with another authenticated id. Unless you're doing that, which it doesn't sound like you are, it would be a stable way to identify your users. You could use the identity id as the identifier in your database, as long as it isn't exposed.
If you're using DynamoDB, as this blog post explains, doing it this way allows you to configure your IAM roles to make access to this data more secure.
I have a web app that needs to provide lightweight user access to a mobile client, via an server side API.
These users need to be authenticated, but do not need to ever login to the web app itself.
Instead of creating a traditional User model, with authentication/authorization, I am thinking of instead creating api keys that get emailed to the relevant user email, so they can just use that to access the mobile app.
Has anyone used this approach before?
I know you shouldn't send access credentials via email. But I can't think of another way without going for the full blown User model approach, which is overkill here, in my opinion.
Thoughts on a postcard please.