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."
there was a story a few minutes ago about a report that Windows security was better than Linux but then it came to light afterwards that it was MS funded but undislosed.
it seems to have disappeared and been replaced by this advert for MS doing good things for security?
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
whereby users sensitive information is stored on their PC rather then online, as in their previous offerings, such as Passport.
wouldn't that lead to easyer spoofing?
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 : )
If the data gets compromised in a central Microsoft server, Microsoft is the only one to blame. If the data gets compromised on your home PC, Microsoft will blame you for failing to secure it properly.
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.
You could use Autoclave, but since it's being end-of-lifed, you could follow the Autoclave author's recommendation and use Darik's Boot and Nuke instead.
Give me my freedom, and I'll take care of my own security, thank you.
We can probably assume that Microsoft's previous "Safe ID" a.k.a. Passport can account for a portion of the high-tech (i.e. non-"other means") ripoffs. 200 million potential vulnerabilites and it's "popularity suffered". A masterful understatement.
If they have proven themselves completely inept at securing at storing 200 million passwords on one password server system, why would anyone think they could possibly secure one password on 200 million password server systems?
I suspect they're just drumming up new lock-ins for Longhorn. FTA: "would not confirm however whether the new info cards ID system will be built into the current Windows XP version or Longhorn". If i were a betting man...
--
Remember, it's never too late to have a happy childhood!
Prior to hare-brained schemes like Passport, where exactly does Microsoft think people stored sensitive information? That's what we have had keychains, vaults, and client certificates for, supported by browsers, operating systems, and add-ons.
Maybe this whole story is an attempt to create the false impression that this is new, breakthrough technology so that Microsoft can then patent "local disk storage of personal information"? Or maybe it's just an April's Fools joke.
Which would probably wipe the harddrive so that M$ would have to sell the new schmuck a new Windows license.
JMD
When all else fails, feel free to panic.
Microsoft solved reading other domains cookies years ago, they still do it now on a lot of their sites, whats funny is they have one department making an internet browser that has security restrictions on cookie usage yet in another department they are thinking up ways to get round the security restrictions they put in place
whats the betting on their Microsoft/MSN cookies will be able to cross domains by default ? seeing as everybody wised up to their exploit game perhaps they are seeking other ways to compromise peoples privacy, advertising aint worth shit without that all important user tracking
you usually judge people based on their previous actions and with MS having such a piss poor record on security and privacy with obviously teams of programmers dedicated to getting round security restrictions (unless this exploit and those GUID servers was mysteriously unintentional) i wouldnt trust those fuckers with telling the time, never mind my security or privacy
Well... aside from that one there's also the shred manpage which discusses this:
CAUTION: Note that shred relies on a very important assumption: that
the filesystem overwrites data in place. This is the traditional way
to do things, but many modern filesystem designs do not satisfy this
assumption. The following are examples of filesystems on which shred
is not effective:
* log-structured or journaled filesystems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
I can't really find any other good info on this, but given what I know about how journaled file systems work I certainly believe this.
Having said that, if anyone has any real information on this I'd be interested to know as well.
When the write head of a HDD applies a magnetic charge to a portion of the disk, it has just enough strength to change the surface polarity to the intended bit value. If it uses too much, it'll spill over onto adjacent portions; not enough, and the polarity of the magnetically sensitive material beneath it will interfere with the intended bit value.
What you are saying is true. If you only overwrite the data a single time, it is easy to determine what the previous value was.
However secure erase tools will overwrite data up to 35 times with random data.
This makes it much more difficult to recover the data and have confidence in what you are recovering.
Another thing to keep in mind is that the original data was also only written barely strongly enough to record the intended bit. It isn't like the original data was burned in with a laser and only the subsequent overwrites are faint. every pass is just strong enough to record the desired bit.
No one has a right to their *own* opinion. They have a right to the TRUTH.
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.
On another note, I'd like Windows to have simple profile switching. No, not the user profile, but the system settings. 1 gaming profile with all the systray stuff out of the way except for AV-software and the firewall, no background services bloat etc. Another profile for strictly browsing and e-mailing with super-restricted access to the lower layer API's or everything sandboxed or whatever. Third profile for productivity apps. E-mailing and web browsing are almost a must here so this may make profile 2 not needed (except in the home for your kids maybe?) but this also needs to be sandboxed. I don't mind waiting for an extra 5 seconds loading my mailclient for security reasons. If Microsoft could make this work (aw with so much money in the bank, they ought to be) they'd have a very powerful feature on their hands. It increases their security (which is mediocre at best) and improves on the user experience. The only problem I can think of is the load time of these profiles. That should be kept to a minimum.
The best weapon of a dictatorship is secrecy, but the best weapon of a democracy should be the weapon of openness.