bcrypt & JWTs vs Cookies

Dec.11.2017 | 8m Read | ^Security

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:

▼ Considerations:

    • ☑⁡⁡ 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).
  • Middleware (software):

    ▼ 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).
  • bcrypt:

    ▼ Features:

    • ☑⁡⁡ 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).
      ☑⁡⁡ Implementations: C/C++, C#, Go, Java, JavaScript, PHP, Python, Ruby and more.
  • ▼ 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:

    • ☑⁡⁡ Cookie (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.
        ◆ 4kb of storage.
      ☑⁡⁡ Session Storage:
        ◆ 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+).
      ☑⁡⁡ Local Storage:
        ◆ 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.
  • Like this post? Read more from the ^Security topic.


           : NEWS