Security and Authentication — IT Fundamentals for Beginners

About this article

Thank you for visiting the site. This article is part 5 of the “IT Fundamentals” primers in the Architecture Crash Course for the Generative-AI Era series, and it covers security and authentication.

The primers so far have looked at how the shop that is a web service runs. This time it is about “security”. Authentication versus authorization, two-factor authentication, encryption — the words that fill the security category of the main series, still through the shop.

Why security is needed at all

Why does a web service need security in the first place?

A physical restaurant is guarding against “people who can physically get to the premises”. A web service, the moment it faces the internet, is in a state where anybody on earth can put a hand on the door. And inside are member names, email addresses, sometimes card details — things that are very bad to lose.

A common misconception here is “who would target a service as obscure as ours?”. I understand the feeling, but it is simply wrong. Attackers are not choosing targets one by one by hand; they are running programs that automatically try the door of every shop they find. Fame is irrelevant; the shops with weak locks get opened first. Which is why even the smallest service needs security.

Authentication: confirming who you are

First, authentication. In the main series it turns up as “identity platform”, “user authentication” and so on.

Roughly, authentication is “confirming who somebody is”. In shop terms, the moment at the door of a members’ restaurant where they say “membership card, please”.

The most familiar authentication on a web service is logging in with an ID and a password. The reasoning is “this person knows the password only the owner of that ID should know, so it is presumably them”. Which also means that once a password is known to somebody else, that person can walk in openly as the owner. Exactly like having a copy of the key.

Authorization: how far you are allowed in

Authentication always comes paired with authorization.

Authorization decides “now that we know who you are, where may you go and what may you do”.

In the restaurant: a customer who showed a membership card can sit in the dining room, but not walk into the staff room. A front-of-house junior can enter the dining room and the kitchen, but not the manager’s office with the safe. The manager can go everywhere. Confirming who someone is and setting how far they may go are two separate matters.

A web service works the same way: after login (authentication) comes the assignment of permissions (authorization) — “ordinary users see only their own data”, “administrators can enter the admin screen”. When the main series says role or permission management, it means designing “who is allowed how far”.

The two words are annoyingly similar in English as well, to the point that people abbreviate them AuthN and AuthZ. Remember only that “identity check” and “entry permission” are different things and you can read the main series.

Two-factor authentication: stopping a copied key

A word on two-factor authentication (also multi-factor authentication, or MFA), which more and more services now require.

I said above that a leaked password is the same as a copied key. In practice, passwords leak far more easily than people think: reused passwords from another service’s breach get tried, a fake login page collects them, or they are simply guessed.

So on top of the password check, you add “please enter the six digits sent to your phone” — another layer of confirmation. In shop terms, asking for photo ID as well as the membership card. An attacker with the copied key (the leaked password) does not also have the owner’s phone, so they stop here.

Encryption: an envelope nobody can see into

The other constant of the main series is encryption.

Encryption converts data into “a form only someone holding the key can read”. As a letter, it is sending it in a sealed envelope rather than on a postcard.

Part 1 described browser and server exchanging orders; those orders travel via a number of intermediate points. Send them as a postcard and anyone along the route who looks will see the password or the card number. So encrypting all traffic is now standard. The “s” at the front of a URL’s “https” is the mark of the envelope.

Data stored in the store room (the database) is generally encrypted too. Even if a burglar does get in, what they carry out is sealed and unreadable, which cuts the damage enormously.

Locks alone will not save you: attacks on people

Everything so far has been mechanism, but in fact most attacks begin not with a hole in the mechanism but with deceiving a person.

The archetype is phishing: an email dressed up as your bank or a courier, leading you to a fake login page where you type your own ID and password. Once that works, however solid your locks are, they do not matter. “The owner handed over the key voluntarily”, and no amount of security equipment can prevent that.

In shop terms: install the finest safe and alarm system you like, but if an employee is talked into opening the safe by a phone call from “head office”, it is over. So real-world security has moved, alongside the equipment, toward arrangements that limit the damage when somebody is fooled. Two-factor authentication is exactly that, and “zero trust”, which the main series discusses, is at root “assume the insiders are being deceived too, and check every time”.

Common misconceptions about security

A few misunderstandings beginners tend to carry.

First, “a complicated password keeps me safe”. Complexity is good, but the most common real-world incident is a complicated password reused across several services, leaking from one of them. However elaborate the key, copies in circulation make the elaborateness irrelevant. So the priority order is “do not reuse” and “turn on two-factor”, ahead of complexity.

Second, “an https site is safe”. As described above, https guarantees only that “the contents of the traffic are not observed”. It does not guarantee that the party on the other end is not a fraudster. Sending it in an envelope means the postman cannot read it, which is no help if the addressee is a criminal. Most phishing sites these days are on https.

Third, a builder’s misconception: “security can be added once it is finished”. Retrofitting security tends to mean rebuilding the structure of the building. So the main series assumes from the outset that security is designed in from the first stage (security by design). Security is a whole category of its own in this series precisely because it bites so early in the design.

Mapping to the terms used in the main series

How this connects to the main series

Security is gathered into the “Security Architecture” category — designing authentication and authorization, protecting traffic and data, and the newer concerns specific to the generative-AI era. This article’s analogies should carry you through all of it.

Security Architecture: Defense in Depth and Zero Trusten.senkohome.com/arch-intro-security-overview/

Related articles

Summary

This article covered security and authentication through the analogy of shop security.

Authentication confirms identity, authorization assigns how far you may go, two-factor is the extra push against copied keys, and encryption is an envelope nobody can see into. Above all, carrying the assumption that attacks are indiscriminate, automated, and constant makes the security category of the main series read far more urgently.

The last primer covers the days after opening: “from development to operations”.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.