App Design conundrum

Discussion in 'Mac Programming' started by Mark FX, Apr 28, 2017.

  1. Mark FX, Apr 28, 2017
    Last edited: Apr 28, 2017

    Mark FX macrumors regular

    Mark FX

    Joined:
    Nov 18, 2011
    Location:
    West Sussex, UK
    #1
    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
     
  2. jaduff46 macrumors regular

    jaduff46

    Joined:
    Mar 3, 2010
    Location:
    Second star on the right....
    #2
    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
     
  3. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #3
    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.
     
  4. Mark FX thread starter macrumors regular

    Mark FX

    Joined:
    Nov 18, 2011
    Location:
    West Sussex, UK
    #4
    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
     
  5. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #5
    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.
     
  6. Les Kern macrumors 68040

    Les Kern

    Joined:
    Apr 26, 2002
    Location:
    Alabama
  7. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #7
    Listen to Les Kern.


    (Recursion is fun!)
     
  8. jtara macrumors 65816

    Joined:
    Mar 23, 2009
    #8
    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...
     
  9. huperniketes macrumors regular

    huperniketes

    Joined:
    Jun 26, 2007
    Location:
    (0, 0, 0)
    #9
    This should be the first step when designing products.
     
  10. Toutou macrumors 6502a

    Toutou

    Joined:
    Jan 6, 2015
    Location:
    Prague, Czech Republic
    #10
    Great, now I'm stuck in your stupid loop. Thanks for ruining my evening!!!!:mad::mad:
     
  11. ApfelKuchen macrumors 68030

    Joined:
    Aug 28, 2012
    Location:
    Between the coasts
    #11
    What do you expect, at a forum dedicated to a company that is headquartered at 1 Infinite Loop (well, for the time being)?
     
  12. huperniketes macrumors regular

    huperniketes

    Joined:
    Jun 26, 2007
    Location:
    (0, 0, 0)
    #12
    You guys are hilarious. I love it!
     
  13. jaduff46 macrumors regular

    jaduff46

    Joined:
    Mar 3, 2010
    Location:
    Second star on the right....
    #13
    Loop: See End Loop

    End Loop: See Loop

    The fun never stops!
     

Share This Page