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 can provide backups for integrity.
◆ Guaranteed Delivery: using a data store for persistent transmission (like databases) vs volatile and temporary transmission (like page files or RAM).
▼ How does it work?
- ☑ Software that interfaces or acts as the 'glue' or 'plumbing' between the end user/system and the actual app.
- ☑ Can secure both the user and the app ecosystem from misuse.
▼ 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 fingerprint, facial landmarks, eye's retina scan, iris pattern recognition, heart rate, and so on).
☑ Authorization: enabling/disabling features according to the specific privileges of the user.
◆ User tiers: Users of ranked feature privileges (like Guest, Worker, Mod, Admin, Root).
☑ Auditing: maintaining and updating the security by studying data.
◆ Logging: inspection of older activity.
☑ A configurable, passwordhashing 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: same message every decode, thus avoiding hash collisions.
◆ One-way function: can not invert easily to decode.
◆ Have an avalanche effect: small changes of input, create dramatic output changes making it difficult to decode through brute force, or iterating through variations.
☑ Passwords have salt, a form of cryptographic padding, or data added (random in the case of salt thus salting passwords so they become salted).
☑ Cryptographic peppers: 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 ablock cipher (made of a fixed length of bits transformed with a symmetric key) calledBlowfish.
◆ Asymmetric key or public-key is a newer method that does not have a single or shared key for both encryption and decryption, thus 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 upon 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 vs 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 system and specialized devices (like for security or signal processing).
▼ Session (User Session or Visit):
☑ A set of user actions over time.
◆ Broken-up/limited by storage means.
◆ Commonly stored on the web via localStorage, sessionStorage or cookies, and sent in the format of a JWT.
JWTs (JSON Web Tokens):
▼ Data Structure:
- ☑ The JWTs 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.
◆ Browsers 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 can be prevented with synchronized token patterns (like HMAC used in) and assigning a header.
☑ 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.
☑ 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.
◆ Claims: data often about the user.
◆ Registered claims: compact predefined claims.
☑ iss (issuer): ids who issued the JWT.
☑ exp (expiration): time limit to accept this JWT.
☑ sub (subject): ids the JWT's subject.
☑ aud (audience): ids the JWT's intended receiver.
☑ nbf (not before): time to wait before processing or accepting this JWT.
☑ iat (issued at): time the JWT is issued.
☑ jti (JWT ID): 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.
☑ May cause data collisions, or lost/corrupted data that must be resent and mitigated against.
☑ 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);