used to determine that… • You are admitted entry to a protected area • You possess the correct key • You are permitted access to a resource • You have been authorised to perform an action
$password = $_POST['password']; // The plaintext password. $algorithm = PASSWORD_DEFAULT; // Choose an algorithm. $hash = password_hash($password, $algorithm); // Hash and salt it. // You may now store the value of $hash in your database! save-password.php
a salt automatically so you don’t have to! • Returns the salt in the hash so no separate storage required. • Hash contains the algorithm parameters used to generate it. $2y$07$CCk9VkXcWxRIhy90tY21SeYjnHxoe0t/8.XQ3IV5KEelwrFTNu4Ge
strong hashing algorithms. • PASSWORD_DEFAULT is the PHP default algorithm; this can change if something stronger comes along. Currently, it is PASSWORD_BCRYPT • You can also use PASSWORD_ARGON2I and PASSWORD_ARGON2ID if PHP was compiled with Argon2 support.
cont’d if ($valid && password_needs_rehash($hash, PASSWORD_DEFAULT)) { // Create a new hash, and replace the old one $user->hash = password_hash($password, PASSWORD_DEFAULT); } verify-password.php
obtain and use a password; it doesn’t verify anything! Two or more different authentication factors goes much further in determining the authenticity of a user.
way of persisting data between requests. Session data is stored server-side. When a session is created in PHP, a random session ID is generated. The ID is stored in a `PHPSESSID` cookie.
similar to the data a PHP Session might contain. The difference is that JWTs do not require server storage. Using a shared secret, JWTs can be decoded and validated across multiple services.
to a hash using your shared secret, you can verify that the contents of the JWT are authentic and have not been tampered with. How can I trust that a JWT is authentic?
of registered (useful, interoperable) claims, which include: ◦ aud - audience ◦ nbf - not before ◦ iss - issuer ◦ exp - expiry ◦ iat - issued at ◦ sub - subject
add your own custom claims to a JWT. Custom claims should be namespaced to avoid collisions. It is recommended to namespace claims using a domain you control. { "sub": "Katy", "https://katy-ereira.co.uk/fav_color": "purple" }
sent in request headers; many servers do not support headers larger than 8kB. Try and keep your JWT and its claims as minimal as possible! • JWTs cannot be invalidated, but they can expire. Set a short expiry time and validate against this to mitigate interception. • Claims within JWTs are only base64 encoded. Don’t encode anything sensitive!
is over 18 therefore I am permitted to play the lottery” • Very granular and flexible. • Can be used to create complex access conditions. • Can consider of a large number of attributes ◦ nature of actions, time, location, relationships, roles, ages, etc.
a site administrator therefore I am authorised to delete posts” • Applies set permissions to generalised groups of people • Less complex access conditions when compared with ABAC • May be harder to scale as the number of roles and permissions grow
this student, so I may view their reports” • Easy to reason about • No need to assign roles or attributes • Harder to scale; when relationship structures evolve, so must the access control
the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. Reference: https:/ /oauth.net/2/
that requires access to resources owned by a Resource Owner and protected by a Resource Server. To access resources, a Client must be Authorised by the Resource Owner.
requests from the Client for access to protected resources. It issues access credentials upon successful Authentication of, and Authorisation by the Resource Owner.
the Resource Owner's resources. It receives resource access requests from the Client. The Client sends access credentials along with its request, which the Resource Server verifies. Upon verification, the Resource Server returns the requested resources.
of OAuth 2.0 implementations. These include: Facebook, Google, LinkedIn, Instagram, etc. By registering a Client, you can ask a Resource Owner for Authorisation using the provider’s OAuth Server. An authenticated user’s email address may be all your Resource Server needs to validate and fulfil the request.
course, you can implement your own OAuth 2.0 provider by following the OAuth 2.0 specification. For now, let’s assume we are integrating with an existing OAuth 2.0 provider such as Google, and that our services have their own database of users with email addresses that belong to Google accounts.
a resource owner to grant access to a protected resource via an OAuth provider. Each method for receiving authorisation to access to a protected resource is called a ‘Grant’.
code is exchanged for an access token. The authorisation code itself can be securely transferred around a server-side application. Proof Key for Code Exchange (PKCE) is an additional step that makes authorisation code grants more secure for mobile and single-page applications.
trusted clients only, the Resource Owner can give its own credentials to the Client (i.e. their username and password), which the Client can then use to authorise with the Auth Server.
why the OAuth working group recommends against using or enabling this grant in your OAuth server, and it has been intentionally omitted from the draft OAuth 2.1 spec. Ref: https:/ /datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.4 How can I trust that the client will store the user’s credentials securely?
its own credentials (e.g. a client ID and secret) to authorise with the Auth Server. This type of grant is used for non-interactive services that do not involve a Resource Owner; e.g. machine-to-machine operations.
to authorise browserless devices, such as smart TVs. Does not require any interaction with the Auth Server; instead, depends on the Resource Owner authenticating and authorising the device manually.
Client can refresh its own grant using a securely stored, longer lived refresh token. A Client can maintain access to protected resources without having to ask the Resource Owner for re-authorisation.
always! • Validate redirect URLs - anything in the request can be edited by a malicious actor. • Use short-lived access tokens, long lived refresh tokens; it should be possible to invalidate longer lived tokens. • Avoid exposing information about your registered users to the public.
maccath
kajitack
kishida
danielsogl
manfredsteyer
antonarhipov
nrslib
pocke
satohjohn
yug1224
andpad
chobishiba
macha64
jnunemaker
tammyeverts
mclloyd
katarinadahlin
techseoconnect
aleyda
jonoalderson
honzajavorek
szymonslowik
eileencodes
marcelosomers
![@maccath | Katy Ereira Logging out <?php session_start(); unset($_SESSION['loggedIn']); //](https://files.speakerdeck.com/presentations/cf3db500b9a74138bbce1307d785e46f/slide_28.jpg){kind=link}
