tag:blogger.com,1999:blog-5261195576153415173.post7408402174712650965..comments2022-11-30T02:31:34.937-08:00Comments on mHealth and Mobile Development: Certification for the lack of certificationUnknownnoreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5261195576153415173.post-31860818469242144232013-12-16T09:14:42.194-08:002013-12-16T09:14:42.194-08:00re: checking for root, it's trivial to check f...re: checking for root, it's trivial to check for root as best you can then fire a warning to the user that the app is not secure if the device is not adequately secured. Bear in mind you cannot always be sure the device isn't rooted, and you would be removing a lot of power users and potential early adopters from the market by shutting out rooted devices. And - in general - those who root are those who understand the dangers (or they quickly become those who own bricks and can't run any apps at all). That said, HTTPS _everything_, _always_. Encrypt at rest _everything_, _always_. Should be illegal not to, IMO.Anonymoushttps://www.blogger.com/profile/17247413103763098908noreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-90420418616376831682013-12-14T09:34:01.559-08:002013-12-14T09:34:01.559-08:00Thank you for your thoughtful response. I agree 10...Thank you for your thoughtful response. I agree 100% that a clinician user must take all precautions to protect other people's data. A more difficult case is for apps we want patients to use themselves. As developers, we have to balance security, ease of use, and patient preference. <br /><br />I think a lot of these come down to educating the user about the risks. People do not set that 4-digit PIN for a reason -- they value convenience over security. In fact, the phone has a lot more sensitive data than PHIs (private photos, locations, cash cards in passbook, email etc). If the user does not care, it is difficult for the developer to do anything. ;) For instance, if you are forcing them to set a PIN to access an app, they will either use "0000" or simply do not use the app. Tough decisions. :)<br /><br />Speaking of which, I wish future iPhones will encrypt data using a hash from the fingerprint (if available). A hash from the fingerprint will be much harder to brute force.<br /><br />MichaelMichael Yuannoreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-9202239447401594752013-12-13T11:15:33.094-08:002013-12-13T11:15:33.094-08:00#1 - NSFileProtectionComplete is subject to brute ...#1 - NSFileProtectionComplete is subject to brute force which is the issue. Only 44% of people even use a PIN on their phone (I can't find the stats on people that use more than a 4 digit PIN) - so it leaves a huge vuln. With SQLCipher, you couple forcing a user to use a PIN within your product, hash+salt it and use that to secure your App with SQLCipher. It removes you from assuming the user has set a PIN for the device itself. <br /><br />Now, you could theoretically derive a key and store it in the keychain w/o forcing the user to enter the PIN. IMHO this is better than just relying on NSFileProtectionComplete, but you are still open to brute force attacks. At least with that, you wouldn't be open to people lazily pulling data from the phone unencrypted - at least your stored data is encrypted. You then have some protection at least. <br /><br />#2 - I am sort of on the fence on. I think I wrote this more towards the "doctor is storing patient data" on the phone - where they should be forced to not utilize a jailbroken device, because it opens up security holes for patient data. <br /><br />Perhaps you are correct that patients should have the right to choose if they want to risk their data. But, I guess, the question is, do people understand the risk of their data when they root or jailbreak. No simple answer.<br /><br />Great points! Harold Smithhttps://www.blogger.com/profile/03347298956963566210noreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-79181468785378389282013-12-13T09:04:11.023-08:002013-12-13T09:04:11.023-08:00Harold,
Thank you for the excellent article. I ha...Harold,<br /><br />Thank you for the excellent article. I have two quick questions / comments with regard to your recommended security approach:<br /><br />1. Encryption of "at rest" data: iOS provides several data protection classes. The "NSFileProtectionComplete" class encrypts the data files unless the app is open. While it is still subject to brute force attacks, I thought it is simpler and more secure than SQLCipher? After all the SQLCipher key needs to be stored in the application itself.<br /><br />2. Preventing the app from running on Jailbroken devices. To me, this goes against the whole idea of "patient centeredness". Who are we to override patient preference, and dictate which device the patient must use? If a patient is willingly putting his own data at risk (she could write it on a paper journal after all), I am not sure the app developer should play "police man". <br /><br />Would love to get your thoughts on these. Thanks!<br /><br />MichaelMichael Yuannoreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-76858381370223008302013-12-12T04:01:01.847-08:002013-12-12T04:01:01.847-08:00Great piece, Tyler. We need you to write about th...Great piece, Tyler. We need you to write about these security problems on an ongoing basis. Thanks, DCKDavid C. Kibbe, MD MBAhttps://www.blogger.com/profile/13787233253906112642noreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-53083213712950490202013-12-11T16:39:57.909-08:002013-12-11T16:39:57.909-08:00Tyler, no worries. I was on the fence about disclo...Tyler, no worries. I was on the fence about disclosing the names of the products, but their lack of responses and issues presented were pretty bad, IMHO - especially for personal health information. I have extended the courtesy of private disclosure plenty of times before - but those entities were very responsive. <br /><br />I'll update if I hear anything. Harold Smithhttps://www.blogger.com/profile/03347298956963566210noreply@blogger.comtag:blogger.com,1999:blog-5261195576153415173.post-73751056504755020712013-12-11T10:33:07.018-08:002013-12-11T10:33:07.018-08:00Thanks for taking the time to survey for this stuf...Thanks for taking the time to survey for this stuff, and for writing about it. Count me in as interested in an updated post if you ever hear from either company.Anonymoushttps://www.blogger.com/profile/00484092068134831325noreply@blogger.com