Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #57498 > unrolled thread
| Started by | dcohenspam@talktalk.net (Daniel Cohen) |
|---|---|
| First post | 2014-03-03 08:57 +0000 |
| Last post | 2014-03-04 17:10 -0500 |
| Articles | 8 on this page of 28 — 8 participants |
Back to article view | Back to comp.sys.mac.system
File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-03 08:57 +0000
Re: File vault, firmware password, etc Tom Stiller <clusterfux.upmon@gmail.com> - 2014-03-03 13:20 +0000
Re: File vault, firmware password, etc Jolly Roger <jollyroger@pobox.com> - 2014-03-03 15:13 +0000
Re: File vault, firmware password, etc Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-03 16:07 +0000
Re: File vault, firmware password, etc me@home.spamsucks.ca (Király) - 2014-03-03 16:19 +0000
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-03 17:57 +0000
Re: File vault, firmware password, etc me@home.spamsucks.ca (Király) - 2014-03-04 00:03 +0000
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-04 12:08 +0000
Re: File vault, firmware password, etc me@home.spamsucks.ca (Király) - 2014-03-04 19:31 +0000
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-04 20:46 +0000
Re: File vault, firmware password, etc Tom Stiller <clusterfux.upmon@gmail.com> - 2014-03-04 21:41 +0000
Re: File vault, firmware password, etc nospam <nospam@nospam.invalid> - 2014-03-04 17:01 -0500
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-04 23:09 +0000
Re: File vault, firmware password, etc Jolly Roger <jollyroger@pobox.com> - 2014-03-04 22:06 +0000
Re: File vault, firmware password, etc Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-04 22:25 +0000
Re: File vault, firmware password, etc billy@MIX.COM - 2014-03-04 22:39 +0000
Re: File vault, firmware password, etc Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-04 23:26 +0000
Re: File vault, firmware password, etc billy@MIX.COM - 2014-03-05 00:10 +0000
Re: File vault, firmware password, etc billy@MIX.COM - 2014-03-04 21:48 +0000
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-04 23:09 +0000
Re: File vault, firmware password, etc Jolly Roger <jollyroger@pobox.com> - 2014-03-03 16:25 +0000
Re: File vault, firmware password, etc billy@MIX.COM - 2014-03-03 17:05 +0000
Re: File vault, firmware password, etc Jolly Roger <jollyroger@pobox.com> - 2014-03-03 17:10 +0000
Re: File vault, firmware password, etc billy@MIX.COM - 2014-03-05 18:22 +0000
Re: File vault, firmware password, etc Jolly Roger <jollyroger@pobox.com> - 2014-03-05 18:28 +0000
Re: File vault, firmware password, etc dcohenspam@talktalk.net (Daniel Cohen) - 2014-03-03 17:57 +0000
Re: File vault, firmware password, etc Tom Stiller <clusterfux.upmon@gmail.com> - 2014-03-03 19:11 +0000
Re: File vault, firmware password, etc Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-03-04 17:10 -0500
Page 2 of 2 — ← Prev page 1 [2]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-03-03 16:25 +0000 |
| Message-ID | <bnjomtFkk8nU1@mid.individual.net> |
| In reply to | #57514 |
On 2014-03-03, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > In message <bnjkg2Fk228U2@mid.individual.net> > Jolly Roger <jollyroger@pobox.com> wrote: >> On 2014-03-03, Tom Stiller <clusterfux.upmon@gmail.com> wrote: >>> On 2014-03-03, Daniel Cohen <dcohenspam@talktalk.net> wrote: >>>> Firmware Password. This prevents any means of accessing the drive other >>>> than a normal login. Can the drive be read if it is removed? Is that why >>>> some people use both File Vault and a firmware password? >>> >>> Prevents acces to the machine itself. one cannot boot into single-user >>> mode or boot fram an external disk, CD, DVD or USB stick. > >> It can, however be bypassed by changing the hardware configuration (for >> instance removing / adding RAM). Someone with physical access to the >> machine can overcome it. > > Yep. > >> Also, someone with root access to the machine can read the firmware >> password easily with the nvram command-line utility. > > Is that still true? I thought that was no longer the case. For newer machines, I believe that's true; but for older systems... > However, Filevault 2 completely protects the data on the disk. There is no > way to get to it without the password or the recovery key. Yep, encrypting the data is the way to go. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2014-03-03 17:05 +0000 |
| Message-ID | <lf2cp9$1kr$1@reader2.panix.com> |
| In reply to | #57511 |
Jolly Roger <jollyroger@pobox.com> writes about Firmware Password:
> It can, however be bypassed by changing the hardware configuration (for
> instance removing / adding RAM). Someone with physical access to the
> machine can overcome it.
Not on machines using the Atmel chip. You either have to let Apple
read and decrypt the data on it, or replace the chip yourself. Or,
feed "Atmel bios chip" into the search engine of your choice, and
find someone willing to do it for you.
Anyway, I'd expect this includes most all of the Intel-based Macs.
> Also, someone with root access to the machine can read the firmware
> password easily with the nvram command-line utility.
I will try to look at this later (don't have a password protected
machine available right now).
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-03-03 17:10 +0000 |
| Message-ID | <bnjrbsFlm49U1@mid.individual.net> |
| In reply to | #57520 |
On 2014-03-03, billy@MIX.COM <billy@MIX.COM> wrote: > Jolly Roger <jollyroger@pobox.com> writes about Firmware Password: > >> It can, however be bypassed by changing the hardware configuration (for >> instance removing / adding RAM). Someone with physical access to the >> machine can overcome it. > > Not on machines using the Atmel chip. You either have to let Apple > read and decrypt the data on it, or replace the chip yourself. Or, > feed "Atmel bios chip" into the search engine of your choice, and > find someone willing to do it for you. > > Anyway, I'd expect this includes most all of the Intel-based Macs. Could be. I'm happy to be wrong, if that's the case! >> Also, someone with root access to the machine can read the firmware >> password easily with the nvram command-line utility. > > I will try to look at this later (don't have a password protected > machine available right now). Me neither. I suspect, as others have mentioned, it may not longer be the case with latest hardware. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2014-03-05 18:22 +0000 |
| Message-ID | <lf7q17$la$1@reader2.panix.com> |
| In reply to | #57520 |
I wrote, quoting Jolly Roger <jollyroger@pobox.com> about the EFI
Firmware Password:
> > Also, someone with root access to the machine can read the firmware
> > password easily with the nvram command-line utility.
>
> I will try to look at this later (don't have a password protected
> machine available right now).
This is from a 2013 MacBook Pro running 10.9.2. Output has been
truncated for posting here, but you may rest assured the password
is not anywhere in these data.
$ sudo nvram -p [Results are the same when not run as root...]
boot-image %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f
boot-gamma %10%06%00%00%c5%9c%00%00%00%00%00%00%f2%00%00%00%00
boot-args -v debug=0x100
SystemAudioVolume L
backlight-level r%04
SmcFlasherResult %00%00%00%00%00%00%00%00%00%00%00%00%00
prev-lang:kbd en:0
efi-apple-payload0-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01
RemoteDisabled %01
fmm-computer-name Sluggy
bluetoothActiveControllerInfo %1d%82%ac%05%00%00%00%13%18%1d%88
efi-apple-payload0 <array><dict><key>IOMatch</key>
efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00
efi-boot-device <array><dict><key>IOMatch</key>
LocationServicesEnabled %01
This is with the EFI security mode set to full, as opposed to command.
I didn't try the command mode, but I don't expect it'd be different.
The only way to do this is by running (or fishing out and copying to
someplace like /usr/local/bin) Apple's setregproptool, which lives in
the recovery partition (or on the install DVD for older OS versions), in
/Applications/Utilities/Firmware\ Password\ Utility/Contents/Resources/.
$ setregproptool -h
Error: this tool must be run as root.
$ sudo setregproptool -h
Password:
setregproptool v 2.0 (9) Aug 24 2013
Copyright (C) 2001-2010 Apple Inc.
All Rights Reserved.
Usage: setregproptool [-c] [-d [-o <old password>]] [[-m <mode> -p <password>] -o <old password>]
-c Check whether password is enabled.
Sets return status of 0 if set, 1 otherwise.
-d Delete current password/mode.
Requires current password on some machines.
-p Set password.
Requires current password on some machines.
-m Set security mode.
Requires current password on some machines.
Mode can be either "full" or "command".
Full mode requires entry of the password on
every boot, command mode only requires entry
of the password if the boot picker is invoked
to select a different boot device.
When enabling the Firmware Password for the first
time, both the password and mode must be provided.
Once the firmware password has been enabled, providing
the mode or password alone will change that parameter
only.
-o Old password.
Only required on certain machines to disable
or change password or mode. Optional, if not
provided the tool will prompt for the password.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-03-05 18:28 +0000 |
| Message-ID | <bnp8muFqnmrU1@mid.individual.net> |
| In reply to | #57622 |
On 2014-03-05, billy@MIX.COM <billy@MIX.COM> wrote: > I wrote, quoting Jolly Roger <jollyroger@pobox.com> about the EFI > Firmware Password: > >> > Also, someone with root access to the machine can read the firmware >> > password easily with the nvram command-line utility. >> >> I will try to look at this later (don't have a password protected >> machine available right now). > > This is from a 2013 MacBook Pro running 10.9.2. Output has been > truncated for posting here, but you may rest assured the password > is not anywhere in these data. > > $ sudo nvram -p [Results are the same when not run as root...] > boot-image %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f > boot-gamma %10%06%00%00%c5%9c%00%00%00%00%00%00%f2%00%00%00%00 > boot-args -v debug=0x100 > SystemAudioVolume L > backlight-level r%04 > SmcFlasherResult %00%00%00%00%00%00%00%00%00%00%00%00%00 > prev-lang:kbd en:0 > efi-apple-payload0-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01 > RemoteDisabled %01 > fmm-computer-name Sluggy > bluetoothActiveControllerInfo %1d%82%ac%05%00%00%00%13%18%1d%88 > efi-apple-payload0 <array><dict><key>IOMatch</key> > efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00 > efi-boot-device <array><dict><key>IOMatch</key> > LocationServicesEnabled %01 > > This is with the EFI security mode set to full, as opposed to command. > I didn't try the command mode, but I don't expect it'd be different. > > The only way to do this is by running (or fishing out and copying to > someplace like /usr/local/bin) Apple's setregproptool, which lives in > the recovery partition (or on the install DVD for older OS versions), in > /Applications/Utilities/Firmware\ Password\ Utility/Contents/Resources/. > > $ setregproptool -h > Error: this tool must be run as root. > $ sudo setregproptool -h > Password: > setregproptool v 2.0 (9) Aug 24 2013 > Copyright (C) 2001-2010 Apple Inc. > All Rights Reserved. > > Usage: setregproptool [-c] [-d [-o <old password>]] [[-m <mode> -p <password>] -o <old password>] > > -c Check whether password is enabled. > Sets return status of 0 if set, 1 otherwise. > -d Delete current password/mode. > Requires current password on some machines. > -p Set password. > Requires current password on some machines. > -m Set security mode. > Requires current password on some machines. > Mode can be either "full" or "command". > Full mode requires entry of the password on > every boot, command mode only requires entry > of the password if the boot picker is invoked > to select a different boot device. > > When enabling the Firmware Password for the first > time, both the password and mode must be provided. > Once the firmware password has been enabled, providing > the mode or password alone will change that parameter > only. > > -o Old password. > Only required on certain machines to disable > or change password or mode. Optional, if not > provided the tool will prompt for the password. > > Billy Y.. Good to know. Thanks for doing the research. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | dcohenspam@talktalk.net (Daniel Cohen) |
|---|---|
| Date | 2014-03-03 17:57 +0000 |
| Message-ID | <1lhy17z.7ue5631un7kqoN%dcohenspam@talktalk.net> |
| In reply to | #57506 |
Tom Stiller <clusterfux.upmon@gmail.com> wrote: > On 2014-03-03, Daniel Cohen <dcohenspam@talktalk.net> wrote: > > I am thinking about additional security for my Macs, a 2007 iMac and a > > 2012 MacBook Pro, both running Mavericks. After reading a lot I've got > > very confused, possibly even more so than when I started. So some of my > > questions and comments may well be stupid. > > > > I don't have great secrets to protect, just normal stuff. I am mostly > > concerned about protecting my data if a computer was stolen. > > > > I have an admin account and also a standard account. Both have > > passwords, not obvious but only about a dozen characters. > > > > So far as I understand it, the situation is this. > > > > File Vault 2. This encrypts the internal drive. One logs in using the > > normal account password. So presumably the encryption protects against > > other methods of accessing the drive (removing the drive, booting from > > an external drive, etc) and that is its main purpose. > > That's the way I see it too. > > > Firmware Password. This prevents any means of accessing the drive other > > than a normal login. Can the drive be read if it is removed? Is that why > > some people use both File Vault and a firmware password? > > Prevents acces to the machine itself. one cannot boot into single-user mode >or boot fram an external disk, CD, DVD or USB stick. Is that "cannot boot" or "cannot boot without the password"? The former might be troublesome, the latter is is fine. > > > What about security on external drives? As far as I can see, it is easy > > enough to encrypt a Time Machine drive and also external non-boot > > drives. > > > > But what should be done with external boot drives? > > Boot from the cloned drive, enable FV and allow it to complete the encryption > process. Thereafter, you will have to supply the FV password to mount the > drive. Once mounted, you can clone to it with the utility of choice. I'v just plucked up courage and encrypted an external boot drive while booted from my internal drive. I was later able to boot from that drive, though Dave Nanian of SuperDuper does say "booting from encrypted externals is not always reliable". > > > > And what about cloning? I have SuperDuper, > > No problem; I do it regularly. > > One caution though -- if you change the FV password, do not clone until you > have started from the clone copy and change its FV password. Failure to do so > will disable the drive in the following manner. You supply the old FV password > to unlock the drive but that is the wrong password for the associated account > so the startup process fails causing a reboot which... Here I'm confused again, perhaps because when I say File Vault I mean File Vault 2. I thought that did not have a password other than account passwords. Certainly Apple's instructions do not say anything about creating a password. -- <http://www.decohen.com> The Labyrinth of the Heart: Changed Myths for Changing Lives book and e-book <http://www.decohen.com/labyrinth> Send e-mail to the Reply-To address, not the From address.
[toc] | [prev] | [next] | [standalone]
| From | Tom Stiller <clusterfux.upmon@gmail.com> |
|---|---|
| Date | 2014-03-03 19:11 +0000 |
| Message-ID | <bnk2ftFn5buU1@mid.individual.net> |
| In reply to | #57525 |
>> > >> > And what about cloning? I have SuperDuper, >> >> No problem; I do it regularly. >> >> One caution though -- if you change the FV password, do not clone until you >> have started from the clone copy and change its FV password. Failure to do so >> will disable the drive in the following manner. You supply the old FV password >> to unlock the drive but that is the wrong password for the associated account >> so the startup process fails causing a reboot which... > > Here I'm confused again, perhaps because when I say File Vault I mean > File Vault 2. I thought that did not have a password other than account > passwords. Certainly Apple's instructions do not say anything about > creating a password. By changing the FV2 password I meant changing the account password of an FV2 permitted user, which also changes that user's FV password. I made the above mistake once but fortunately had a second FV2 permitted user and so was able to startup using *that* userID, then logout, login with the other userID using its new password and finally changer the user password to match that on the original drive.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-03-04 17:10 -0500 |
| Message-ID | <Y6KdnUlkaPna0ovOnZ2dnUVZ_rqdnZ2d@giganews.com> |
| In reply to | #57498 |
On 2014.03.03, 03:57 , Daniel Cohen wrote:
> What about security on external drives? As far as I can see, it is easy
> enough to encrypt a Time Machine drive and also external non-boot
> drives.
For my external drives (of late) I've been using a unique password
(long, random-mixed-case-numbers-symbols) with FileVault 2. I do not
save that password in Keychain - it is only in my noggin. If I forget
it, that data is lost.
If reusing a drive that was not encrypted before and that has my data of
any kind on it, I write random numbers over it twice using a quick and
dirty program I wrote. Then I set it up as a Filevault 2 drive to
encrypt new data written to it.
When the drives are retired, I'll simply "reformat" them (doesn't do
much) and pass them on to whoever needs them or disassemble for
recycling (metals/plastics to the recyc bin; electronics to the recovery
center).
I used to do violent things to disk platters before discarding them -
with a Filevault 2 volume I won't have that worry.
--
Privacy has become an essential personal chore that most
people are not trained to perform.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.sys.mac.system
csiph-web