hckrnws

TIL that OWASP has a bunch of Top 10 projects other than application security. Some others I found:

- Top 10 for LLMs - https://owasp.org/www-project-top-10-for-large-language-mode...

- Top 10 for OT - https://ot.owasp.org/

- Top 10 for Smart Contracts - https://owasp.org/www-project-smart-contract-top-10/

- Top 10 for Open Source Software - https://owasp.org/www-project-open-source-software-top-10/

I personally like the API one: https://owasp.org/API-Security/editions/2023/en/0x11-t10/

So many basic screwups.

A better link would be the dedicated site for it, also contains introduction which describes what NHI are: https://owasp.org/www-project-non-human-identities-top-10/20...

Ok, we've changed to that from https://owasp.org/www-project-non-human-identities-top-10/. Thanks!

Hah, turns out they're talking about stuff like access tokens, not otherkin!

Glad I wasn't the only one whose mind immediately jumped to "On the internet, nobody knows you're a dog"

On most of my platforms I try to make sure everyone knows :)

I especially enjoyed NHI10:2025 Human Use of NHI.

Time to stop all that pesky human use. Switch off the servers too, just to be sure.

Amusing nomenclature, but it's a legitimate concern. If your SREs use application credentials to connect to the database, your ability to have effective access controls and have accurate access audit trails are severely hampered.

This focuses mostly more on internal security (i.e after the attacker already has a foothold inside) versus the classic OWASP that are for external front fracing applications

It has long been consensus that perimeter security is an outdated concept. With servers in public clouds workers remote etc just assume that a breach could potentially happen and mitigate the potential damage - stealing credentials from a marketing guy should not result in root access to prod db.

They are using some fancy wording, but this just seems to be about regular service accounts (i.e. "bots") when they are mixed with user accounts in a SoA setting. No AI needed.

AI is not mentioned. Besides, service accounts are not bots.

The collection provides a structured approach to self audit the security practice regarding non-human identities. The recent CCC showcased breach of a VW connected car repository based on the exploitation of those NHI.

I agree. A bot is a program or an application that provides some sort of functionality that appears automated or autonomous in some way. A service account could be the primary identity of a bot, but that doesn't make it a bot.

I am confused with the wording. Is there an official description of Non-Human Identities?

I only known service accounts, which pose similar threat. Both AI and Humans can use service accounts and api-keys to pose the same threats.

But it's ultimately known and wide-spread as service accounts from what I know. Is non-human identity referring to a special case or attack vector?

Here is how OWASP define it:

> Non-human identities (NHIs) are used to provide authorization to software entities such as applications, APIs, bots, and automated systems to access secured resources. Unlike human identities, NHIs are not controlled or directly owned by a human. Their identity object and authentication often work differently to human, and common human user security measures do not apply to them.

https://owasp.org/www-project-non-human-identities-top-10/20...

I think it's just a fancy description for service accounts, but possibly extended to any kind of access that is used for machine-to-machine interaction rather than for users; I guess tokens used by IoT devices to access an API would also count as NHI. I guess that "Non-Human" doesn't imply any AI around (nor other animals or extraterrestrials, although I guess nobody thought that...).

they kind of mention various examples throughout, e.g.:

- such as service accounts and access keys

- such as API keys, tokens, encryption keys, and certificates

- typically achieved using static credentials or OpenID Connect (OIDC)

- sensitive NHIs such as API keys, tokens, encryption keys, and certificates

I would love to hear about any useful work around leak/abuse-resistance improvements of service accounts and API keys (i.e. the 'NHI' referenced here -- awkward terminology!). Passkeys are a great solution when some kind of end-user interactivity is feasible, and AWS Secrets Manager is supposedly very good if you're entirely on that platform, but for self-hosting, the options seem limited (and things like Hashicorp Vault still don't fully solve the problem)?

I recently refactored a moderately complicated system to remove the need for periodic distribution of updated network access credentials, and the best I could come up with were X509 client certificates, which (even if in this case it was a big improvement over the existing state of affairs) feel archaic...

Linters help in terms of detection. We’ve gotten a lot of mileage out of regularly running gitleaks, trivy and trufflehog over our repos

Another good source of NHI definitions, concepts, and threats https://nhimg.org/the-ultimate-guide-to-non-human-identities

It’s already wise to establish a shared authentication word or phrase with family and colleagues, because AI can now convincingly mimic a person’s face, voice, gestures, even their gait during video calls or phone conversations. A bot won’t know the secret passcode when you ask for it.

Within the next 20–25 years, you may need that same safeguard in face-to-face meetings, since Replicants will be lifelike enough to fool anyone.

Voight-Kampff Test: https://youtu.be/IbBfONITYNg

Please click through the link before commenting. NHIs have absolutely nothing to do with AIs masquerading as humans. This is basically about service accounts and API keys...

I did. And took it further and read the docs.. :-)

"Unlike human identities, NHIs are not controlled or directly owned by a human. Their identity object and authentication often work differently to human, and common human user security measures do not apply to them."

So this is about identities who are not human as they use those service accounts. Some would go as far as to say: AIs masquerading as humans.

Identities are very hard to manage and secure overall. Audits are super long, tedious.

Adding more dimensions into reviews that aren't properly done right now will be extremely tricky.

Shameless plug: I work to make this easier at https://www.slashid.dev/products/identity-protection/

And yes, you're absolutely right. Attempting to manage NHIs across multiple cloud/service providers without having proper automation in place is a total nightmare.

Wtf? We have been calling these workload identities for years.

Sorry but can anybody explain what Non-Human Identities are?

I think OWASP it self have pretty good explanation in their introduction chapter:

https://owasp.org/www-project-non-human-identities-top-10/20...

It's any user account you create that won't be used by a person.

Based on the title and the first few paragraphs, I expected this to be about risk of datacenter security breaches by Bears, and the like.

Mice and ants are listed as some of the greater enemies of the datacenter according to a pest control company's website. I guess bees would cause some inconvenience too.

Full title is "OWASP Non-Human Identities Top 10".

This comprehensive list highlights the most critical challenges in integrating Non-Human Identities (NHIs) into the development lifecycle, ranked based on exploitability, prevalence, detectability, and impact.

[dead]