This content has been marked as final. Show 3 replies
It's not possible to hide this at all, but also it's not really a big security hole, certainly it's tiny to the hole created by using AutoBoot in the first place.
If you use an auto-boot style mode, the encryption key for the drive is stored on the machine as well (this is true regardless of who's product you use), so in autoboot mode there's no real security at all. Changing the password is just annoying, it doesn't really make things any more secure in real terms. If you loose the machine you can't even claim the data was protected (as you lost the key alongside the data).
If I found your machine in autoboot mode, I could just use the classic firewire attack and retrieve your data, or I could try any of the published network attacks and see if there was a patch missing. I could even just wait a month or two for a new network vulnerability to be discovered and use that to attack your machine. Without pre-boot authentication, there are a lot of easy ways in.
Saying that though of course, it all comes down to a risk analysis - It may be a perfectly rational business decision to use auto boot style protection and rely on the Windows login for security. That's a different discussion.
It was a business decision to go with autoboot based on implementation, user training, and support requirements.
Can the autoboot.ini file be in a secured folder? I haven't tested this yet but, when does autoboot refer to the file for the password?
Would autoboot refer to the file when pre-boot is loading? so the folder security shouldn't be an issue?
it really does not matter - the password and key are stored on the disk for anyone to find. No protection you can put in place is going to change that.