Erasing HDD password via admin/bios password

Hi Lint256,

Thanks for posting.

Apologies that your systems are not working as expected.

Your post suggests that you have a corporate or large business account.  The Forums are pretty much made up of consumers helping other consumers.  Your company will have a Technical Account Manager assigned to it.  

The TAM will have all the information regarding your products and what warranty options are available, so contacting them would be in your best interest in resolving this issue.  If you are having difficulty finding your TAM, please contact your IT department or the Finance department of your company.

If it's a personal system, use the "Get Help Now" option at the bottom right to chat with a Dell technician right away.

To remove the hard drive password, it's necessary to set a blank password (go into the setup page with the hard drive password, and enter the current password).  Leave both fields blank and save.  This will remove the hard drive password.

There are two parts to the drive password - the one in setup, and the one stored on the drive itself.  You MUST know the existing password to reset it to blank -- if you don't, while you CAN remove the CMOS portion of the password, the one on the drive will remain -- it would require replacing the drive or shipping the drive off to a recovery company with the tools to remove it.

We have a small corporation, we bought the laptops on the market and I'm the responsible for the whole I.T. dept.

Nobody from Dell ever cared to check us, hence why I had to get here. Maybe customers will serve me better than wha I got so far from Dell.

ein63, you clearly don't understood me, I know how bios/hd password works, okay?

The thing is: In Dell's HD password page it is clearly stated that the admin (*bios*) password can be used to revoke the hard drive password, in such scenario the HDD password would be encrypted using admin's password hash as encryption key, and if you have such password you could anytime later generate the key that could be used to turn the encrypted HDD password back into plaintext.

On the other hand I understand your skeptical stance (I have the same). I have to investigate up until an authoritative answer that what's written on bios is actually rubbish, see?

What is the exact wording you're seeing in the BIOS about clearing out the HDD password by only knowing the admin password?  The HDD password is stored in the HDD's controller itself.  Even for drives that are NOT self-encrypting, I don't believe there's even an ATA command to clear out the password without knowing it, otherwise somebody could just move your drive to a system where they know the BIOS admin password, clear it out, and then access your data, which would render an HDD password utterly useless.  But on drives that DO use the password to protect an encryption key that in turn protects all the sectors on the drive, clearing out the password without knowing the original would not even be possible, except of course if you were to accept erasing the entire drive.

Glad you got it sorted.  And that's interesting, I didn't realize Dell systems cached a copy of the HDD password in some form in order to enable that functionality.

In terms of a little safer rather than NSA-proof, if you're going to have your users typing in passwords anyway, I don't see why you wouldn't want to use proper disk encryption.  It's much more security for the same amount of effort, and actually BitLocker is designed to allow you to have encryption without a user-supplied password at all because the TPM stores the key (although you still need to retain the Recovery Key for certain atypical scenarios, and you can optionally still require a user-supplied PIN as well).  Additionally, using encryption would simplify data recovery efforts through tools like SATA to USB adapters/enclosures/docks, which wouldn't know how to prompt for an ATA password but which you would be able to decrypt if they were using BitLocker or similar.  Finally, as of this writing, Dell does not support HDD passwords on NVMe-based SSDs, just in case you were planning on getting any laptops that will have them.

You're wrong in many ways, the ATA specification do have a specific command for that since ages ago. The HDD password is kept on disk, but unaccessible for ordinary users, if the password was kept on the HDD controller (the disk-side part of it) a simple HDD controller switcheroo would solve the problem. The HDD is really not encrypted at all, we just want to make it a bit safer, not NSA-proof. (We're considering whether or not to employ truecrypt or bitlocker over the machines or not, 'til then we're using HDD's passwords.)

What you don't get it is that the BIOS itself keeps a copy of HDD password on it, but even if you reverse engineer it you won't be able to extract it because that copy of the (HDD) password was scrambled/encrypted by the admin's (BIOS) password, so as long as you know admin's password you can extract the plaintext of the HDD's password as long as the HDD was kept on the same machine that used to set its password all along.

The text on that admin's password page goes:   "Also, the admin password can be used to delete the HDD password." , it just doesn't tell you how: It's just a matter of typing the admin's password where you should type HDD's password.

Thanks to your post I took the time to try using the admin's password right in place of the HDD's password, even though they're clearly different, and it worked like a charm, who would have thought?

The connection is indirect - you need the BIOS or Admin password to get to the page where you can reset the hard drive password -- that much is true.

Note however that the hard drive password DOES NOT encrypt the contents of the drive.  Unless your system and drive support full disc encryption -- which is a totally separate issue from the password set on the hard drive itself.

That password is stored in a user-inaccessible portion of the drive -- it CAN be removed by someone having the software tools to do the job, at which point the contents of the drive become accessible.

I just solved it, you can actually use the admin password right on place of the HDD password and it will reset the HDD successfully.

Be aware that my admin password has nothing to do with the HDD password, the HDD password was given to the end used, the admin password wasn't.

I'll leave you guys with the trouble of understanding how can the BIOS encrypt HDD's password by employing the hash of the admin's password as the encryption key, sorry, that's cryptography 101 for me.

By the way, with respect to TrueCrypt vs. BitLocker, be aware that TrueCrypt was abandoned quite a while ago, before they even got around to fixing Windows 8-related issues.  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.  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.  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.  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.  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.  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.

But 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.

Intel several years ago introduced hardware-level acceleration for AES encryption/decryption operations into their CPUs, so the CPU does not create a bottleneck or cause meaningful CPU utilization even when writing to the latest NVMe drives.  That concern is several years outdated.  With respect to impossibility of recovering data, if you're already managing passwords manually, encryption is no WORSE in that regard, and once again, with BitLocker especially if you have an AD environment, the Recovery Key is automatically backed up when encryption is enabled (you can have it refuse to enable if it can't talk to a domain controller).  That seems a lot safer to me than having to worry about knowing the HDD or admin password for a particular system, but what do I know?  And as I said earlier, ATA passwords present their own complications recovering data.  What if you want to recover the drive from an external enclosure for convenience or because you don't have a suitable laptop nearby where you can install it internally?

Yes, I suppose setting up encryption is a bit more work if you're already going to muck around in the BIOS to set an admin password anyway, but I would still argue it's worth it.

If you set an HDD password, you're using a SATA-based HDD.  Here is Dell's official KB article saying that HDD passwords are not supported on NVMe SSDs: www.dell.com/.../no-bios-option-to-set-a-hard-drive-password-on-m2-ssd

In my defense, I said "I don't believe" there was an ATA command to clear out an HDD password without knowing it.  So yes I suppose I can still be wrong, but it's not as if I claimed it as fact.  However, I don't see any proof from you to the contrary.  You simply claimed that the command exists as part of the industry-wide ATA standard and has for years.  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.  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.  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.

But where YOU'RE wrong is in categorically saying that the drive itself "is not really encrypted at all".  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.  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.  Other encryption standards that take advantage of automatic drive encryption are TCG, OPAL, and Microsoft's eDrive standard.

jphughan, I'm not picking on you, you were wrong, but hey, we all make mistakes, tech changes all the time as well. Many people think that password-protecting hard drives is a proprietary extension of a hard-drive/bios combination bundled by a manufacturer because used to happen in the past.

Now, in no way a simple ATA command would be able to "disable" the password, that would be ridiculous, if you think I intended to say that I must say that either you read that wrong or I said it wrong, it doesn't matter afterall.

The data wasn't encrypted because for that to happen we would have to see the drive auto-encrypting itself right after setting a password, kinda like a RAID rebuild, but instead the drive kept itself idle after setting the password.

Also, if you use "0000000000000000000000000" as key to an AES encryption key you will not get paintext data coming out as encrypted, that would only happen if you use a XOR encryption, which is next to no encryption at all. But I get what you're suggesting: The drive could use that password to encrypt itself, yes, but either you would have to completely repartition and reformat it after setting the password or you would have to wait the drive to read-then-rewrite-encrypted itself from alfa to omega, right?

Last but not least I have a self-encrypting Crucial M300 SSD on other computer, I work with digital currencies and I know a whole bunch about crypto ;-)

Let's agree that SATA password protection is a standard and can be used on any recent SATA-compliant device, that can even be done with SATA-USB adapters, but we don't have software for that as it's such a niche market that you end up being obligated to use it on your own SATA HBA, ok?

NMVe are much different, they differ from one another just like software modems differed from hardware modems in terms of standardization, manufacturer can do almost anything they feel like. We just don't see any BIOS manufacturer going thru all the steps to make their BIOSes compatible with each and every way NVMe-SSD-manufacturers decide to go for.