Here we cover some core concepts of security and progress down the cryptographic rabbit hole of passwords, encryption, and web storage. Buckle-up Buck-o.
Cyber vs IT Security:
☑ Cyber: anything in the digital realm like software or hardware.
☑ IT (Information Technology): broader than cyber, includes the physical world, acknowledging real-world attack vectors such as human and business needs.
◆ Always consider the real-world dimension to security (like biometrics over weak passwords or ones that must be written).
▼ The CIA Pillars of IT Security:
☑ Confidentiality: your data is private.
◆ Encryption: masking data with a code or pattern.
◆ Sandboxing (virtualization): actual system and data is hidden and protected by a virtual one.
☑ Integrity: your data is uncompromised.
◆ Backup Servers: provide failover (redundancy) so data is not lost due to partial failure.
◆ Digital Signatures: additional data attached that when processed, verifies the other data as authentic.
☑ Availability: your data is ready.
◆ Clustering: shared server and data architecture to increase availability (also provides backups for integrity).
◆ Guaranteed Delivery: using a data store for persistent transmission (like databases) instead of volatile and temporary transmission (like page files or RAM).
▼ How does it work?
- ☑ The middleware (software) interfaces or acts as the 'glue' or 'plumbing' between the end user and the system with the actual app.
- ☑ Secures both the user and the app ecosystem from misuse (like the AWS service Cognito ↗).
▼ AAA Middleware Security:
☑ Authentication: identifying the user and system.
◆ Passwords: long alphanumerics (like partial phrases with both upper and lower cases and special characters).
◆ Biometrics: physical features (like fingerprints, facial landmarks, eye's retina scan, iris pattern recognition, heart rate, and so on).
☑ Authorization: enabling and disabling features according to the specific privileges of the user.
◆ User tiers: users of ranked data privileges (like Guest, Worker, Mod, Admin, Root).
☑ Auditing: maintain and update security by studying data.
◆ Logging: inspection of older activity using data (logs).
☑ A configurable password hashing function for securing data.
◆ Cryptographic hashing functions: the input known as a message is transformed by looking up different values from the outputted byte array.
◆ Deterministic: the same message every decode to avoid hash collisions.
◆ One-way function: prevents easily inverting data to decode it.
◆ Have an avalanche effect: small changes of input create dramatic output changes, making it difficult to decode through brute force, or iterating through variations.
☑ salt (cryptography): a form of padding, or random data added (so salting passwords makes them salted).
☑ Peppers (cryptography): a secret added to the password, which unlike a salt, is stored separately from the output (like outside of the database, making the security much more difficult to breach).
◆ NOTE: Syntatic Sugar simplifies code syntax (like an abstracted function that automates or being able to directly access an array instead of using getter and setter functions). Not necessarily cryptographic.
☑ Uses a block cipher (made of a fixed length of bits transformed with a symmetric key) called Blowfish.
◆ Asymmetric key or public-key is a newer method that does not have a single or shared key for both encryption and decryption, making it more secure.
◆ Uses the digits of PI, (3.1415926535...) for numbers that appear random, but are not.
☑ Invented by Niels Provos and David Mazières in 1999, based on their Eksblowfish (Expensive Key Setup Blowfish) key transforms, making it an elaborate set of rounds and tweaks to Blowfish.
▼ bcrypt (middleware):
☑ Has a decoding speed of O(log n) (algorithm time), making it fast considering hash lookups.
☑ Optimized for CPUs instead of GPUs by using a non-cacheable table.
◆ This complicates hardware-based attacks since CPUs are more expensive and have less linking capabilities.
☑ Optimize your encrypted output or attempt to crack using an FPGA (Field Programmable Gate Array) and as much RAM as possible.
◆ FPGAs are essentially processor chips (with an accompanying board) that specialize in processing arrays and can be programmed directly.
◆ They often accompany embedded systems and specialized devices (like for security or signal processing).
▼ Session (User Session or Visit):
☑ A set of user actions over time.
◆ Broken-up and limited by storage means.
◆ Commonly stored on the web using localStorage, sessionStorage, or cookies, and sent in the format of a JWT.
JWTs (JSON Web Tokens):
▼ Data Structure:
- ☑ The JWT format has an additional layer of security with their headers and can be used for sessionStorage, localStorage, and cookies.
▼ Cookies vs session storage vs local storage:
◆ More browser centric, unfriendly to non-browser apps, and does not require HTML5 like Session Storage and Local Storage.
◆ The browser auto sends and stores cookies, a JWT without cookies requires an HTTP request and assigned storage.
◆ Data must be sent to the server.
◆ Expires at the end of the session (as determined by the browser settings and site exit).
◆ Data remains local unless extracted and sent to the server via code.
◆ Larger storage than cookies (5mb+).
◆ No expiration, explicitly cleared in code or via browser settings.
◆ Stores data locally, but can be sent to the server via code.
◆ Largest of the 3 storages.
▼ Storages vs cyber attacks:
☑ All 3 forms of storage are restricted from same-origin XSS (X or 'Cross'-Site Scripting) and must be sent from the same domain (like Google.com cannot send cookies to Gmail.com).
☑ Cookies are particularly vulnerable to an attack called a Cross-Site Request Forgery (CSRF).
◆ This occurs by forging the origin address (like mySite.com to hackerSite.com) in the HTTP (or HTTPS) request header, from a tampered web component, so that your other cookie's session can be hijacked.
◆ CSRFs is prevented by synchronized token patterns and assigning a header (like the HMAC token pattern used in encryption). NOTE: CORS and HTTPS offer no protection against CSRFs.
▼ 3 parts of a bcrypt JWT:
☑ Header: contains the token type, and hashing algo (like SHA256)
◆ alg (algorithm): encryption method in signature. NOTE: HMAC (Hash-Based Message Authentication Codes) are the most common.
◆ typ (type): media type stored in the header.
◆ cty (content type): content structure of the JWT (also stored in the header).
☑ Payload: contains the claims or the 'meat' of the data.
☑ Signature: verifies the encryption through the encoded header, payload, a secret and the encrypting algorithm found within the header (like Blowfish).
◆ Like, 'HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret);'
▼ Claims data in detail:
☑ Claims: data often about the user.
☑ Registered claims: compact predefined claims.
◆ iss (issuer): ids who issued the JWT.
◆ exp (expiration): the time limit to accept this JWT.
◆ sub (subject): ids the JWT's subject.
◆ aud (audience): ids the JWT's intended receiver.
◆ nbf (not before): the time to wait before processing or accepting this JWT.
◆ iat (issued at): the time the JWT is issued.
◆ jti (JWT ID): the unique id for the JWT.
☑ Public claims: custom defined names. Define them as registered names or use a collision-resistant public name.
☑ Private claims: a custom claim that is not public or registered. NOTE: May cause data collisions (lost or corrupted data) that must be resent and mitigated against.