Slashdot Mirror
Microsoft Offers New Data-Security Scheme
bingly_beep writes "The BBC is reporting Microsoft's new user security measure, whereby users sensitive information is stored on their PC rather then online, as in their previous offerings, such as Passport. This sounds like a good idea, but any such system would surely require that the user definitely erases the HD on any machine they sell. Perhaps Microsoft should include an option, like 'Prepare this computer for resale,' which utterly destroys all data."
This could be good or bad. The data, stored on the computer, would not be on the Internet all the time and thus be safer. On the other hand, .Net has great security. A user with little computer knowledge would not protect his/her computer well enough from hackers, etc., which would leave the data "out there." I think that the latter is safer, however.
And, as stated in the article, there had better be a way to destroy all sensitive data if the user wishes to sell the computer.
INACTIVE ACCOUNT
MSFT's assumption is apparently that data stored on personal computers is more secure than on servers.
I'm not sure that this is necessarily true.
When you consider that the vast majority of computer users have no idea what a "firewall" is, and that MSFT's track record for security is poor to say the least -- its not obvious that storing sensitive data in designated locations on PC's is the safer route at all.
Some might say this is MSFT's way of passing the buck of responsibility to the end user rather than fixing the problem. Now if data is compromised fault could arguably lie with mom and pop rather than a Microsoft server.
------ The best brain training is now totally free : )
One little linux command is all it takes, insert linux live CD and su -c"shred /dev/hda" and even the NSA would have trouble getting any data off the harddisk, windows license isn't transferable anyways. Fight software piracy, shred used Windows hard disks!
Apocalypse Cancelled, Sorry, No Ticket Refunds
* and i would say unlikely threats, for any one individual, and compared to all the risks everyone faces in life. imho.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
Despite what they tell you, these erasure programs do not work on drives using journalled filesystems (ie almost every drive there is these days... including you Windows users with NTFS, and Linux users with Reiser, Ext3, XFS, etc).
This is not entirely correct.
Journaled file systems by default only use the write ahead log or "journal" for metadata changes, and not for data itself.
This means, when you overwrite the file 35 times in place, the journal is not involved in this operation.
When the secure delete program, then issues a DELETE, that operation is logged. Some time shortly thereafter the directory structure is updated to reflect that deletion. However, the data would have been overwritten 35 times (using the defaults in the eraser program) notwithstanding that the delete may be deferred.
As long as the filing system allows software to bypass the write-behind disk cache this works.
If your disk controller hardware has its own cache this may very well interfere.
a journaling filing system makes it more difficult to hide the fact that a deleted file ever existed, but it typically will not interfere with writing data into that file.
Additionally the article expresses concern that a journaling system may move a file to a new location on a write.
You will want to confirm for your specific filing system, but typically this would be very very inefficient on a hard disk.
AFAIK ext3, reiser, NTFS, BeFS (the only journaled filing systems I have much experience with) do not move files around on the partitian simply because the data within the file is modified.
Since hard drives support random access, on a hard drive there is very little likelyhood that a superior location to store that file will be found than the original location chosen (and there is no reason to NOT use the original location). Hard drives fill up over time. The overhead in choosing a better location in very expensive.
Someone please correct me if I am wrong.
In fact, (with those FSs that I mentioned) unless you defragment or something, files are left in the original locations they were allocated, and any modifications occur on the same disk locations.
Another factor to consider. The journal is typically implemented as a fixed size circular buffer, and it is overwritten frequently.
If you want to help insure this happens soon perform the following operation.
1: create a directoy X.
create a 0 byte file Y inside inside directory X.
2:
open Y. append 1 byte.
close Y.
move Y to the parent directory of X.
open Y. append 1 byte.
move Y back inside X.
rename Y to some random name.
rename directory X to some random name.
touch X
touch Y
copy Y to a new file Y!
delete Y
let Y! now be the new Y (for future iterations)
3: repeat all steps from 2: until 3: a hundred thousand times or so.
Do that with your disk cache turned off (or a sync operation between every step) and that will probably irradicate whatever is in the journal.
This loop causes a ton of meta data changes which must be written into a write ahead log. Moving and renaming the file may or may not be considered a metadata change depending on the FS, it may simply be a data change to data in a directory (I believe this is the case in ext3; but if I recall, in BeFS file renaming and moving is a metadata change.
Finally.. since the journal doesn't track data itself, the only thing it may contain are filenames, paths and perhaps filesizes. Your data is not there.
in any event, while there is merit to the concerns expressed in the article, they are somewhat overstated.
If you ask me, we should all be encyrpting our data partitions by now!
I agree with you there.
Storing plain text is absurd.
No one has a right to their *own* opinion. They have a right to the TRUTH.