![]() There are some reasons, cpu usage being one, impossibility of recovering any data if something bad happens (that is a BIG factor), time and effort required to go into each user's laptop and encrypting it are other factors. Other encryption standards that take advantage of automatic drive encryption are TCG, OPAL, and Microsoft's eDrive standard. Initially, the sectors are encrypted but the KEY is stored in the clear, so it works as an unencrypted drive, but if the drive supports "ATA Class 0 encryption" then when an HDD password is specified, that key is encrypted using a derivation of the supplied password. While not ALL drives that support HDD passwords encrypt their data, it is becoming increasingly common for drives, both spinning and SSDs, to always encrypt their actual data sectors. In terms of a logic board swap, even if you COULD do that, that's not the same thing as claiming there's a simple command to disable an HDD password.īut where YOU'RE wrong is in categorically saying that the drive itself "is not really encrypted at all". But if you have documentation to the contrary, as I'd hope you would when saying something as emphatic as, "You're wrong in many ways," I would be keen to read it. That is a highly dubious claim since again, that would mean any drive's password could be bypassed from any system simply by running a small utility that issued that standardized command - does it really sound plausible to you that the standard would have been implemented that way? I can imagine there being a variety of proprietary tools for different vendors for this purpose that aren't publicly available, but a standard ATA command? I doubt it. You simply claimed that the command exists as part of the industry-wide ATA standard and has for years. However, I don't see any proof from you to the contrary. ![]() So yes I suppose I can still be wrong, but it's not as if I claimed it as fact. In my defense, I said "I don't believe" there was an ATA command to clear out an HDD password without knowing it. With TrueCrypt/VeraCrypt, if you don't know the password and don't have a rescue disc for that system that was made when a password you DO know was in place, you're stuck.īut again, if you're still disinclined from BitLocker because you don't always have the Pro version of Windows that's required to use it and/or would prefer open source software, I would look at VeraCrypt over TrueCrypt. Additionally, if you have an Active Directory environment, BitLocker allows Recovery Keys to be backed up to the domain controller, which simplifies things quite a bit. At least with BitLocker, you can reasonably expect that in-place upgrades to a new version of Windows will run properly even when BitLocker is being used. Also, as with any third-party software that operates at a low level like this, there's always a risk that updating to a new version of Windows will break something, which in the case of a disk encryption solution is inconvenient at best and catastrophic at worst - and with Windows 10, Microsoft is committing to new releases every March and September. ![]() But be aware that just like TrueCrypt, VeraCrypt does not support OS volume encryption on GPT disks, which are used for systems that boot in UEFI mode BitLocker has no such limitation. Version 7.1a is still solid at least if you're on Windows 7, but you should look at VeraCrypt instead, which rose up to build on what TrueCrypt started. BitLocker, be aware that TrueCrypt was abandoned quite a while ago, before they even got around to fixing Windows 8-related issues. By the way, with respect to TrueCrypt vs.
0 Comments
Leave a Reply. |