Security
Security Without TLS
Security Without TLSI know what you’re thinking, that I’m another one of those people out there that think they can roll their own protocols better than the contributors of SSL/TLS. I’m here to tell you that I am not! I’ve recently stumbled upon a really nice framework that allows to you safely define your own protocol that is still supported by the best practices used in Diffie-Hellman cryptography. The name of the framework is called “The Noise Protocol”. |
The Complete Guide to OAuth 2.0 and OpenID Connect Protocols
Find out how the most widely-used protocols for authentication and authorization really workWe’ve all seen the “sign in with Google” and “connect to Facebook” buttons on websites and mobile apps. Click the button and a screen opens that says, “This app wants to access your public profile, contacts…” and asks you whether you want to give access. This is OAuth at a high level. Understanding these protocols is crucial for every software engineer, security expert, and even hacker. TL;DRA complete guide to OAuth 2.0 and OpenID Connect, the two most widely used protocols on the internet today for authorization and authentication. OAuth 2.0 is used for authorization and OpenID Connect is used for authentication. There are two most common OAuth 2.0 authorization flows, authorization code flow for server-side applications, and implicit flow for browser-based applications. OpenID Connect is an identity layer on top of the OAuth 2.0 protocol to make OAuth suitable for the authentication use cases. Why OAuth?To understand the reason for the birth of OAuth we need to understand a term called Delegated Authorization. Delegated authorizationDelegated authorization is an approach to allowing a third-party application access to a user’s data. Two approaches to delegated authorizationThere are two approaches for delegated authorization, whether you give the third-party application your account password so they can login into your account on your behalf and access your data or you grant the application to access your data using OAuth without giving your password (and none of us will give our password!). Now we know the need and importance of OAuth, let’s dive deeper into the protocol. What is OAuth?OAuth (Open Authorization) is a standard protocol for delegated authorization. It allows applications to access user data without the user’s password. OAuth 2.0 terminologyUnderstanding this protocol requires us to understand its terminology:
Take a look at this terminology in the OAuth 2.0 abstract flow: ![]() The authorization key/grant can be of type code or token. We’ll learn about different authorization grants later. Now, let’s take a look at the authorization flow in detail:
That’s how users give third-party applications access to their data without giving them the password. At this point, the following questions arise:
These questions take us to another important piece of OAuth terminology: scopes. Scopes in OAuthScopes in OAuth 2.0 are used to limit an application’s access to a user’s data. By issuing an authorization grant that is limited only to the scopes granted by the user. When the client makes a request to the authorization server for authorization grant, it sends a list of scopes with it. The authorization server uses this list of scopes to generate a consent screen and grants permission from the user. If the user agrees to the consent screen, the authorization server issues a token or authorization code that is limited only to the scopes granted by the user. For instance, if I grant a client application to see the list of my Google contacts then the token issued to the client by the authorization server can’t be used to delete my contacts or see my calendar events — it’s only scoped to read my Google contacts. Setup for OAuth 2.0Before moving on to OAuth flows, it’s good to know some prior OAuth configuration. When the request for authorization grant is initiated, the client sends some configuration data to the authorization server as query params. The basic query params are:
Understanding Different OAuth FlowsThe two most commonly used OAuth 2.0 flows are authorization code flow for server-based applications and implicit flow for pure JavaScript Single Page Applications (SPAs). To explain the OAuth flows, I’m considering Google as the OAuth service provider. Authorization code flowThe authorization code flow or authorization code grant is an ideal OAuth flow which is considered to be highly secured because it uses both the front-end channel (browser) and the backend-channel (server) to implement the OAuth 2.0 mechanism. ![]() The client begins the authorization sequence by redirecting the user to the authorization server with https://accounts.google.com/o/oauth2/v2/auth? In the above request, the client is requiring the user’s permission to access his public profile and contacts by defining them in the 4/W7q7P51a-iMsCeLvIaQc6bYrgtp9 Why exchange code for a token?An access token is the only thing that can be used to access data on the resource server, not the application code. So why is the client set ![]() Problem: An access token is a secret piece of information that we don’t want someone to access. If the client requests an access token directly and stores it in the browser, it can be stolen because browsers are not fully secure. Anyone can see the page source or potentially use dev tools to acquire the access token. Solution: To avoid exposure of the access token in the browser, the front end channel of the client gets the application code from the authorization server, then it sends the application code to the client’s back end channel. Now to exchange this application code for an access token, a thing called POST /token HTTP/1.1 The authorization server validates the client secret and application code and responds with an access token. The back end channel stores the access token and potentially use this token to access a resource server. In this way, the browser cannot access the access token. Implicit flowThe OAuth 2.0 implicit flow is used when you don’t have a back end channel and your website is a static site that uses only the browser. In this case, you skip the last step that happens on the backchannel when you exchange the application code for an access token. In the implicit flow, the authorization server responds with an access token right away. ![]() The client redirects the browser to the authorization server URI to start the authorization flow with Implicit flow is considered less secure because the browser is responsible for managing the access token, so it could potentially be stolen. Still, it’s widely used for single-page applications. Authentication vs AuthorizationAs we know, OAuth solves the delegated authorization problem, but it doesn’t provide a standard way to authenticate the user. You could say that:
If you’re confused by these terms, here’s the difference between them:
In other words, authentication cares who you are, authorization cares what permissions you have. OpenID ConnectOpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It extends OAuth 2.0 to standardize a way for authentication. ![]() OAuth does not provide user identity right away but rather it provides an access token for authorization. OpenID Connect enables the client to identify the user based on the authentication performed by the authorization server. This is achieved by defining a scope named The URI for OpenID Connect authentication request made by the client looks like this: https://accounts.google.com/o/oauth2/v2/auth? The result of the request is an application code that the client can exchange for an access token and ID token. If the OAuth flow is implicit then the authorization server responds with an access token and an ID token right away. The ID token is a JWT or JSON Web Token. A JWT is an encoded token that consists of three parts: header, payload, and signature. After acquiring the ID token, the client can decode it to get the user info encoded in the payload part — like this: { ClaimsThe payload of the ID token contains some fields known as claims. Basic claims are:
However, claims are not limited to these fields. It’s up to the authorization server to encode claims. The client can use this information to authenticate the user. If the client needs more user information, the client can specify standard OpenID Connect scopes to tell the authorization server to include the required information in the ID token’s payload. These scopes are End NoteIt’s always good to practice what you have learned. To play with OAuth 2.0 scopes, authorization codes, and tokens go to Google OAuth 2.0 Playground. |
Multi-Factor Authentication from Duo
Multi-Factor Authentication from DuoThere’s no easier way to use multi-factor authentication. Designed for the modern workforce and backed by a zero trust philosophy, Duo is Cisco's user-friendly, scalable access security platform that keeps your business ahead of ever-changing security threats. ![]() Verify identity in seconds. Protect any application on any device. Easily deploy Duo in any environment. |
IBM kit wants to keep your data encrypted while in use
IBM kit wants to keep your data encrypted while in useIBM's new technology is only compatible with Apple devices, but Android and Linux support is on the way.![]() ![]() (Image credit: Image Credit: Sergey Nivens / Shutterstock) IBM is moving forward with its homomorphic encryption (FHE) solution, providing encryption for in-use and shared data for Apple’s computing platforms. It recently released a toolkit on GitHub, allowing Apple devices (iOS and macOS) to implement its newest technology. Homomorphic encryption allows users to share data with third parties (e.g. public clouds), all the while keeping it encrypted. IBM sees many use cases for the technology, mostly in highly regulated industries that depend heavily on keeping data secure – healthcare and finance, for example. Announcing the news in a company blog post, Senior Research Scientist Flavio Bergamaschi wrote: “FHE is particularly suited to industries which are regulated and make use of private, confidential and 'crown jewel' data, such as finance and healthcare, since the technology can make it possible to share financial information or patient health records broadly while restricting access to all but the necessary data.” For the time being, the technology is limited to Apple’s devices, although Android and Linux versions are in the works and expected “in a few weeks”. IBM was careful to note that the solutions shared on GitHub are “not perfect or final” and that early adopters may experience hiccups. |
Free phishing security test
Controlling outbound traffic from Kubernetes
At Monzo, the Security Team's highest priority is to keep your money and data safe. And to achieve this, we're always adding and refining security controls across our banking platform. Late last year, we wrapped up a major networking project which let us control internal traffic in our platform. This gave us a lot of confidence that malicious code or an intruder compromising an individual microservice wouldn't be able to hurt our customers. Since then, we've been thinking about how we can add similar security to network traffic leaving our platform. A lot of attacks begin with a compromised platform component 'phoning home' — that is, communicating with a computer outside of Monzo that is controlled by the attacker. Once this communication is established, the attacker can control the compromised service and attempt to infiltrate deeper into our platform. We knew that if we could block that communication, we'd stand a better chance at stopping an attack in its tracks. |
Securing your bastion hosts with Amazon EC2 Instance Connect
In a previous blog post, I discussed how you can use AWS Systems Manager Session Manager to securely connect to your private instances in your virtual private cloud (VPC) without needing an intermediary bastion host, open ports, or a key pair assigned to the instances. In this post, I cover how you can improve the security of your existing bastion hosts by using Amazon Elastic Compute Cloud (Amazon EC2) Instance Connect. I also demonstrate how you can use an AWS Lambda function to automate your security group configuration to allow access from the published IP address range of the EC2 Instance Connect service. This is necessary if you want to connect to your instances using Instance Connect from the Amazon EC2 console. |
stop disabling SELinux
Seriously, stop disabling SELinux. Every time you run setenforce 0, you make Dan Walsh weep. |
JSON Web Token
What is JSON Web Token?JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA. Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it. |