Strong Passwords with SecAccessControlCreateWithFlags

Question

neil218 OP

Created 1w

Replies 4

Boosts 0

Participants 3

Hi everyone,

I’ve been working on storing keys and passwords in the macOS Keychain using the Keychain Services API. Specifically, I’m leveraging SecAccessControlCreateWithFlags to bind items to access control flags, and overall, it’s been working smoothly.

I have a question regarding the .applicationPassword flag of SecAccessControlCreateWithFlags. While it successfully prompts the user to input a password, there are no apparent password rules, even a simple “1” is accepted.

My questions are:

Is there a way to enforce strong password requirements when using the .applicationPassword flag?
If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input?
With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain, is there a way to store it in a file-based Keychain while marking it as unexportable?

I appreciate any insights or suggestions. Thank you!

Neil

Answered by DTS Engineer in 829937022

Written by neil218 in 776929021

Is there a way to enforce strong password requirements when using the .applicationPassword flag?

There is not.

I think that’d made a fine enhancement request.

If you do file an ER, please post your bug number, just for the record.

Written by neil218 in 776929021

If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input?

No.

But I suspect I’m missing something here. Let’s say you could do this, what would the workflow look like? Would you expect the user to remember this high-complexity password? That seems rather… well… brittle.

Written by neil218 in 776929021

With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain … ?

Correct. This is officially known as the data protection keychain. I recommend that you read TN3137 On Mac keychain APIs and implementations, which explains the backstory here.

Written by neil218 in 776929021

is there a way to store it in a file-based Keychain while marking it as unexportable?

No. The data protection keychain uses a completely different access control mechanism than the file-based keychain, and SecAccessControl is part of that data protection keychain model.

But, again, I suspect I’m missing some part of the big picture. What do you mean by “unexportable” here?

The file based keychain does support private keys where you can’t export the raw key bits, but that’s under a different name (extractable). And it only applies to keys, not passwords.

If you can explain more about your overall security goals, I may be able to offer better advice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

ciberseguridad OP

1w

Hello, I have no idea how to enforce that. At for example windows domains, there is a policy GPO that controls the password complexity but I think that you need to enforce the complexity before storing the password. I am new, so learning ;)

0

Answer 2

DTS Engineer OP

Apple

1w

Accepted Answer

Recommended

Written by neil218 in 776929021

Is there a way to enforce strong password requirements when using the .applicationPassword flag?

There is not.

I think that’d made a fine enhancement request.

If you do file an ER, please post your bug number, just for the record.

Written by neil218 in 776929021

If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input?

No.

But I suspect I’m missing something here. Let’s say you could do this, what would the workflow look like? Would you expect the user to remember this high-complexity password? That seems rather… well… brittle.

Written by neil218 in 776929021

With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain … ?

Correct. This is officially known as the data protection keychain. I recommend that you read TN3137 On Mac keychain APIs and implementations, which explains the backstory here.

Written by neil218 in 776929021

is there a way to store it in a file-based Keychain while marking it as unexportable?

No. The data protection keychain uses a completely different access control mechanism than the file-based keychain, and SecAccessControl is part of that data protection keychain model.

But, again, I suspect I’m missing some part of the big picture. What do you mean by “unexportable” here?

The file based keychain does support private keys where you can’t export the raw key bits, but that’s under a different name (extractable). And it only applies to keys, not passwords.

If you can explain more about your overall security goals, I may be able to offer better advice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

2

Answer 3

neil218 OP

1w

Thank you for the clear answers, I really appreciate the help!

For context, a client asked us to tie a key to an access control flag while enforcing a strong password. Alternatively, they wanted to store a key in the file-based keychain but ensure that the user couldn’t export it (e.g., as a .p12 file). We were exploring the feasibility of these options.

Now that we know it’s not possible, we can provide them with a clear answer. Thanks again for your support!

0

Answer 4

DTS Engineer OP

Apple

4d

Written by neil218 in 830408022

ensure that the user couldn’t export it

That is definitely an option for the file-based keychain. I’ve got code for it somewhere… OK, here we go… check out this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0