6.3 KiB
6.3 KiB
List of topics that this book can cover
- Preface - "A scout is Trustworthy"
- Authentication
- Authorization
- Audit/Accountability
- OAuth
- OpenID
- SAML
- JWT
- SAML vs OAuth vs OpenID
- OAuth vs OpenID
Questions I need to answer before attempting to write this book
- Do I strictly focus on authentication or expand it to authorization and security in general?
Topics
Why listen to this guy?
What this book is
What this book is not
What are you authenticating?
- Users
- Anonymous
- System services
- Third parties
- Distributed and decentralized applications
What are you authenticating for?
- Shoppers - allowing a user to save and access their information for future use
- Security - applying authorization (including Paid access or limiting ability to administrate)
- Paid access - limiting access to paid users
- User tracking - do we really need to do this?
How are you authenticating
- Something you know - password, security question, pin number
- Something you have - an email address, phone number, or security key
- Something you are - biometrics
- Somewhere you are - location
- Something you do - behavior
Layers of security
The following list was derived from https://identitymanagementinstitute.org/layered-security-model/
- Physical security
- Network security
- Application security (you are here!)
- Data security
- User education on security
Developer Experience
- Consider the experience of a developer who has to apply your authentication
- Compare to physical security, when you make an area well lit, highly visible, and easily accessible the place by default becomes more secure when compared to a dark hidden ally-way. You didn't need to add a security guard.
- When your authentication infrastructure is easy to apply or applied by default, your application automatically becomes more secure.
User Experience
- Consider the user experience as a way of making your application more secure (see also physical security comparison in developer experience)
- Why passwords are still useful
- Familiarity - people have used passwords in many applications, it isn't new to them
- Ease of use (unless done right) - example of FHIR client
- Ease of implementation - low barrier to entry
- Inexpensive (unless hacked)
- Scalability
- No specialized hardware
- Versatility (standalone, or as part of a mfa system, or versatility in how it is implemented)
- User choice (choosing their own passwords)
- Encourages users to be aware of their security
- Ease of recovery
- User autonomy - users have full control over their passwords, changing them when they want
- Why passwords should die
- Weak passwords
- Password reuse
- Phishing vulnerability
- Credential Stuffing - using stolen creds to gain access
- Password management challenges - putting all passwords into a single basket (pw manager)
- Brute-force attacks
- Password recovery risks - security questions, email resets etc can be susceptible to social engineering
- Limited security - it is a single factor (something you know)
- Support costs - the trade-off you get because of the low cost of implementation
- Password Policy Complexity
- User Resistance
- Password hash storage
- Limited accountability - sharing of passwords
- Less convenience compared to biometrics or other technology
- WebAuthn or other asymmetric cryptography is mostly fantastic for user experience and security
- How it works will be discussed in the Asymmetric Cryptography for Authentication chapter
- There is a large user experience hurdle to implementing asymmetric cryptography for applications. Users are not use to managing keys. When keys (or devices) are lost, how does one recover an identity?
Asymmetric Cryptography for authentication
- The case for WebAuthn and other asymmetric cryptographic authentication
- It is almost accidentally multifactor, you have something, but in order to use it you need to unlock it with something you know or something you are. e.g. Your smartphone keeps the key in a special module that needs to be unlocked with the phone's security features (pin, password, FaceID or TouchID). Then that module can prove you 'have' the key using cryptography.
- Unlocking the key using a password is great because the password verification is local only, a password hash doesn't ever have to leave your phone or be stored in some database you don't control.
- Asymmetric cryptography allows for the private key to stay on the device while still being usable to prove you have the key. Using the private key you can sign messages. The recipient of the message can use your public key to verify the signature.
- The authentication system doesn't need to store any secrets or sensitive information in order to authenticate a user. This makes the authentication system a much less interesting target for attackers.
- Internal service to service authentication
- Some systems simply use a shared secret to generate symmetrical tokens
- Issues include, non-repudiation (you don't know for certain which service generated that key)
- Compromised keys give access to everything
- rotating the keys requires coordination (which some organizations try to avoid because it's 'hard')
- Google Cloud (and other cloud services) provide some authentication when a service is running in their cloud. Using their asymmetric authentication to prove the service is running in a place we trust we can issue credentials for our application.
- Requires that the system be authenticated by its host
- gives us non-repudiation, auditability and a bunch of other goodies
- allows us to apply authorization levels if desired
- Some systems simply use a shared secret to generate symmetrical tokens
Password Best Practices
- Policies tend to change as computers become more powerful
- NIST guidelines are great
- bcrypt, pbkdf2 and other hashing and storing suggestions
- Securing your database