admin user should be able to change their password.

[v0lkan]

We'll ask for the old password for security.

[kfox1111]

The best part is no part.... Could we do away with the password entirely?

We have a spire server. We could use a jwt issued by spire for special admin access?

[v0lkan]

Thanks a lot @kfox1111, that's an intriguing idea.

We have a spire server. We could use a jwt issued by spire for special admin access?

SPIKE Nexus, a SPIFFE-enabled secrets store, relies on the SPIRE server for issuing identities (SVIDs) to workloads. The SPIKE Pilot binary already uses x509 SVIDs to identify itself, leveraging SPIFFE's robust service-to-service authentication capabilities.

However, human identity verification poses unique challenges. While workloads seamlessly integrate with SPIFFE’s identity model, humans require additional considerations for secure and practical authentication.

Here are some challenges:

Human Identity Verification

• SPIRE issues identities (SVIDs) for workloads, not directly to individuals.
• SVIDs, whether x509 or JWT, are designed for service-to-service authentication, not for human interactions.
• Assigning SVIDs to people is complex and not natively supported by SPIFFE.

Password as a Dual-Purpose Mechanism

Admin passwords currently serve two critical purposes:

• Authentication: Verifying the admin user’s identity.
• Key Recovery: Encrypting the root key for recovery scenarios. In cases where both SPIKE Keeper and SPIKE Nexus crash, an admin must provide the root key manually—a task not achievable with JWT SVIDs alone.

There are two things here, that makes the problem hairy:

• SPIRE lacks a built-in mechanism for users to directly obtain JWTs.
• A JWT-based solution addresses authentication but not the key recovery requirement.

--

I do believe that the ideal system ("the best part is no part") minimizes complexity; and until we get there, we still can balance usability, security, and feasibility:

We can:

1. Retain passwords as a fallback mechanism.
2. Leverage modern authentication methods for regular use.
3. Encourage gradual adoption of hardware-based or federated identity solutions.

For example;

As a primary authentication mechanism

• We can Integrate OIDC (OpenID Connect) using the SPIRE OIDC Discovery Provider:
  • Admin users authenticate via their organization’s Identity Management (IDM) system.
  • From the admin’s perspective, the experience remains intuitive and consistent.

On top of that we can:

• Retain passwords solely for root key recovery scenarios.
• Encrypt the root key using the password and securely store it in the backing store.

And as a cherry on the top, we can:

• Support hardware-based authenticaiton
  • Introduce support for hardware security tokens (e.g., HSM, TPM, YubiKey):
    • Tokens serve as an alternative to passwords for authentication.
    • Encourage adoption by admins for added security.

And in addition to all those, we can enable MFA by combining:

• OIDC for identity verification.
• Hardware tokens or passwords as a second factor.

--

But before we get there, it'd be good to have an admin password that conventional users can use in their dull conventional worlds :)

It's easier to trust machines than humans.

[v0lkan]

@jbeda had some ideas about this too by the way; if we can securely deliver SVIDs to humans; things would be easier.

What I have in mind is to use DNS TXT records for proof of self and SPIFFE ID issuance.

Or using an HSM/TPM was something else that was on my mind.

QRCodes was somethig I thought.

Another tangent I pondered whas whether an authority can actually issue SPIFFEID for people in SANs of certs (i.e.: spiffe://volkan.io/volkan.ozcelik ) if the CA that gives me the cert is trusted; I can authenticate with it as myself. But that would require a robust PKI for issuance and renewal.

But I'm wildly guessing, speculating, and thinking out loud at the moment.

[v0lkan]

Anohter idea:

• Hoomans receive a SPIFFE ID and an OTP (via email, SMS, or app).
• The OTP is used to claim or activate the SPIFFE ID.
• SPIRE verifies the OTP during the registration process.

Problem: how do you securely deliver the OTP?

--

spiffe over Blockchain: I feel it will cause more problems than it solves.

--

using NFC/RFID chips that has unique spiffeids. -- that would require convincing people to use hardware.

--

another option operating systems (or browsers) natively supporting spiffeids.

I mean, since I log in to my OS, my OS knows me, after some biometric attestation (fingerprint, retina scan etc) I can be issued an SVID that I can use wherever I want.

If any of you folks know anyone in cupertinoe that might be interested in this, we could initiate a discussion :) .

[kfox1111]

Thanks a lot @kfox1111, that's an intriguing idea.

We have a spire server. We could use a jwt issued by spire for special admin access?

SPIKE Nexus, a SPIFFE-enabled secrets store, relies on the SPIRE server for issuing identities (SVIDs) to workloads. The SPIKE Pilot binary already uses x509 SVIDs to identify itself, leveraging SPIFFE's robust service-to-service authentication capabilities.

However, human identity verification poses unique challenges. While workloads seamlessly integrate with SPIFFE’s identity model, humans require additional considerations for secure and practical authentication.

Here are some challenges:

Human Identity Verification

• SPIRE issues identities (SVIDs) for workloads, not directly to individuals.

Yes, but sort of....

In a pinch, a spire-agent with unix attestor can identify individual users. This may just be enough for admin identification for initial bootstrapping/recovery purposes.

• SVIDs, whether x509 or JWT, are designed for service-to-service authentication, not for human interactions.
• Assigning SVIDs to people is complex and not natively supported by SPIFFE.

Password as a Dual-Purpose Mechanism

Admin passwords currently serve two critical purposes:

• Authentication: Verifying the admin user’s identity.
• Key Recovery: Encrypting the root key for recovery scenarios. In cases where both SPIKE Keeper and SPIKE Nexus crash, an admin must provide the root key manually—a task not achievable with JWT SVIDs alone.

Ah. I see. This does conflate the two though and probably shouldnt?

I can see the need for Key Recovery. But, should this be the same string (password) used for an admin user? I'm thinking not.

I also think maybe there is a third thing being conflated here....

Lets take linux as an example. You may have multiple admins involved. You have root, the traditional admin, which is its own account, and hopefully is not used for anything except fixing something horribly broken. And then you have other admins, such as 'kfox', that can do things and occasionally sudo run something.

For admins, SPIKE is going to need:

1. named admins. so, for most things you know who is doing what. JWT will handle this well, using something like Keycloak, Entra, github, gitlab, facebook, etc, etc.
2. traditional admin, needed when things go horribly wrong to reenable named admins. I'm thinking, SPIRE issued jwt for a certain uid, on a certain machine, can fill this role, without needing anything else. It can be configured pretty much on the fly as things go wrong, and can even be removed when not needed. Example: SPIRE admin assigns spiffe://trustdomain/spike/superuser to unix:name:kfox on host spiffe://trustdomain/spiffe/agent/http_challenge/adminmachine.example.org for a bit, can do whats needed to recover the system, and then remove the entry again.

There are two things here, that makes the problem hairy:

• SPIRE lacks a built-in mechanism for users to directly obtain JWTs.
• A JWT-based solution addresses authentication but not the key recovery requirement.

--

I do believe that the ideal system ("the best part is no part") minimizes complexity; and until we get there, we still can balance usability, security, and feasibility:

We can:

1. Retain passwords as a fallback mechanism.
2. Leverage modern authentication methods for regular use.
3. Encourage gradual adoption of hardware-based or federated identity solutions.

For example;

As a primary authentication mechanism

• We can Integrate OIDC (OpenID Connect) using the SPIRE OIDC Discovery Provider:

  • Admin users authenticate via their organization’s Identity Management (IDM) system.
  • From the admin’s perspective, the experience remains intuitive and consistent.

👍

On top of that we can:

• Retain passwords solely for root key recovery scenarios.
• Encrypt the root key using the password and securely store it in the backing store.

We do need a solution to recovery. Just not sure passwords are the best way to do it. Especially passwords (plural)

And as a cherry on the top, we can:

• Support hardware-based authenticaiton

  • Introduce support for hardware security tokens (e.g., HSM, TPM, YubiKey):

    • Tokens serve as an alternative to passwords for authentication.
    • Encourage adoption by admins for added security.

A token isn't useful without someone vetting it....

Say I buy a YubiKey from Amazon. It is in no way associated with me until someone trusted creates that association. My org though, signed me up with their OIDC instance, checking my identity (drivers license, bills, passport, etc), and that on the YubiKey, and then associated Me, and the YubiKey with my identity in their own server. Now that server will vouch for me if I use that YubiKey.

IMO, SPIKE shouldn't be in that business. Its complicated to get right, and duplicates code/process other projects/orgs are doing. OIDC allows that to be completely outsourced and its up to the auth provider to do that, and we just trust the OIDC provider. As the SPIKE deployer, which OIDC servers to trust is the main concern I think?

And in addition to all those, we can enable MFA by combining:

• OIDC for identity verification.
• Hardware tokens or passwords as a second factor.

A lot of OIDC providers will already deal with the MFA bits themselves. Probably do not have to do anything specific there, keeping things simple. Admins can determine what level of trust there, by choosing which OIDC implementations(servers) they delegate to.

But before we get there, it'd be good to have an admin password that conventional users can use in their dull conventional worlds :)

It's easier to trust machines than humans.

Thats the problem with passwords. Your trusting a human, with limited memory, with a string a machine cares about and hope it stays secure. Thats proven hard. :/

I'm still thinking rather then a human with a password, we can find a way to have a small quorum of machines with independent secret material can reform the decryption keys. Then there need not be a human in the loop there at all.

A recovery pw in the very short term until that system is designed is ok, but should be killed as soon as it can be I think. And until that day, we need to figure out how to minimize that password to just the absolute bare minimal places it must be used to prevent it leaking out.

[v0lkan]

I'm still thinking rather then a human with a password, we can find a way to have a small quorum of machines with independent secret material can reform the decryption keys. Then there need not be a human in the loop there at all.

In our case assuming we have N keepers, unless N keepers fail simultaneously, the root key (and any other key) can "in theory" be recovered. So I geolocate (say) 6 keepers in 3 availability zones. Then I should be extremely unlucky to lose them all. --> that would sort out "do we need something to encrypt the root key?" problem. -- short answer: No, as long as we have enough keepers alive (that may also establish a quorum) we don't need any human to encrypt (or even know , or care about) the rooot key.
[1]

A recovery pw in the very short term until that system is designed is ok, but should be killed as soon as it can be I think.

Agreed.

And until that day, we need to figure out how to minimize that password to just the absolute bare minimal places it must be used to prevent it leaking out.

Agreed too.

---

I just scanned the rest of the message; will read it again and respond accordingly.

---

Also, if the trust boundary at the machine level, then we don't need separate passwords at all:

• Jonh Doe logs into his linux box.
• John Doe uses spike binary (that already has an SVID)
• Maybe Jonh Doe explicitly calls spike init for some auditing requirement; but spike init will not ask for passwords at all.
• End of story.

And since [1] solves the need to encrypt the root key, we won't need passwords ever.

My reasoning is:

• Some admin (Chuk Norris) has installed SPIRE and that admin also created registration entries for the spike binary. So that admin likely knows their $#!%; and therefore they have hardened access to the box that the spike binary is contained.
• SPIKE binary cannot be tampared, because its SVID attests for its linux hash, execution path, etc, etc.
• So the only attack vector is Jane Doe shelling into the machine and using the spike binary.

So we can still use a good old password, if it keeps people happy; but even with the password, if Chuk Norris has not set up the machine properly, Jane Doe won't be able to get/set any secrets.

So Jane's password reduces to just a random string to identify herself for auditing purposes, and nothing else.

If Jane gives her passowrd to Jack; then Jack will still have to log in to the machine. So Jack will have to pass Chuck Norris before he can even use SPIKE.

[v0lkan]

Key @kfox1111 I had a chance to think about this a bit.

Here are my comments:

In a pinch, a spire-agent with unix attestor can identify individual users. This may just be enough for admin identification for initial bootstrapping/recovery purposes.

That's a good idea. The admin user should already have an SVID for "their" user anyway.

For example the following entry identifies the user:

# [exhibit 1:]

# Register SPIKE Pilot
spire-server entry create \
    -spiffeID spiffe://spike.ist/spike/pilot \
    -parentID "spiffe://spike.ist/spire-agent" \
    -selector unix:uid:"$(id -u)" \
    -selector unix:path:"$PILOT_PATH" \
    -selector unix:sha256:"$PILOT_SHA"

So the fact that the user can use the SPIKE Pilot (the spike binary) indeed means that they are authenticated. They don't need a password to further authenticate themselves. (reasoning: they cannot be that user unless they log in to the unix box -- the trust boundary is the box itself)

So I think, we should be EXPLICIT in stating that the password is for KEY RECOVERY ONLY. And the admin could opt out if they want to (because it's not the only way to recover a key: For example, I can provide SPIKE my public key and ask it to encrypt the root key for me instead later; OR I can provide a password later with a spike recover command instead of directly at initialization OR we can have N-keepers to keep the key OR we can have an upstream SPIKE to store the key as a secret... I am sure that part is figureoutable)

This does conflate the two though and probably shouldnt?

Possible :)

named admins. so, for most things you know who is doing what. JWT will handle this well, using something like Keycloak, Entra, github, gitlab, facebook, etc, etc.

^ that needs to be a user story on its own. We can start experimenting with keycloak and see how it goes from there. An OIDC is an OIDC is an OIDC anyway -- how different can they be :)

traditional admin, needed when things go horribly wrong to reenable named admins. I'm thinking, SPIRE issued jwt for a certain uid, on a certain machine

I think [exhibit 1:] is good enough to secure the traditional admin.

We can have a SPIFFE ID like spiffe://spike.ist/spike/pilot/role/superuser. It does not even have to be a JWT SVID. Someone who can talk to SPIKE can assign/unassign it.

So. If hell broke lose, I'll assign myself a superadmin SVID; fix stuff, and then unregister that SVID.

For named admins, we'd need OIDC, which can wait for a while. For now, one superadmin is good enough.

A token isn't useful without someone vetting it....

Yes, and I agree that it's not worth introducing to complexity, unless either of us want to found a TPM/human-id startup (which is not a bad idea ideed :))

Thats the problem with passwords. Your trusting a human, with limited memory, with a string a machine cares about and hope it stays secure. Thats proven hard. :/

LOL, but agreed.

--

So in short, the above approach I think...

1. will eliminate need for password.
2. will push identifying the superadmin to their unix credentials (one who owns the box owns spike, provided someone who owns spire let them own spike -- I like the multi-level access approach. So if I have login access to the box, but not to SPIRE, then the SPIRE admin can remove my access if I turn out to be a bad superadmin :) -- but in reality I will be the alpha and the omega (both SPIRE admin and also linux user))
3. root key backup and rotation is figureoutable and FFS.
4. named admins are figureoutable and FFS.

--

I'll think about it a bit more and create necessary user stories.