I'm creating simple user login at the beginning of my app. After user submits correct username and password, my script from server should return some parameters which I should store in some sort of local database, and check for these parameters every time when new view appear/loads.
My questions are:
1) which type of local "database" should I use, which one is secure so no one else from "outside" can access it, because if someone could than he could set my logins by himself (keychains, user defaults etc.)?
2) which parameters should I return from server, which one of them are essentially from security when checking if user is logged in - I'm thinking of username and the token - if user is successfully logged in, than server script should create some type of token which will be stored in online database. Every time user makes some request from app to the server than token is checked, if it exists in app and if it exists in server database and if they are equal.
3) How should I check if user is logged in when new view is loading in the app - should I just check if variables exists (for example in Keychains) or should I connect to the server and check every time server database?
for storing sensitive user data(password, api token, email) you should always use Keychain for this purpose.In other hand there is Realm also offer secure way to store your data.Its easy to use, you just need wrap data objects with realm base(Object) class and mark properties with dynamic attribute.For basic login system i think user name, email and api token good enough.But depends on api needs you can include here phone number, birthday etc.For checking user authorization I think validating api token good enough in most case.
There is also most secure techniques to improve data safety like keep database property names in keychain.Hashing sensitive data parts in api calls.Last thing you need use https for api communication.
Related
I have an iOS app where all user and data functionality is handled through firebase. For all required firebase functions, we have set the rights on firebase set such that they are secure (i.e., everyone can only read/write the parts of the database that are relevant to them).
Now, in the “create new user” screen of my app, obviously no user is signed in yet, but I would like to check for availability of the desired email address and username.
How can I conduct the check without making a list of all email addresses and usernames openly accessible in the database (i.e., setting the rights such that everyone can read them).
Keeping an openly accessible list of usernames in the database in my view is a security risk. On the other hand of course no user is signed in when on the “create user” screen, so I don’t know how to restrict the access.
Thanks.
There are many ways around this. Here are a couple suggestions:
Sign the user in anonymously before choosing a username. This would then give them the access you're looking for without making the data public. Then, when the user creates an account, the anonymous account can be converted, as shown in the documentation.
Use an HTTP-triggered Cloud Function, passing the username the user wants to try as a query. Inside the function, check the database for the existence of the username, and then respond to the HTTP call accordingly.
I'd probably do the former because it'll return a quicker response. Cloud Functions can take time to spin up if they haven't run for a while.
I am creating an application using Appcelerator wherein the user needs to enter the username and password to login. Once logged in, the user can enable TouchID for authentication. After logging out, the user can use the TouchID for authentication and use the application.
My flow is that once the username and password is provided, I store those two information in Keychain using the following module iOS Keychain Module. Then I use ti.touchid to authenticate the fingerprint, if success, then I retrieve the username and password from keychain and then send it over HTTPS web service call and login the user to the application.
My query is that, whether this is an acceptable approach.
I am not an iOS developer nor does any ti or keychain terms mean anything to me at all. That's for a start and to reduce the number of down votes i might get.
In terns of security, I would suggest that you imagine obtaining that particular user's phone where you know you have some authentication credentials stored. Let's say I am a user of your app, already logged-in and have my credentials saved somewhere on my device, and you obtain this phone by stealing it from me.
Now, will you be able to access my account in anyway? Will a hacker with access to the physical phone be able to retrieve any information stored in your Keychain storage?
If so, If you can think of anyway to do so, then your approach is not valid.
I understand you want to save users sometime by making sure they can login with just their fingerprint, which is a valid reason to think of such an approach, but you will have to think everything in terms of reverse engineering.
Additional recommendations would be using an on-the-fly hash to store information in the Keychain and making sure to check that before restoring the same. For example, user credentials saved on "home wifi" can be verified with your fingerprint only "at home" on the same wifi network where the same will be invalid on a different network.
i.e)
(keychainItem.x = y) is TRUE ONLY IF (something else)
where this (something else) is something that will prevent hackers from accessing the Keychain even if they have access to the device itself.
I do this myself when programming web applications with stored cookies. I for example use a stored cookie ONLY IF it is being accessed from the same IP it was saved from. Anytime that IP address changes, user will have to re-authenticate even if the cookie values are correct.
Hope this helps.
This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.
In the web API my app communicates with, the authentication process is designed in the following way:
The user enters the name of the group that he/she belongs to.
The server sends the list of group members.
The user chooses a user name and types a password.
My app sends a hash constructed of the group id, user id and password to the server to validate the credentials and in case of successful validation uses this hash in further transactions.
Having this process, I do not get standard NSURLConnection messages like connection:canAuthenticateAgainstProtectionSpace: or connection:didReceiveAuthenticationChallenge:.
I can deal with it per se, but when it comes to securely storing the credentials, I get confused. Is there a way to do this via some built-in iOS SDK methods or I have to write the hash in a file manually, for example? What's the proper way?
The keychain seems the best option to store the user's credentials/hash.
Check out http://developer.apple.com/library/mac/#documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
And https://github.com/ldandersen/scifihifi-iphone/tree/05e64ff2814a8192c43f1f81eb8e09dc3764fa18/security
Be aware that while the keychain is probably the safest place in iOS to store this kind of data, it isn't entirely secure. But considering the data you want to store, it's probably well enough.
Edit: Look at http://overhrd.com/?p=208
You'd be able to access the data on your keychain with simple calls of this nature:
[Keychain setString:#"hashhashhash" forKey:#"userHash"];
// later on…
[Keychain getStringForKey:#"userHash"];
I'm trying to implement a "Remember Me" login functionality for an ASP.NET MVC site I'm building. I'm trying to use this approach http://jaspan.com/improved_persistent_login_cookie_best_practice (see 'Miller's Design' near top) and have it working to a degree.
Thus the work-flow is:
User logs in and is issued a cryptographically secure random string + their database ID as a persistent cookie (lasting about 30 days). Secure string is stored in the database next to their user account record.
User later comes back to site where browser presents the login cookie, the ID and secure key is looked up in the database and if match is found, the user is automatically authenticated.
Once authenticated a new secure key is generated, stored in the database and new cookie issued.
I have this working fine, however, it doesn't work very well if the user logs in from multiple browsers or computers. Obviously different browsers will end up with a different secure key stored as a cookie, thus the work-flow becomes:
User logs in from browser A, is issued a secure key as cookie, key is stored in database.
User logs in from browser B, is issued a different secure key as cookie. Key is also stored in database, but overwrites the key generated from browser A.
User visits site from browser A again, browser presents cookie issued from step 1. but it no longer matches because secure key was replaced in step 2. so user has to log in again. Another new key is generated and overwrites the key issued to browser B.
Users visits from browser B again, key doesn't match, has to log in again etc. etc.
How do I solve this? Do I need to store and maintain multiple keys in the database? Am I even going about this the right way? I've noticed StackOverflow seems to manage this and remembers me from different browsers and computers.
From reading the article you linked, it seems to me like Miller's design is to store the random string and the username as a pair in a different table than the user-table. By using the random string as the index, you can have multiple simultaneous logins from the same user-name while still being reasonably well-protected from session hijacking.
Your description indicate that you store the random string inside the user-table, which would only allow one login at the time.
You need a third item in your cookie, a 'series' token. This will represent a login event. Everytime the user logs into your system, it creates a new series, that doesn't change until they logout, or login again. You still have your token, ie Secured Key, that is updating on every request.
Here's some links to help with this implementation:
Database problems when allowing multiple browser persistent log ins
The definitive guide to form-based website authentication