Storing Authentication Tokens on iOS - Nsuserdefaults VS Keychain

Storing authentication tokens on iOS - NSUserDefaults vs Keychain?

I would highly recommend you use the keychain - it's exactly what Facebook do for storing their session tokens.

NSUserDefaults is not secure or encrypted - it can be easily opened and read, both on device and when synced to a Mac. So whilst user defaults is a good place for things like preferences and config info, it's not a good place for anything sensitive, like passwords.

Session tokens should almost always treated the same as passwords, so you should store them securely in the keychain, where they'll be encrypted. Apple have some sample code (GenericKeychain) that shows a basic implementation, and you'll find other examples by searching StackOverflow. Hope that's helped you out.

Storing authentication token on iOS

2 options

• Make use of NSUserdefault(store as access token or textfield inputs[Remember me option])
• Keychain access(recommended) for doing the job.

NSUserdefaults is not secure for storing such credible values which is for authentication purpose.Keychain on the other hand is made to do this,safe and secure.

how to store more than 5 authentication token in keychain iPhone

Since KeychainWrapper is initialized with an Identifier, a possible way to store more tokens (or else) is to have various Identifiers.

how can i store my access token to defaults or into an array

You can use user defaults objective c save your token

NSString *token = @“yourToken”;
[[NSUserDefaults standardUserDefaults] setObject: token forKey:@“Token”];
[[NSUserDefaults standardUserDefaults] synchronize]; 

Get your token

NSString *savedValue = [[NSUserDefaults standardUserDefaults]
    stringForKey:@"Token"];

Swift3.0 code save data

let defaults = UserDefaults.standard
defaults.set(“yourToken”, forKey: “Token”)

// Get the Token from UserDefaults
if let token = defaults.value(forKey: “Token”) as? String {
    print("defaults Token: \(token)")
}

Best Practice of saving an access token in iOS

I am just saving it inside NSUserDefaults but I don't think it is the safest way of persisting sensitive data like this.

Almost. NSUserDefaults uses plaintext for storing data, so it is insecure. If you want to be a bit safer, you can store the data in the keychain (however, even this considered-to-be-secure storage can be easily dumped...)

Best practices for storing a Token in iOS app

If view controllers need this token, you've broken MVC. There is no reason for a view controller to directly talk to the network. That should be handled in the model layers. A view controller coordinates a view while it's on the screen. It doesn't do anything else.

So you'll store your token in the model. How do the view controllers access the model? That depends on your experience level:

• If you're fairly new to Cocoa development, use a shared instance (a "singleton," though really it's not a singleton; it's just a static let shared property). This pattern has been used very successfully by Cocoa devs for decades. There's a reason we use it. It just works, and you don't have to fight it. But, it has some problems, which brings me to the next option:

• If you have enough iOS experience to have actually run into problems with shared instances (usually related to unit testing and occasionally related to code reuse), then you will know enough to have an opinion on all the many other patterns people have been applying (and sometimes inventing) in recent years. But jumping into these more complicated patterns is not, in my opinion, a good approach for new developers. They tend to move you away from how Apple intends us to work (in particular, most of them assume you won't use Storyboards, and Apple pushes Storyboards very hard). There are reasons to go against Apple's guidance, they're not always right, and some of the new patterns are very interesting. But wait until you have some experience before you decide that you know more than Apple about developing Cocoa apps.

If you need to store the token in memory, you're done. If you need to persist it and it's considered sensitive, then the correct place is Keychain. Use a wrapper. The Keychain API is horrible beyond description. Any wrapper will do. KeychainAccess is popular these days, but really, any of them are fine.

The main problem w/ NSUserDefaults is that if someone steals the phone and jailbreaks it, it's easier to read NSUserDefaults than Keychain. As a matter of policy, don't put sensitive information in NSUserDefaults.

Can the keychain be used like a NSUserDefaults on steroids for storing NSData?

I don't think there is any limit and you definitely can store NSData, however performance will not be very good. Quoting Apple's documentation:

The keychain is intended for storing small amounts of sensitive data that are specific to your app. It is not intended as a general-purpose mechanism for encrypting and storing data.

I wouldn't store more than 1KB or so in a keychain entry, and you should also avoid having a lot of keychain entries.

If you need to encrypt a large amount of data, you should generate a random AES-256 key and store the key in keychain, then encrypt your large data using AES. Look up RNCryptor on keychain for a good library to implement this properly and ask any specific encryption questions at security.stackexchange.com.

I also wouldn't store large amounts of data in NSUserDefaults. It also is not intended to be used that way. Data should be stored in a file in one of the relevant directories defined under NSSearchPathDirectory, or else in iCloud.

It's a matter of performance. All of the code for working with both keychain and user defaults is based on the assumption only a small amount of data will be there. It's very fast for small amounts of data, but larger amounts will wast memory and cpu cycles/battery power. And in the case of keychain, you are also wasting the user's LTE bandwidth, since every change will be sent over the internet to every device they own.

I don't think Apple's app review team actively enforces this stuff, but it would technically violate the rules to use the API for anything other than it's intended purpose.

---

Related Topics