There are millions of unfilled cybersecurity roles, yet capable entry-level candidates are rejected every day.

The industry publicly claims a severe skills shortage while quietly filtering out anyone who has not already been trusted elsewhere.

That is why “entry-level” roles demanding three to five years of experience are so common.

This is deliberate risk avoidance in a field where one bad hire can be catastrophic.

If you approach this market like a normal entry-level job hunt, you will keep failing for reasons no one is incentivized to explain. This post explains how security hiring actually works, and how to work within it.

At the end of this post, you will understand:

• Why cybersecurity hiring behaves differently from software and IT

• Why trust, not skill, determines who gets hired at the junior level

• How elite hiring culture quietly shut the door on newcomers

Entry-level, 5 years required.

You may have heard the stat: 3.5 million unfilled cybersecurity jobs globally.

And yet you apply to dozens of roles, get ghosted by most, and rejected by the rest for “lack of experience.” This happens across tech, but it is far more pronounced in cybersecurity. That is not an accident.

Here’s what’s actually happening: cybersecurity hiring is not a talent market. It’s a risk market. That single reframe changes everything.

When I was a security manager at Amazon building out my team, I reviewed hundreds of resumes every week for a handful of critical roles. Even when the role demanded seniority, the bar was unforgiving. The more relevant the experience, at scale, in complex environments, the better. Not because junior candidates lacked ability, but because I could not afford the risk. The role did not allow for learning on the job.

That is how most security hiring works.

Hiring managers aren’t optimizing for growing talent primarily. They’re optimizing to avoid blame. If they hire a senior and something goes wrong, that’s bad luck. If they hire a junior and something goes wrong, that’s bad judgment.

Software engineering, arguably, tolerates iteration and mistakes better. In cybersecurity, being 99% times right can still be a failing grade.

The “skills gap” is not about skills. It is about risk tolerance. And as the stakes rise, risk tolerance collapses.

The system is not broken. It is working as designed.

But this still leaves an obvious question. If security hiring is about avoiding risk, who absorbs that risk?

The answer is predictable.

Juniors

In any risk-averse system, uncertainty gets pushed to the edges. In cybersecurity hiring, juniors are that uncertainty.

I’m not here to tell you the system should change. I’m here to tell you how to win within it. But first, you need to understand why you keep losing.

Training juniors is expensive in ways job descriptions never mention. Seniors lose hours to mentorship they can’t afford. Every new hire with access expands the attack surface security teams are supposed to shrink.

But the real killer is asymmetric consequences. The junior makes the mistake. The manager owns the fallout. No one gets promoted for taking a risk on a junior. People absolutely get fired when that risk goes wrong.

Many teams would rather stay understaffed than take on unknown risk. That open role might stay open for 18 months because “nobody qualified applied” is an easier conversation than “I hired someone junior and they caused an incident.”

This is not fair. But it is rational. And there’s another layer making it worse. One that has nothing to do with risk math and everything to do with culture.

Culture eats strategy for breakfast. And juniors for lunch.

I spent years at Amazon and served as a Bar Raiser. For those unfamiliar: Bar Raisers are trained interviewers who sit on hiring loops to ensure every new hire raises the functional bar (Are they better than 50% of their would-be peers in similar roles?), and, that they have the long term growth potential in the company through cultural fit. When everyone shares the same mental models, you move faster in a crisis.

I remember one candidate who was deep functionally and a strong coder. But across multiple interviews, he hadn’t shown the builder mindset. No ownership signals. No inherent leadership qualities. The hiring manager wanted to hire fast and focused only on technical skills and made an argument to hire the candidate. I pushed back - amazing tech skills don't automatically raise the bar on culture. We did not hire the candidate.

That system works at Amazon because Amazon invests on both sides. High bar plus high support. Rigorous interviews plus intensive onboarding, and a bazillion mechanisms (like automated tools, paved road solutions) that prevent mistakes from becoming real incidents.

Here’s the problem: many companies copied Amazon’s filter, but few copied Amazon’s investment. Smaller companies adopted elite hiring standards without the onboarding, mentorship, tooling, or safety nets that make them survivable. Risk aversion plus borrowed elite culture equals an industry hostile to beginners.

To Wrap It Up

The skills gap is real, but not how you’ve been told.

There’s no shortage of people who want security jobs. There’s a shortage of people that hiring managers feel safe betting on.

Security hiring avoids risk by design. Juniors are excluded rationally. Elite culture tightened the gate without adding support.

This is not your fault. But it is your problem.

Here’s the one key insight from this post: In cybersecurity, trust is the entry-level requirement. You don’t convince security teams you’re smart. You convince them you’re safe. Every resume bullet, every interview answer, every portfolio piece should answer one question: why is hiring me lower risk than hiring nobody?

In Part 2, I’ll break this down into two practical paths. One for entering security from adjacent roles. One for borrowing credibility when you have none.

Your neighborhood security nerd,

Aditya :)

I spent two years mastering buffer overflows and hunting cross-site scripting vulnerabilities at Johns Hopkins University’s Information Security Institute. I spent my first week on my first job after grad school learning how to write emails that don't piss people off.

Guess which skill mattered more?

No one told you what actually happens when you leave the classroom and enter the corporate world. So I will.

This isn’t a rant against formal education. Your professors did their best. Cryptography matters. Network protocols matter. Buffer overflows and the math you suffered through? It matters too. But there’s a gap between getting your cybersecurity degree and surviving your first year in the trenches.

At the end of this post, you will master:

• Why technical skills are table stakes, not the game

• How to speak “business” to executives and senior peers

• What the daily grind actually looks like (spoiler: it’s not hacking)

Dave From Accounting Will Wreck You

Here’s something your textbooks and curriculum didn’t emphasize: humans are the variable that breaks every perfect security model (a relatable story from Chipotle on this).

You learned AES-256 encryption. Same Origin Policy. Buffer Overflows. All good stuff. Everything you need for a solid foundation. But 60% of security breaches involve a human element (as per Verizon DBIR Report 2025). You can build the most elegant architecture in the world, and yet Dave from accounting clicking a phishing link on a Friday afternoon undoes all of it.

And if people are your biggest vulnerability, then the people who control your budget are your biggest constraint. Which brings us to stakeholders.

The Email That Almost Broke Me

Early in my career, I was a consultant doing security assessments. Found a gap. Wrote the recommendation. Sent the email to the relevant team and included a senior leader for visibility.

My phone rang within the hour. The senior leader was yelling. Yelling. They thought I, a lowly outside consultant, was ordering them around. The recommendation wasn’t even for them. They were just CC’d.

Was I technically correct? Yes. Was my communication wrong? Also yes.

Being right doesn’t matter if you can’t bring people along. Security is a team sport. The team includes executives with their own pressures, egos, and priorities.

This extends to budgets. Security is a cost center. Sales generates revenue. You - in security - generate... fewer bad things happening?

You’ll spend a surprising amount of your career translating technical vulnerabilities into business impact. “SQL injection vulnerability” means nothing to a CFO. “A $4 million regulatory fine and a Wall Street Journal headline” gets attention.

But even when you get their attention, you’ll face the next reality: trade-offs.

Security Is a Trade-Off Problem

School presents security as a goal. Industry treats it as a negotiation.

This took me years to internalize. I used to think my job was finding every vulnerability I could and demanding fixes. Wrong. My job is helping the business make informed decisions about risk.

Sometimes they need to ship next month. Sometimes the “right” fix requires six months of re-architecture. Sometimes the legacy system held together with duct tape processes $50 million daily.

I’ve had this conversation hundreds of times. A gap exists. The real fix is substantial. The business can’t wait. So we negotiate: band-aid now, medium-term mitigation, long-term fix.

Here’s what they really don’t tell you: the long-term fix almost never happens on its own. Never. “Temporary” mitigations become permanent fixtures for years. The only way real fixes happen is through top-down leadership mandates. Someone with authority saying “this is a priority” and keeping the pressure on.

Risk acceptance is real. Sometimes the business accepts a risk because fixing it costs more than the potential impact. Your job isn’t preventing that decision. Your job is making sure it’s informed and documented.

All of this sounds strategic. But most of your days won’t feel strategic at all.

The Hacker Hoodie Is a Lie

I need to address the elephant in the room: the hacker fantasy.

You’ve seen the movies. Hoodies. Dark rooms. Green text on black screens. Here’s reality: most of your time will be logs, tickets, and spreadsheets.

Security operations means staring at dashboards. Triaging alerts (mostly false positives). Writing documentation nobody reads until something breaks. Explaining the same risk to the same people for the third time this quarter.

The career paths are diverse and evolving. Engineers build systems. SecOps monitors threats. Privacy specialists handle data ethics. Forensics reconstructs incidents. Red teamers emulate attackers. But everyone, at every level, spends time on operational grind.

You’ll generate tickets. Automate repetitive tasks. Update spreadsheets tracking remediation. Glamorous? No. Necessary? Absolutely.

And then, eventually, something goes wrong.

When It Hits the Fan

At some point, there will be a breach.

School walked you through frameworks. NIST has a nice four-phase model. Clean. Logical. Real incidents are chaos.

You’re investigating while containing while communicating while documenting while someone important wants updates every fifteen minutes. Pressure is intense. Information is incomplete. Decisions have direct consequences.

And remember Dave from accounting? He’s usually involved. Most incidents trace back to human error, not sophisticated nation-state attacks. Someone clicked something (MGM Resorts 2023 Ransomware incident). Someone misconfigured something (Capital One 2019 break). Someone reused a password (Colonial Pipeline 2021 Ransomware attack).

The glamorous hacking you imagined? Rare. The mundane human mistakes? Constant.

This brings us full circle: security is about people. Protecting them from threats. Protecting systems from their mistakes. Convincing leadership to fund the work. Managing your own energy, health and motivation while doing it.

You’re running a Marathon

Careers here are rarely linear. I started as a developer. Became a pen tester. Now I'm in security architecture. The path was anything but straight. I’ve met pen testers who became privacy officers. Network engineers who became CISOs. Developers who stumbled into AppSec and never left.

But I need to warn you about burnout. Security is always-on. Threats don’t respect business hours. The stress of being a digital firefighter accumulates. Set boundaries. Find employers who respect them. This is a marathon.

The landscape shifts constantly. Now, AI is changing everything and new attack vectors are emerging.

Skate to where the puck is going. The people who thrive are the ones who never stop learning.

To Wrap It Up

Your degree gave you a foundation. But you’ve only learned half the job.

The other half is people: understanding them, protecting them from themselves, convincing them to fund your work, communicating risk without making enemies.

None of this means education was wasted. It means education was the beginning.

Welcome to the real world. It’s messier than the textbooks. But it’s more interesting too.

- Your neighborhood security nerd, Aditya :)

In the early 1900s in British India, the government faced a deadly problem: too many venomous cobras. Their solution seemed logical. They offered a cash bounty for every dead cobra brought in.

It worked initially. The snake population dropped. But then, the locals grew inventive. They started farming cobras to kill them and collect the bounty. When the government realized this and scrapped the program, the breeders released their worthless snakes into the wild. The result? The cobra population ended up higher than before the program started.

This is the classic cautionary tale of Goodhart’s Law. Most cybersecurity programs fail for this same simple reason. They violate Goodhart’s Law.

When a measure becomes a target, it stops being a good measure.

I’ve seen this play out repeatedly in many security teams. We introduce metrics to understand risk, and over time those same metrics quietly become goals. Once that happens, behavior shifts. Often not because people are careless or trying to cheat the system, but because they are responding rationally to the incentives in front of them. Basic human behavior.

The Problem: Performance Theatre

Think about the metrics many of us rely on in cybersecurity. Vulnerability counts. Open Critical/High findings. Phishing simulation click rates. Unpatched libraries. Asset coverage percentages. None are inherently wrong. The problem starts when success is defined by improving the number rather than reducing real risk. Teams naturally focus on what is easiest to fix, while harder, more structural issues get deferred.

This is how performance theater creeps in. I’ve watched teams close tickets at impressive speed while long-standing architectural weaknesses remained untouched. Dashboards looked healthy. Reports reassured leadership. Meanwhile, the most critical systems were still exposed. Security improved on paper, not in reality.

The same pattern shows up in awareness programs. In environments where phishing metrics are enforced too aggressively, people stop reporting real emails because they fear being penalized. The measure that was supposed to improve security ends up eroding trust and weakening detection.

The Solution: Tug of War Metrics

The strongest teams I’ve worked with design explicitly for this failure mode. They don’t abandon metrics, but they refuse to let any single metric stand alone. Every measure is paired with a counter-measure that pulls behavior in the opposite direction, a “tug of war” that forces balance.

• If you track Mean Time to Remediate (MTTR), you must also track Incident Recurrence. (Did we fix it fast, or did we just put a band-aid on it?)

• If you track Vulnerability Counts, you must also track Exploitability. (Are we fixing what matters?)

• If you track Alerts Closed, you must also track Detection Gaps. (Are we clearing the queue or missing the signal?)

This balance is intentional. Competing metrics create tension, and that tension forces judgment. Judgment is where real security decisions happen. Without it, numbers become a substitute for thinking.

Culture matters more than most dashboards will ever show. If security makes it difficult for engineers and operators to do their jobs, they will work around it. I’ve learned to pay attention to friction. How hard is it to do the right thing securely? The answer tells you more than most KPIs.

The Takeaway

If your security dashboard always looks calm and green, that is not reassurance. It is a question. Real systems are noisy. Real risk is messy. Goodhart’s Law is your reminder to stop polishing the glass and start listening to the signals underneath it. Balance creates truth.

The OWASP1 Top 10 list for 2025 has been released, four years after its previous iteration. The list is a general assessment of significant risks in web application security. Its structure and changes from the 2021 list offer insight into the state of the industry, highlighting areas where we are improving and, more often, where we continue to fail. These are my brief thoughts on the list in general.

1. Broken Access Control (A01:2025) 👑

Broken Access Control occurs when an application fails to enforce restrictions on authenticated users, allowing them to act outside their intended permissions. This includes bypassing authorization checks, accessing unauthorized resources, or performing privileged actions without proper validation. Examples include authorization bypass using Insecure Direct Object Reference.

This category remains at the top, which speaks volumes about the difficulty of implementing effective authorization models in complex systems. It now incorporates the 2021’s No. 10 Server Side Request Forgery (SSRF).

2. Security Misconfiguration (A02:2025) ⚙️

Security Misconfiguration refers to improper implementation of security controls across any layer of the application stack: network, web servers, databases, or cloud configurations. Examples include default credentials, public cloud buckets, missing security headers, misconfigured CORS policies, or unnecessary features enabled (e.g., verbose error messages, admin interfaces).

This category is a notable jump from #6 to #2. This is less a failure of technology and more a failure of process. Misconfigurations, such as leaked credentials, are a direct result of complexity. The axiom “complexity is the worst enemy of security” holds true here.

3. Software Supply Chain Failures (A03:2025) 📦

Software Supply Chain Failures refer to security risks introduced through third-party components, libraries, tools, or services integrated into an application. These failures occur when external dependencies are compromised, outdated, or poorly managed, leading to vulnerabilities that propagate across systems.

This category expands on 2021’s “Vulnerable and Outdated Components.” The SolarWinds and Log4j incidents demonstrated the systemic risk of modern software development and spiral dependencies. We are building systems with components we do not control or fully understand - a robust third party risk management is needed here.

4. Cryptographic Failures (A04:2025) 🔑

Cryptographic failures refer to the improper implementation, configuration, or usage of cryptographic mechanisms intended to protect data in transit or at rest. This includes weak or outdated algorithms, insecure key generation or storage, missing encryption altogether (sadly still prevalent), or misuse of protocols (TLS 1.2 vs TLS 1.3).

This category has dropped two slots from #2 suggests some progress, but this area remains critical. The core problem often lies not in the algorithms themselves but in their implementation and key management. Dance like no one is watching. Encrypt like everyone is.

5. Injection (A05:2025) 💉

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. This allows attackers to alter the intended logic of the program, often leading to unauthorized access, data leakage, or system compromise.

Injection attacks have been a known risk for decades; this category has dropped 2 slots from 2021’s No. 3 (and 2017’s No. 1). They includes a range of issues from Cross-site Scripting (high frequency/low impact) to SQL Injection (low frequency/high impact) vulnerabilities. “Prompt Injection” for LLMs is no. 1 in the OWASP Top 10 for LLM 2025 list - so injection attacks as a category are not going anywhere unfortunately.

6. Insecure Design (A06:2025) 📐

Insecure Design refers to flaws in the architecture and design of an application that create inherent security weaknesses, regardless of how well the implementation is executed. Unlike implementation bugs, insecure design is about what is built, not how it’s built. Examples include client-side enforcing security logic, lack of authentication or authorization mechanisms consistently, absence of secure defaults, direct object reference without access control, missing logging at key interfaces, etc.

This category, introduced in 2021, reflects the industry’s growing recognition that security needs to be considered at the design phase, not as an afterthought. This requires a shift in mindset across the development lifecycle.

7. Authentication Failures (A07:2025) ✅

Authentication failures occur when an application incorrectly implements identity verification mechanisms, allowing attackers to compromise credentials, bypass login systems, or impersonate users.

This categories is in a steady position on the list at #7. Despite improvements through standardized frameworks (like OAuth2, OpenID Connect, and SAML), misconfigurations and poor implementation still expose systems to brute-force attacks, credential stuffing, and session hijacking. The risk is amplified in APIs and mobile apps where tokens and credentials are often mishandled.

8. Software or Data Integrity Failures (A08:2025) ⚖️

Software or Data Integrity Failures occur when a system fails to adequately protect the consistency and trustworthiness (“integrity”) of its code, configuration, or data, particularly when processing input from untrusted sources or updating code components. This includes issues like allowing unverified serialization-deserialization of sensitive objects, failing to use cryptographic checks (like hashes or digital signatures) on firmware updates, or trusting input without validation, encoding, or proper type and schema verification.

This category is remaining at #8. It emphasizes the need to verify the integrity of data and code. In this AI era (yes, I said it - AI era) , where data poisoning can have significant consequences, ensuring data has not been tampered with is essential for trustworthy systems.

9. Logging & Alerting Failures (A09:2025) 🚨

This vulnerability arises when security-relevant events are not properly recorded, monitored, or acted upon. It includes missing, insufficient, or improperly configured logging mechanisms, as well as the absence of timely alerting systems that can detect and escalate suspicious activity.

This category has a slight name change (previously “Security Logging and Monitoring Failures”). Per OWASP, the name change emphasizes the necessity of detection as well as response capabilities. It is not enough to simply log events; we need effective alerting mechanisms to identify and act on security incidents in a timely manner. Great logging with no intelligent alerting is of minimal value.

10. Mishandling of Exceptional Conditions (A10:2025) 🤯

Mishandling of Exceptional Conditions occurs when systems fail to properly handle unexpected or abnormal conditions. Examples include failing to roll back failed operations entirely, exposing detailed stack traces in error messages, or allowing race conditions where the security state is incorrectly calculated or manipulated.

This category is a new entry on the list. This points to the need for systems to fail securely (a secure design principle) and handle unexpected events gracefully. Flaws here can lead to race conditions or replay attacks - this precise concept led to a recent cloud outage. It’s a reminder that security must consider not just the “happy path” of system operation, but also what happens when things go wrong.

So what?

The OWASP Top 10 is a useful tool for prioritizing security efforts. But the list itself is a symptom of a larger, systemic problem: our inability to build secure software in the first place. The 2025 update shows that while some categories shift, the core issues remain stubbornly familiar: access control, misconfiguration, supply chain risk, and insecure design. These are not just technical problems - they’re organizational, procedural, and cultural. We must move beyond simply addressing this list and start addressing the fundamental engineering and process issues that generate these vulnerabilities.

👋 Dear reader, hope you’re healthy and happy. In this post we will cover:

• What is Aadhaar biometric system of India (think: SSN on steroids)

• How Aadhaar access is expanding

• Privacy quagmire it will lead to

Buckle up!

Imagine you walk into a bar. Not just any bar, but one where they don’t check your ID at the door. Instead, they scan your face, fingerprint, and maybe even ask for a DNA sample just to serve you a beer. The bartender assures you it’s all for your own good—better service, no fake IDs, and an overall smoother experience. You hesitate, but hey, the beer is cold, and you don’t want to be that guy making a fuss.

Next thing you know, every bar in town starts doing it. Then the donut shops. Then restaurants, grocery stores, and even gas stations. Soon, it’s impossible to buy anything without handing over your biometrics. And the kicker? You never explicitly agreed to any of this. You just wanted a drink.

That, in a nutshell, is the Aadhaar expansion story in India.

Aadhaar, a 12-digit identity system, is linked to the biometrics of more than 1.4 billion people in India. Let that number sink in for a moment. It’s 2x the population of entire Europe. And 4x the US population. Imagine if your Social Security number was paired with your fingerprints and iris scans, and then made available not just for government services and core services (like banking) but also for private businesses e-commerce apps, concert tickets or pizza delivery.

Originally, Aadhaar was supposed to be a simple fix for an age-old problem: making sure government subsidies reached the right citizens. And it is true that Aadhaar has made life simpler, it is an ID that's accepted everywhere in the government. I recall once trying to get my Indian passport renewed and struggling to keep up with which ID is accepted where.

Over time, though, private companies like banks or cellphone companies started tapping into the Aadhaar database to verify customers. A landmark Indian Supreme Court ruling in 2018 thankfully put strict limits on that practice.

Now, in 2025, the Indian government has decided to loosen those restrictions again. Private companies in e-commerce, healthcare, travel, and hospitality will be able to use Aadhaar authentication to verify customers.

From the original Press Release:

The amendment enables both government and non-government entities to avail Aadhaar authentication service for providing various services in the public interest for related specific purposes like enablement of innovation, spread of knowledge, promoting ease of living of residents and enabling better access to services for them.

No evaluation criteria:

Any entity seeking Aadhaar authentication will be required to apply with the details of intended requirements to the concerned ministry or department of the Central or the State government in a format being made available on a portal for this purpose. The applications will be examined by UIDAI and MeitY will issue the approval based on the recommendation of UIDAI.

The government promises this will improve service delivery, reduce fraud, and make life easier for the average citizen. Because why wouldn’t you want to trust your personal data - fingerprints, iris scans, and all - to a bunch of businesses? It’s not like data breaches ever happen, right?

It sounds like progress, until you start asking the hard questions.

Privacy advocates, including yours truly, are nervous. We worry this shift could resurrect elements of the Aadhaar Act that the Indian Supreme Court had already struck down. The Indian government insists all businesses must apply for approval before using Aadhaar authentication, but the criteria for approval remain murky. Who gets access? How will they be monitored? What happens if they misuse it? All valid concerns, all largely unanswered.

A leaked password you cannot ever change

India’s colossal population makes the stakes enormous. In the US, people might fear identity theft if their Social Security number falls into the wrong hands. Multiply that fear by a factor of a billion, and toss in biometric data that can’t exactly be changed if leaked.

Meanwhile, a comprehensive data protection law in India is still pending to be fully operational. So, we now have a system where private companies will have broader access to sensitive biometric authentication, while the rules on how they should handle that data remain vague at best. We are building a highway and punting the traffic laws to later.

Then there’s the issue of voluntary usage. Technically, Aadhaar authentication remains optional. But what happens when private businesses start making it the easiest, or even the only, way to access services? Just as you could technically not use Aadhaar to get a SIM card or open a bank account, but good luck finding a hassle-free alternative, this could quickly become a “voluntary” requirement. That’s how de facto mandates work. You don’t have to comply, but life sure gets a lot harder if you don’t.

India’s experiment is unfolding in real-time. On one hand, it could spark a wave of new tech innovations and supercharge online services. On the other, it tests the boundaries of privacy and fairness on a massive scale. Nobody wants to be locked out of essential services because of a technical glitch, nor do they want Big Brother (or Big Business) tracking their every move.

So, coming back to the bar.

At first, handing over a fingerprint for a beer seemed harmless. But now, every business in town wants a piece of that data, and opting out is becoming less of a choice. Before long, you start wondering: was the convenience really worth it? Or did we all just trade a little too much privacy for the promise of a smoother experience?

Aadhaar is at that tipping point. The system has undeniable benefits, but this latest expansion could be a turning point, either towards seamless, secure digital identity verification or a sprawling privacy crisis waiting to happen.

And once you hand over your data, there’s no taking it back.

Dear, reader.

I had the pleasure of talking about AI safety at BsidesNYC23 in New York city on Apr 22, 2023.

Abstract: ChatGPT is here to stay. With the increasing reliance on Artificial Intelligence everywhere, it is crucial to consider the security and privacy implications of generative AI. The talk will cover potential misuse of AI: spreading false information, abusing its capabilities to assist with security attacks such as phishing or malware, and the difficulties in detecting and mitigating malicious input and output.
The goal of this talk is to increase awareness and understanding of the security challenges with generative AIs. And to encourage efforts to ensure the safe and secure use of these powerful tools.

Here’s the talk recording.

And, here is the slide deck.

Bsidesnyc23 The Dark Side Of Chatgpt Aditya Patel

5.05MB ∙ PDF file

Download

Download

Please reach out if you’ve any questions/comments.

Bill Gates recently wrote an excellent essay: The Age of AI has begun

While I respect the positive outlook the essay presents, I don’t full agree with everything. Here’re my top takeaways and a quick hot take.

📍 AI is the next big thing. Bill Gates draws parallels between the impact of AI and previous technological revolutions, and anticipates that AI will have a profound and pervasive influence on every aspect of human life and society in the next decade.

The development of AI is as fundamental as the creation of the microprocessor, the personal computer, the Internet, and the mobile phone.

(source: The Age of AI has begun)

📍 AI will help the society at large. He explores some of the potential benefits of AI for addressing some of the world’s biggest challenges, such as reducing child mortality, improving education, fighting climate change, and advancing scientific discovery, and provides some concrete examples of how AI is already making a positive difference in these areas. Like, the AI powered ultrasound machines that can help save mothers and their babies in low-income, remote areas.

📍 AI safety. He also recognizes some of the potential risks and challenges of AI, such as ethical dilemmas, social implications, job displacement, and malicious use, and urges governments, businesses, and individuals to prepare for them by investing in research, education, regulation, and ethics.

This last point stands out.. overall, the essay is great, but to some extent downplays the risks of AGI - Artificial General Intelligence (for my own opinions and biases as a security professional at least). For instance, risks with AGI are not sufficiently explained

… we’ll have an incredibly powerful AGI. It will be able to do everything that a human brain can, but without any practical limits on the size of its memory or the speed at which it operates.

(source: The Age of AI has begun)

AI poses serious threats and challenges like: biases, hallucinations, misinformation, and privacy implications.. ChatGPT has shown that AI is awesome and has almost unbound capabilities, but we should be more cautious and critical.

What do you think?

📕 Security Wale is a blog about cloud, cybersecurity, and in between - written by Aditya Patel (more here). To support this effort, consider subscribing (it’s free) and spreading the word.

👋 Dear reader, hope you’re healthy and happy. In this post we will cover:

• What is threat modeling, and why you should care

• Why is it unique and complex

• How to do threat modeling, and a simple mental model for it.

Buckle up! 

Threat modeling, in cybersecurity, is a process of identifying, and mitigating potential threats to a system.

It is one of the many security activities, like SAST (Static Application Security Testing) aka secure code reviews; and DAST (Dynamic Application Security Testing) aka penetration tests. There are also techniques like runtime analysis or dependency checks, more relevant for microservices. And bug bounties, and IR gamedays among a few others. Among all these, threat modeling holds its place firmly.

Why do we need threat modeling? It’s all about money, baby. Also security. The primary objective of threat modeling is to identify potential security weaknesses early and address them before they become too expensive to fix. It also helps identify issues that cannot be found by other security activities by looking at design of a system. Like this ingenious #crappydesign below. No pentest or code review will find an equivalent issue, threat modeling will.

Not just that, the Open Web Application Security Project (OWASP), a non-profit security organization, produces a list of top 10 most critical security risks to web applications. The list is produced every 3-4 years and is widely used in cybersecurity. In its latest edition, “A04:2021 – Insecure Design” is a new entry at #4.

A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.

(Source: OWASP / emphasis in bold mine)

So we understand why Threat Modeling is important. However, of all the security activities, it’s the wierdest: unique and complex.

Threat Modeling is unique because

• It cannot be fully automated (yet), as it requires an analysis pedigree of humans.

• It is simple to learn, but difficult to master. Just like learning how to drive or swim. (But unlike chess, which is also simple to learn, but very difficult to master)

• It’s a human-centric security activity. 

• There are many, many techniques available for it. All are cumbersome.

Threat Modeling is complex because there are a bazillion ways to do it. Few popular threat modeling methodologies are Attack Trees (Schneir, 1998/99) which is an attacker centric visualization of threats; STRIDE (Microsoft, 1999) which is a developer centric mnemonic to cover basic security categories; ATT&CK framework (MITRE, 2013) is an intrusion centric knowledge base of tactics and techniques; and PASTA (Versprite, 2015), which is a risk centric threat modeling process popularly used at Gitlab. There are at least 10 others that I have come across, plus tens of their custom variations. Moral of the story is that there is no one size fits all. Probably some lead security architect in your organization preferred one approach over the other and introduced it - and now you’re stuck with it.

In all of these techniques though, the goal of the threat modeling is common:

To wear an attacker’s hat, and list out threats, rank them, and create practical mitigations.

A simple mental model

Over the years, I have developed a mental model that can be applied agnostic to the various techniques above. Obviously, this is what has worked for me and I am simply sharing it, not to introduce yet another technique, rather to share my learnings in a condensed format. First, follow these steps to build a threat model.

🗺 Step 0: Architecture - Find what to threat model.

Understand the system through whatever-the-hell you can find about it: business docs, technical docs, diagrams, demos, etc. Anything but code, as it will be distracting. Then identify scope and list assumptions. As you do these steps, try to see forest among the trees.

💰 Step 1: Assets - Find what to protect.

Identify “Assets” in the system. An asset is a data or functionality or component that needs to be protected. Examples:

• A01 - Credentials

• A02 - Credit Card Numbers

• A03 - Transient data stored in memory for processing

• A04 - Business Logic/Functionality. And so on..

🎭 Step 2: Threat Actors - Find who to protect from.

Identify “Threat Actors”, these are the internal or external malicious actors trying to compromise the system. Examples:

• TA01 - Malicious insider, application admin

• TA02 - Novice insider with access, user from another department

• TA02 - Malicious outsider, script kiddie

• TA03 - Malicious outsider, nation state. And so on..

🚦 Step 3: Controls - Learn about protections.

Identify “Controls” that are planned or are in place. Examples:

• C01 - Single Sign On authentication

• C02 - RBAC authorization

• C03 - Encryption

• C04 - Key management. And so on..

✍️ Step 4: Draw a threat model diagram

This can be a new simple architecture diagram, or an overlay on top of an existing diagram by marking trust boundaries (a trust boundary could be a network boundary, a compute unit or a data store, etc.), assets, threat actors, and controls. Here’s a good sample (source).

💥 Step 5: Enumerate threats

Now that you’ve understood the system → listed assets → listed threat actors → listed controls → drawn a threat model diagram with trust zones; you can start writing threats.

How do you write the threats? Do you refer to a threat library (like the one provided by the ATTACK framework) and select the ones relevant for you, but then what’s the point of all this hoopla? Do you just write what comes to mind (“what could go wrong”), but then will it be exhaustive, and is it a structured approach?

So, review the threat model you’ve in front of you section by section (or asset by asset), and see if a threat actor can compromise/steal an asset due to a missing or weak security control across a trust zone, if yes, there’s your threat. Yes, you’d need some security experience or training to do so. Yes, a threat library will help. No, it cannot be fully automated. And yes, you can do it. Let’s illustrate this with a few examples.

In the diagram above, locate TA01 (malicious user) and TA04 (compromised wordpress blog). TA01 is able to steal A04 (blog admin credentials) because there is no security control at the wordpress blog and also because it is compromised due to TA04. (This is a general example, so there are many assumptions here, for e.g., TA04 could be due to an unpatched wordpress engine). So our threat becomes:

Threat: A malicious user steals wordpress credentials from the wordpress blog admin console

Mitigation: 1) Patch Wordpress to latest version. 2) Require any user to authenticate using strong credentials and MFA before accessing the compromised.

Let’s take another example:

Threat: Launch Distributed-Denial-of-Service (DDoS) attack to XYZ application at the frontend.

Mitigation: Follows the recommendations of AWS Best Practices for DDoS Resiliency whitepaper: Filter out bad requests (CloudFront and API Gateway endpoint only accepts well-formed HTTP requests), managed services can automatically scale to absorb attack (and the user can also apply throttling limits in API Gateway or restrict access using AWS GeoIP block).

👷‍♂️ Step 6: Put threats to action

Once you’ve created threats and written some practical mitigations to remove or reduce the risk, you need to convert the threats to something actionable like a developer user story and corresponding tasks. Here’s a sample for it.

Wrapping it up

The thing with mental models is that you form them on your own accord through: processing information → identifying key concepts → deliberate practice → testing your understanding → and → experience. My goal here is to give you a reference pointer on how my mental model looks when it comes to threat modeling, and inspire you (doesn’t matter if you’re a security SME or a software dev) to take on threat modeling.

In future related posts, I will share some end to end threat models of public systems; and how to scale threat modeling at the speed of your business. If you’ve ideas, requests or suggestions, let me know.

📕 Security Wale is a blog about cloud, cybersecurity, and in between - written by Aditya Patel (more here). To support this effort, consider subscribing (it’s free) and spreading the word.

👋 Dear reader: Hope you’re staying safe, and going strong with your new year resolutions. This is first part of a series of posts I wish to write on peculiar cloud security challenges. In this post, I will cover:

• Encryption at rest in cloud

• Amazon S3 and its encryption options

• How cloud’s server side encryption can give a false sense of security, and what you can do about it

Encryption is a tricky concept. It’s simple at the surface, but dig a level deeper and it unravels like Game of Thrones subplots.

Let’s take AWS' recent announcement that all new objects in Amazon S3 (Simple Storage Service) will now be encrypted by default.

Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket in Amazon S3. Starting January 5, 2023, all new object uploads to Amazon S3 will be automatically encrypted at no additional cost and with no impact on performance. 

(Source: AWS docs)

What was earlier a 1-click setup, is now zero-click. AWS, and its S3 service specially, operate at a mind boggling scale. There are 280 trillion objects in S3, averaging over 100 million requests per second. To be able to support transparent encryption on all new objects, while not breaking any existing functionality, dependencies and applications - is impressive to say the least. Kudos to the engineering teams.

But.. does the default SSE-S3 encryption provide effective confidentiality? And, does it help in reducing impact of one of the primary causes of CISO migraines, i.e., data leakage via intentional or accidental public S3 buckets?

Short answer: No.

I’m a big proponent of AWS, and can say from experience that AWS takes security very seriously. However, in this case, server side encryption with default S3 keys (SSE-S3) can be misconstrued, potentially leading to inaction from customers to employ stricter encryption schemes (which are all available natively in AWS btw) on sensitive data.

Let’s dive in.

Cryptography - a quick primer

Encryption converts readable data to a random looking blob. It is the reason we can watch dog videos in private, or crib about things on group chats (well, mostly), or buy toilet paper online securely. On a serious note, encryption is a fundamental tool for cybersecurity to the extent that it can be an enabler of human rights, by allowing freedom of speech through end-to-end encryption. It is a big deal to get it right.

Technically, encryption is the process of converting plaintext data into ciphertext. There are 2 types of encryption: symmetric and asymmetric. Symmetric encryption uses the same key to encrypt and decrypt the data. Asymmetric encryption uses separate keys to do the same, and is also called public key cryptography. We will limit this blog post to symmetric encryption of data at rest, which is the data stored on disks.

encrypt(plaintext, key) → ciphertext

The efficacy of a good encryption scheme depends upon the strength of encryption algorithm (the lock) and the encryption key (key).

🔒 First is the lock, i.e., the algorithm itself. There are many encryption algorithms available, the most common type today is Advanced Encryption Standard with 256 bit key (AES-256). There is enough evidence, backed by gory mathematical proofs, to safely assume that the AES-256 encryption algorithm is not broken, for now. From one estimate, if we use the combined compute power of every PC on earth (estimated 2 billion PCs), it’d take 13,689 trillion trillion trillion trillion years to brute force AES-256. For comparison, the age of the universe is a meager 14 billion years. Quantum computers might change the equation sooner than later, but for now AES-256 is considered a quantum resistant algorithm. Moral of the story here is to trust the researchers and don’t invent your crypto.

🔑 Then comes the key. As a wise man once said: if a thief has your key, no lock is strong enough. That’s why protecting the key is the most important part of a secure encryption scheme. So in theory, it’s pretty simple to protect your data. Choose a vetted encryption algorithm, and protect the key. In practice, things are more complex.

Any modern production application usually has many different data sources, and hence many encryption schemes and keys. For instance, Pinterest currently stores and manages 1 exabyte of data on AWS. Nope - that’s not a typo, that is one frickin’ exabyte, or 1 billion gigabytes of data, which needs to be protected.

This humongous amount of data is unlikely to be in a single data store. So now, you need to manage encryption across all the applicable data stores, equating to potentially thousands of encryption keys. Add to it the security best practice of rotating the keys periodically, or in case of an incident, deleting a whole bunch of keys. Doing this on your own is a nightmare. Ask Harry Potter.

Luckily, you don’t have to. There are key management services both for on premise and cloud. In AWS, the service is called AWS Key Management Service (AWS KMS).

This brings us to the types of encryption choices available in S3.

Encryption in Amazon S3

You can either do Server Side Encryption (SSE), in which Amazon S3 encrypts your data as it writes it to disks in its data centers and decrypts it for you when you access it. With server side encryption, there are 3 broad ways to manage your encryption keys.

One option is for S3 to fully manage the encryption keys (SSE-S3). This option places the most trust in AWS, and is the reason I’m writing this post. A second option is for customers to use a key that is managed by the Amazon Key Management Service (SSE-KMS). This option gives customers control and transparency over access to their keys with strong auditing. Spoiler: this is my recommendation for most use-cases. Third option is for the customer to provide and manage the key, but have S3 perform the actual encryption and decryption (SSE-C). This gives customers a level of separation between themselves and AWS; do note that there’s a small window where the encryption key will be present on AWS servers to do encryption and decryption. Using either of these 3 ways, you can choose to give all the encryption, decryption and associated compute headaches to AWS.

Or, you can say hey AWS, I don’t trust you, I will do the Client Side Encryption (CSE), in which you encrypt your data locally and pass it to the Amazon S3 service for storage and retrieval. You’ve 2 further options here: Use a key stored in AWS Key Management Service (AWS KMS). Or, use a key that you store within your application.

Security is a tradeoff problem. Your security decisions may come at the cost of convenience or performance or a higher spend. If you can safely create and manage your own keys in your applications for instance, you, and only you, will have access to the unencrypted material (assuming your access controls are rock solid). Choose client side encryption for highly regulated industries, business critical and the most paranoid of use cases. For the rest, the tradeoff problem may lean towards using the other option, the server side encryption.

And as per an AWS blog, server side encryption may be the way to go. I agree.

While client-side encryption still has an important role in security and data protection, two of its disadvantages are that it depends on clients having a secure source of randomness, which is not always easy, and it is CPU intensive on the client. For more simplicity and efficiency, our services also offer server-side encryption.

(Source: AWS blog)

Now, let’s go back to the news announcement, that AWS now encrypts all new object uploads with SSE-S3 server side encryption. So does it provide any meaningful confidentiality?

So does it?

In my opinion, no, the SSE-S3 server side encryption does not provide any meaningful security assurance when it comes to confidentiality of data. Here’s why.

One. It is mostly a checkbox exercise. This may appease some auditors but not all (disclaimer: nothing against auditors, I work very closely with them at Amazon, and they understand security better than most). For example, SSE-S3 meets PCI DSS’ encryption requirement but not the segregation of duties requirement.

Next, at best SSE-S3 adds a defense in depth protection against a physical loss, theft or confiscation of an AWS hard drive storing your data. Think crazy scenarios like a tornado or fire, followed by more chaos and somehow the AWS hard drive landing at Goodwill. If the data on it is unencrypted, game over. As you can imagine, the likelihood of this happening is about the same as that of the United States winning a cricket world cup.

Lastly, in SSE-S3, since S3 encrypts and decrypts the data transparently to anyone with access to the bucket, on its own it will not protect leaked S3 buckets’ contents from being read. Public S3 buckets is unfortunately still a fairly common scenario.

Why does AWS even provide this option then? For one, some encryption is better than no encryption. Few compliance attestations may be happy with it, since it gives you a defense in depth option. It also provides some practical benefits for AWS to wipe out the hard drives more easily and securely (delete the key and you get crypto shredding). Also worth noting, there are no additional costs for using SSE-S3.

What should you do instead? My suggestion is to go with any of the other options in Figure 1. At a minimum, go with the server side encryption with KMS keys, SSE-KMS.

SSE-KMS provides a good balance between security and usability. For reading and writing contents of S3, it requires users to have access to both the object and the key. Enter multiple permission policies at IAM, S3 and KMS level, and hence segregation of duties. Now if a bucket is made public, and if it’s encrypted with SSE-KMS, it’s a very low likelihood that its contents will be world readable. Win!

Takeaways

If you’re new to AWS, you might be wondering, wow this is complicated. It is, and I didn’t even cover all the scenarios. Here’re the takeaways:

1. Don’t invent your crypto. Choose a cryptographic algorithm vetted by academia and industry such as AES-256.

2. Outsource key generation and management. Prefer not to create and manage your own cryptographic keys if it’s not your core competency. Use the cloud service provider’s key management service instead.

3. SSE-KMS for the win. That means, in AWS for your data in S3, prefer the server side encryption with KMS keys (SSE-KMS) for most use cases.

4. SSE-S3 may be misleading. Server side encryption with S3 keys (SSE-S3) shows AWS’ commitment to security, but IMO it doesn’t provide benefits beyond a compliance checkbox and a very low probability scenario of AWS data-center compromise.

To wrap it up, here’s a relevant quote, attributed to Amazon CTO Werner Vogels:

“Dance like nobody's watching. Encrypt like everyone is.”

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.

P.S. This article made it to the frontpage of Hackernews. Good discussion there as a further reading.

Happy New Year 🎉! In this post, I will cover:

• What is People-Centric Cybersecurity

• Why “humans are the weakest link is security” needs a revisit

• How to reduce human mistakes in security

Recently at a regular Chipotle preorder-and-grab-food run, I realized that the bag they gave me was lighter than usual. Our order is always the same, so even a slight change in weight would have been noticeable. It turned out, the missing item was neither a side of hot salsa nor a bag of chips, rather it was the burrito! I pointed out the mistake, and they promptly fixed it. Phew.

This happened despite Chipotle having a process for digital orders with dedicated second “make lines”.

Tech-enabled second make lines: After implementing second make lines in most stores for online orders, Chipotle digitized many, adding visual screens that guide staff through the order to ensure that it's more accurate.

(Source: Chipotle newsroom)

Mistakes happen. We’re humans after all. Security is no different.

People are considered the achilles heal of security, because unfortunately, they often are. As per Verizon 2022 Data Breach Investigations Report (DBIR), 82% (!!) of all security breaches in 2022 involved a human element.

The human element continues to drive breaches. This year 82% of breaches involved the human element. Whether it is the Use of stolen credentials, Phishing, Misuse, or simply an Error, people continue to play a very large role in incidents and breaches alike.

(Source: Verizon DBIR 2022, page 8)

As a result, if you look at most security best practices, say these from AWS, you’d notice that they take a very blunt approach such as keeping people away from data.

Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of mishandling or modification and human error when handling sensitive data.

(Source: AWS Well-Architected Framework, Design principles)

But.. at the end of the day, you cannot keep people away from data and systems. There will always be someone on a team somewhere who will need access, or worse, may have direct access nonetheless.

Next up, comes fixing people related security issues via, training.

Security trainings help in creating awareness but a one size fits all approach is not sufficient. More often than not, security trainings are dull, mandatory affairs - which no one pays attention to. When was the last time you enjoyed and remembered all your security training takeaways?

Let’s say stars align and you create the world’s most engaging series of security trainings, it might still not work. There’s so much noise, stress, fatigue and distraction in this pandemic driven IT world today, that mistakes are bound to happen. Training humans, trusting them to make the right choices, and then yelling “i told you so” (although satisfying) is not the solution. 

So what can be done?

If changing culture is hard, changing human behavior is next to impossible. There’s thousands of years of evolutionary baggage that we carry: fear and greed are factors that will likely continue to be exploited by adversaries. That's where the synergy between man and machine comes in.

Enter people-centric security. In cybersecurity, there’s a concept called people-centric security, which means putting people at the heart of security, instead of considering them the weakest link.

Here are some things that we can do to reduce human mistakes in security and achieve a people-centric security vision.

🌯 One. Use automation to reduce cognitive load, and Artificial Intelligence (AI) to augment human decision making. This way you’re assisting humans to make less mistakes. They will be able to thrive with data driven decisions. For instance: initial screening for a security issue can be done by a tool; enrich incident response tickets with more relevant information for a security analyst to triage more effectively; or pre-populate security configurations using a predetermined baseline in new applications. Use-cases are endless, but the idea is simple: use machine learning to augment human decisions.

🌯 Two. Train users with the right expectations. Security training and awareness is important, however, it’s just another layer in your arsenal to improve the security posture overall. Users need to be familiar with basic security hygiene like keeping all software up to date, multi-factor authentication and how to avoid phishing attempts. Train users, but don’t expect it to be a panacea.

🌯 Three. Make security easy. As a security practitioner, instead of giving people a checklist of bazillion best practices, or hundreds of resources, give them an easy button (a simple intuitive solution) that takes care of security automagically. Developers should choose a solution because it makes their life easy: something faster, more reliable, less complex. Security achieved through such a solution can be a happy byproduct.

🌯 Four. Assume things will fail. Even with all these mechanisms successfully in place, assume things will fail, because they will. Build strong detection and auto-remediation capabilities in your systems (again, powered by AI). Build defense in depth. Build resilience. Build processes. And test these in peacetime through tabletop exercises and hands-on simulations. I see humans fiddling with systems, sometimes misconfiguring them, regularly, both at AWS and Amazon. Fortunately, we have mechanisms in place to detect → correct, and in some cases even prevent it.

Wrapping it up

I was lucky to detect → correct the case of missing burrito, our Chipotle order hasn’t changed since 200 BC, I’d have detected even a missing chip. And what about the experience? It’s okay, mistakes happen. All we need is to develop some empathy, trust that humans will make mistakes, prepare for it, and march towards people (enjoying burrito) centric security.

📕 Security Wale is a blog about cloud, cybersecurity, and in between - written by Aditya Patel. This is a passion project, where Aditya shares his learnings, opinions and rants from over a decade of working in the IT industry in United States. For a living, currently, he protects ☁️ cloudy things at Amazon/AWS. Earlier, Aditya has done software security consulting, masters in Information Security from Johns Hopkins, and computer science engineering. To support this effort, consider subscribing (it’s free) and spreading the word.

LastPass, the password manager service, announced that there were breached again.

From The Verge’s story

If you have an account you use to store passwords and login information on LastPass, or you used to have one and hadn’t deleted it before this fall, your password vault may be in hackers’ hands. Still, the company claims you might be safe if you have a strong master password and its most recent default settings. However, if you have a weak master password or less security, the company says that “as an extra security measure, you should consider minimizing risk by changing passwords of websites you have stored.”

LastPass has been terrible at security over the past few years! This is almost the worst that can happen to a password manager service, I’d be panicking if I were their CEO or CISO at the moment.

Breaches happen.. but the way LastPass has handled this (and earlier breaches) is a case study on how not to handle breach disclosures. They had a breach in August 2022, and are now saying attackers used data from that breach to target an employee to attack again in November 2022 - this time stealing encrypted password vaults!

Not only the timing and manner of their disclosure is horrible (at Christmas when most IT departments/folks are on vacation), their recommendation is to change each and every password in your vault (and since the URLs are unencrypted, attackers have an easier way targeting specific high-reward website accounts).

And it doesn’t end here… in theory a breach like this should not matter, because your vault is encrypted with a strong encryption algorithm, which can’t be brute forced in a practical amount of time…. that’s what you’d expect. Sorry, not the case here! Lastpass uses a custom version of PBKDF2 encryption algorithm with 100,100 iterations (the more the better).. but also still allows the ones with fewer iteration (pre 2018 accounts have 5000 iterations as reported by Verge). So attackers have a good chance of breaking cypto on many of the stolen vaults.

It’s also worth noting that if you have an older account (prior to a newer default setting introduced after 2018), a weaker password-strengthening process may have been used to protect your master password. According to LastPass, it currently uses “a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function,” but when a Verge staff member checked their older account using a link the company includes in its blog, it told them their account was set to 5,000 iterations.

This is just great. LastPass users, time to change all your passwords and switch to 1Password or Bitwarden.