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