Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Mark FX

macrumors regular
Original poster
Nov 18, 2011
159
17
West Sussex, UK
I've recently started an app project, which is a secure data storage application, and currently have the app locking encrypted data files to the Mac device on which they were created.
But have now started to question that design principle.
As although this makes the data files even more secure, as the files could not be opened by anyone on another Mac system, even by the person who created them in the first place.

So although I'm not going to go into details about the app and what it does, or how it works, for obvious reasons, I'm interested in the views of other coders and developers, as to wether they think this system locking mechanism is a good idea or not.

So the three short simple app design questions are.

Locking the secure data files to a particular Mac system, Good idea or bad idea?

Would you want to have the option to lock the data files to one Mac system?

And also the option to unlock them from this system as well, for movable backed up files?

I appreciate any views on the three questions above , but please could you keep your answers breif and relevant to the questions only, as opposed to questions about the app itself.

Many Thanks in advance.

Regards Mark
 
Last edited:
I've recently started an app project, which is a secure data storage application, and currently have the app locking encrypted data files to the Mac device on which they were created.
But have now started to question that design principle.
As although this makes the data files even more secure, as the files could not be opened by anyone on another Mac system, even by the person who created them in the first place.

So although I'm not going to go into details about the app and what it does, or how it works, for obvious reasons, I'm interested in the views of other coders and developers, as to wether they think this system locking mechanism is a good idea or not.

So the three short simple app design questions are.

Locking the secure data files to a particular Mac system, Good idea or bad idea?

Would you want to have the option to lock the data files to one Mac system?

And also the option to unlock them from this system as well, for movable backed up files?

I appreciate any views on the three questions above , but please could you keep your answers breif and relevant to the questions only, as opposed to questions about the app itself.

Many Thanks in advance.

Regards Mark

Perhaps I'm missing something. I don't see the benefit of locking files to a particular CPU. Where's the redundancy? What happens if you have a CPU/disk/motherboard failure
 
  • Like
Reactions: xStep and chown33
Perhaps I'm missing something. I don't see the benefit of locking files to a particular CPU. Where's the redundancy? What happens if you have a CPU/disk/motherboard failure
I agree completely. Without some sort of contingency plan that can unlock the files after a failure, from a machine other than the one it was locked to, I don't see this as being safe. So as a feature, I'd have to call it bad.

I honestly don't understand the purpose behind locking to a specific CPU in the first place. As a user, why would I do this? What's the reason for the product or feature? What is the goal it helps me achieve? Those are important questions, because they go to the heart of the feature's very existence.

As a DRM (Digital Restriction Management) product, I can see both a reason and a goal, but that wouldn't be a reason for a user, only for the entity who wants to restrict an otherwise easily copyable digital product.

If I were working in IT and needed to lock a file to a machine for some management purpose, then that might be a useful goal. But if the user of the machine can then unlock it without my permission, then that's not useful. So again, as an individual user, I see no purpose here. As a manager of other users or their machines, I can see a purpose, but the attractiveness (its "good or bad"-ness) depends on other factors.
 
  • Like
Reactions: xStep
Yeah! after further reflecting on my original design, I kind of came to that conclusion myself after posting the question, that it was not such a great idea to implement this system locking for the data files.
Although it was more likley to be locked to the Mac's Serial Number or UUID, or maybe the system's Host Name or Address.
But this would still lock out the user's data files on another system.

Just thinking out load on this one, even though I kind of new the answer while asking for other opinions.
I may consider making it a user option with a big warning attached.
The extra security may be worth the price to someone.

Regards Mark
 
The extra security may be worth the price to someone.
Anyone who thinks that is probably deluding themselves. Security theater instead of security.

The best security would use strong cryptography and a good key. If the key is made from a machine serial number, well, now you've defined a pattern for attackers to apply brute force to. If the key is hashed from a machine serial number, you've created a motivation for creating a rainbow table for attackers to use. No matter how you slice it, you're basically creating a pattern that keys will always follow, even if the serial number is combined with other random key material. You're effectively reducing the randomness of the key.

Conversely, if the cryptography is good, and the key is good, then nothing is gained by tying to a serial number (or other machine-unique token), for the data-recovery reasons already outlined above. In short, you've tied your key-management and key-distribution practice to something that you have sub-optimal and incomplete control over. You'd be better off just using a better (longer) key, or employing better key-management practices, because both of those are things you have control over.
 
You shouldn't be asking developers.

You should be asking potential users.

There may well be use cases.

This message will self-destruct in 10 seconds... 9... 8...
 
  • Like
Reactions: huperniketes
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.