Firmware password management

You have an EA that gets the firmware password? Sounds cool, how does that work? I wasn't aware that the firmware password is stored in plain text on the device.

@mschroder i found the passwords in install.logs (plain text), as a result of failed jamf policy.however i am not sure, how they come from.
I did few firmwarepasswd -verify and found they were correct.

Curious why you'd want to go from a unique password on every device to the same password. Information likes to be free and once you provide that password to the wrong person, all your Macs are vulnerable.

Actually you are correct.Its better to have a unique password rather than a single for all. But the issue is the passwords are not saved anywhere, they are randomly created.Hence i am planning to change them just to have them tracked.
@talkingmoose how you are saving/tracking the unique FW passwords? is there a way to save those ,apart from offline excel/csv?
I would like to know the best practice for that.
thank you

@Rohitds14, I have a script and an Extension Attribute to generate a random 8-character password and to capture it to Jamf Pro to the computer record. Once the script has run, the Mac needs to be restarted for the firmware password to activate.

https://gist.github.com/talkingmoose/7f3d4b75c22e21332a11117937765247

Thanks @talkingmoose , this is useful.
In my environment, the passwords are already set (randomly), and managed in excel. I believe this script will only work in FW password is not set only.

@Rohitds14 The following may prove helpful: Firmware Password Manager.

hi @talkingmoose ,
Thanks for the help, this working fine, Just an additional query, i believe the password is getting saved in a file in clear text.
can we encrypt that or anything else, So that the user does not stumble on the password.

@Rohitds14, I started to say, "Unfortunately, due to the way Extension Attributes work, we always have to have that file present. Otherwise, the EA will go blank."

However, it would probably be possible to write the script to encode the data on disk and then decode it when reporting it to the EA. I'll need to dig into it. Doesn't sound difficult, but will take some time to make sure it's right.

Could you add your comment to the comments section on GitHub for me? I'll take a look at what I can do.

thank you it will be awesome! @talkingmoose

Hi @talkingmoose, I'm looking at the possibility of implementing your awesome work. Something that's not clear to me based on the current version of the script on Github is around the temporary file and cleanup.

1. Is the firmware password obfuscated when the temporary file is created? If not, can it be?
2. I don't see a line in the script that cleans up the temporary file afterwards. Is this by design (e.g. does the file need to stay there to report back to Jamf using the extension attribute or is it simply looking for the .fp folder to show that the policy has ran?

Thanks a lot,
Justin.

@jtrant, if I'm still referring to that file as "temporary" in my instructions, that's my fault. It should reside there permanently.

I had hoped to make that file temporary, but later learned that I must choose to return something to a Jamf Pro extension attribute. A value is always returned and if I don't specify that value, it returns nothing and wipes out the password in Jamf Pro.

I'm looking at what it would take to store the password in a different format — possibly using something like Jamf's Encrypted Script Parameters.

No ETA yet on when I'll have a working encrypted solution, but I'm looking at it indeed!

managing firmware passwords is a nightmare because of how it is designed compounded by no one has really built a solid tool to manage them either. I would highly suggest not using firmware passwords unless you are contractually obligated to do so

Thanks @talkingmoose, appreciate your efforts on this. My issue is that our users are admins, and storing it anywhere locally is not possible in my case.

@tlarkin I agree that firmware passwords are a nightmare, but we are obligated to set them globally.

@jtrant yeah I feel ya, I had to do it at a previous job because we were told we had to, and we just did a master password for all Macs firmware. Luckily, at the rest of my jobs I have convinced the people that it is too much of a hassle and FV2, plus remote lock/wipe is pretty much all that is needed given the pitfalls of firmware password automation, maintenance and execution and that it is not securely done in any way with out building some sort of custom system.