3

From what I understand after reading the iOS Swift documentation, these are the key points:

  1. The user can't access or modify my iOS application's UserDefaults

  2. Other applications can't access or modify my iOS application's UserDefaults

At most, the information found in UserDefaults gets deleted. But it can't be freely read or modified by a third party. So what exactly is the danger in storing sensitive information here?

Can someone give a plausible example of an attack where a significant software vulnerability would be exposed due to using UserDefaults instead of Keychain Services on the iOS platform?

AlanSTACK
  • 5,525
  • 3
  • 40
  • 99
  • 2
    Does this answer your question? [Difference between Keychain and NSUserDefault?](https://stackoverflow.com/questions/12090136/difference-between-keychain-and-nsuserdefault) – EmilioPelaez Jun 17 '21 at 16:31
  • @EmilioPelaez Hi, I don't feel like the questions are exactly the same. My question is more of a pedagogical dive into the theoretical differences between the two objects from an attacker's standpoint. In fact, if you read the link that you posted, you will notice that the answers over there conflict with the answers below this post regarding `Keychain Services` susceptibility to jailbroken devices. – AlanSTACK Jun 17 '21 at 16:37

1 Answers1

3

First and foremost, encryption - UserDefaults does not use encryption out of the box.

Second, on any device a user can access the files system and specifically your app container and hence the UserDefaults using iExplorer app for example and access the whole plist that represents the user defaults - change it and extract information - not protected against malicious users.

Third, third party libraries you are using in your app are able to access your ‘standard’ user defaults or guess some container name you are using to extract/ override the information.

There are probably more reasons but I’d say these are the main ones

CloudBalancing
  • 1,461
  • 2
  • 11
  • 22
  • Wouldn't `Keychain Services` also be susceptible to the same circumstances you described above? – AlanSTACK Jun 17 '21 at 15:32
  • 1
    Not that i can think of. It is encrypted and held within the container it is initialized with. So malicious users will have to break encryption and third party libs cannot access the keychain container. – CloudBalancing Jun 17 '21 at 15:34
  • See this thread on some additional benefits for using keychain vs user defaults. https://stackoverflow.com/questions/12090136/difference-between-keychain-and-nsuserdefault and this https://fluffy.es/persist-data/ – CloudBalancing Jun 17 '21 at 15:37
  • So the two circumstances which `UserDefaults` becomes unsafe is if the user themselves is stealing their own session data and if your app dependencies are going rogue? – AlanSTACK Jun 17 '21 at 15:43
  • Hmm, as we are talking about safety only and not best practices and best user experience yea. I would not say it's only the user who tries to steal its own session - I'd also say a malicious user got hold of the phone - weather stole it / bought it and managed to recover the disk/root it. I'm trying to think of more scenarios... on rooted devices, other apps might have access to other apps containers? – CloudBalancing Jun 17 '21 at 17:31
  • That's a very good point! It didn't even occur to me to consider the scenario of a stolen phone. This link, however, claims that `Keychain Services` can also be accessed via a jailbroken phone - https://stackoverflow.com/questions/12090136/difference-between-keychain-and-nsuserdefault. – AlanSTACK Jun 17 '21 at 17:56
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/233904/discussion-between-cloudbalancing-and-alanstack). – CloudBalancing Jun 17 '21 at 17:59