-
All replies
-
Helpful answers
-
Nov 24, 2015 12:15 PM in response to Csound1by iRaindrop,Point well taken. My bad. But I invite you to re-read the first two sentences of my post after that.
-
Nov 25, 2015 5:32 PM in response to MarcelloM1973by peterfrommawson lakes,Apple's explanation of their reasons for removing this function make no sense at all. If there's a problem with the delete algorithms or a security breach is possible then why not fix the problem? Does using the command directly as in "diskutil secureErase freespace LEVEL /Volumes/DRIVENAM" still have the same issues as the function that has been removed?
Some articles suggest using the rm (or a variant of this command) command also works - but aren't these just the lower level calls used by the removed function?
-
by Barney-15E,Nov 25, 2015 6:36 PM in response to peterfrommawson lakes
Barney-15E
Nov 25, 2015 6:36 PM
in response to peterfrommawson lakes
Level 9 (50,099 points)
Mac OS Xpeterfrommawson lakes wrote:
Apple's explanation of their reasons for removing this function make no sense at all. If there's a problem with the delete algorithms or a security breach is possible then why not fix the problem?
It is likely not fixable. For SSD's, there is no fix possible. Repeatedly writing to the disk serves little purpose as the cells may not actually hold the data anymore. Also, it will reduce the lifespan of the drive. The drive controller can do things with the data and not tell the OS. A similar problem happens on a spinning disk in that the controller can remap bad sectors without the OS knowing. Those "bad" sectors can store the data you wish to erase securely. The OS knows nothing about them or what is stored in them.
Does using the command directly as in "diskutil secureErase freespace LEVEL /Volumes/DRIVENAM" still have the same issues as the function that has been removed?
There is no difference. OS X is just a GUI wrapper that implements the unix commands.
Some articles suggest using the rm (or a variant of this command) command also works - but aren't these just the lower level calls used by the removed function?
It is srm, but I am not sure if that is actually used by diskutil or if they have their own algorithm. Regardless, it has the same flaws.
Going back to this:
why not fix the problem?
They did. It's called FileVault. If you fully encrypt the disk, there is no need to securely erase anything.
-
Nov 25, 2015 10:25 PM in response to Barney-15Eby iRaindrop,Barney-15E wrote:
They did. It's called FileVault. If you fully encrypt the disk, there is no need to securely erase anything.
There is a need if you don't want the file accessible by anyone who has the password to log into (or has gained access to) the encrypted disk.
-
Nov 26, 2015 4:22 AM in response to iRaindropby Barney-15E,iRaindrop wrote:
Barney-15E wrote:
They did. It's called FileVault. If you fully encrypt the disk, there is no need to securely erase anything.
There is a need if you don't want the file accessible by anyone who has the password to log into (or has gained access to) the encrypted disk.
Why would you give them the password?
Why do you let them have any access to the computer without implicit trust?
And why would you have file recovery software installed on that computer?
-
Nov 26, 2015 5:25 AM in response to iRaindropby R C-R,Adding a little to what Barney already said, without the password here is no practical way to access anything on the disk. The encryption is very secure, the same as is used by government agencies, & while it can be broken, it typically would take decades to do so.
Besides, as long as you are not foolish enough to give anyone else your password or use a short, easy to guess one, there is very little chance they would ever get it right. Every user can have their own account, so there is no good reason to 'share' an account with anybody else.
-
Nov 26, 2015 9:42 AM in response to iRaindropby MrHoffman,iRaindrop wrote:
There is a need if you don't want the file accessible by anyone who has the password to log into (or has gained access to) the encrypted disk.
Folks with the FileVault 2 disk master password have access to the protected data. That's axiomatic.
But there's no need to provide that master key, as the user account passwords provide a (revokable) proxy to the data.
Apple has published guidelines for organizations setting up full disk encryption with FileVault 2, which can provide some background.
Protecting against so-called insider threats — the folks with authorized access and at least user-level passwords — is a whole 'nother level of complexity to a configuration, and that goes far beyond topics such as FileVault 2 and of what a particular organization can decide is proper data destruction.
-
Nov 26, 2015 10:23 AM in response to iRaindropby Csound1,iRaindrop wrote:
Barney-15E wrote:
They did. It's called FileVault. If you fully encrypt the disk, there is no need to securely erase anything.
There is a need if you don't want the file accessible by anyone who has the password to log into (or has gained access to) the encrypted disk.
Why would you give your password out, doesn't that defeat the purpose of having one?
-
Nov 26, 2015 10:35 AM in response to Csound1by Allan Eckert,Sort of defeats any efforts to encrypt the data also.
As I see it, if the data has the need for encryption then no one besides you should have the password to gain access to the password. If that is not possible then don't both encrypting it in the first place.
-
Nov 26, 2015 11:05 AM in response to Csound1by iRaindrop,Csound1 wrote:
There is a need if you don't want the file accessible by anyone who has the password to log into (or has gained access to) the encrypted disk.
Why would you give your password out, doesn't that defeat the purpose of having one?
Yes, encrypted disk and passwords don't amount to a hill of beans if a spouse of someone has the pwd (bad idea as they could have different accounts), or if the mac is left on before it times out and you're in the other room and someone else does some snooping. In other words, human missteps and forgetfulness always trumps security - so in that case folks like to have the sensitive data completely gone for the "good housekeeping" and pease of mind -- even though its "inside the castle."
Mr. Hoffman comments on what I'm trying to get at.
-
Nov 26, 2015 11:10 AM in response to iRaindropby Barney-15E,If you have a computer that you cannot control access, it is not really feasible to store sensitive data on that computer.
If you don't have absolute control, you have none at all.
If you need to function in that environment, and you standard users are capable of hacking into your account, then you should store the sensitive data on another encrypted medium that you do not leave connected to the computer unless you have control of the computer.
-
-
Nov 26, 2015 11:47 AM in response to iRaindropby Barney-15E,Yes, encrypted disk and passwords don't amount to a hill of beans if a spouse of someone has the pwd (bad idea as they could have different accounts), or if the mac is left on before it times out and you're in the other room and someone else does some snooping. In other words, human missteps and forgetfulness always trumps security - so in that case folks like to have the sensitive data completely gone for the "good housekeeping" and pease of mind -- even though its "inside the castle."
Where exactly was the sensitive data before you moved it to the Trash? Was that not suspect to snooping, then?
-
Nov 26, 2015 12:10 PM in response to iRaindropby MrHoffman,iRaindrop wrote:
Mr. Hoffman comments on what I'm trying to get at.
Not sure I was commenting on that, I thought the topic here was the lack of Data Security Erase and its inapplicability to SSDs, and the usefulness of Full Disk Encryption to avoid that case.
If you have local data that's more sensitive than usual, data that's regulated, or if you're a target for somebody willing to spend some thought and some money to access your data (and possibly illicitly), then any lapses, an unfamiliarity with how SSDs or FDE works, and the rest of the sorts of operational mistakes that can arise, are all bad news.
But as for secure erasure of SSDs (which is what this thread started as), you need add-on tools to do that — using overwriting isn't particularly effective, and isn't entirely reliably even on its intended hard disk target — or use full disk encryption to avoid the usual sorts of access.
-
Nov 26, 2015 12:17 PM in response to Barney-15Eby iRaindrop,Your question is kinda off-topic since we use general scenarios, but I'll answer it anyway. About 300 XML files of documentation (which I generate with Java) for a pre-released product of which I am under NDA for my client. Anyhow. I understand a lot more know and thanks for the insights.