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, ie software or hardware.
      ☑⁡⁡ IT (Information Technology): Broader that cyber, includes the physical world, acknowledging real-world attack vectors such as human and business needs.
        ◆ Always consider the real-world dimension to security, ie, biometrics over weak or complex, written passwords.
  • ▼ The CIA Pillars of IT Security:

    • ☑⁡⁡ C[onfidentiality]: 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.
      ☑⁡⁡ I[ntegrity]: 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.
      ☑⁡⁡ A[vailability]: 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 (ie, databases) vs volatile and temporary transmission (ie, page files or RAM).
  • Middleware:

    ▼ 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:

    • ☑⁡⁡ A[uthentication]: identifying the user and system.
        ◆ Passwords: long alphanumerics, ie partial phrases with both upper and lower cases and special characters.
        ◆ Biometrics: physical features, ie fingerprint, facial landmarks, eye's retina scan, iris pattern recognition, heart rate, etc.
      ☑⁡⁡ A[uthorization]: enabling/disabling features according to the specific privileges of the user.
        ◆ User tiers: Users of ranked feature privileges, ie Guest, Worker, Mod, Admin.
      ☑⁡⁡ A[uditing]: maintaining and updating the security by studying data.
        ◆ Logging: inspection of older activity.
  • bcrypt:

    ▼ Features:

    • ☑⁡⁡ 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 (ie, outside of the database, making the security much more difficult to breach).
        ◆ NOTE:Syntatic Sugar simplifies code syntax, ie 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, (ie 3.1415926535...) for numbers that appear random, but are not.
      ☑⁡⁡ Invented by Niels Provos and David Mazières in 1999, based upon theirEksblowfish (Expensive Key Setup Blowfish) key transforms, making it an elaborate set of rounds and tweaks to Blowfish.
  • ▼ bcrypt Middleware:

    • ☑⁡⁡ Has a decoding speed of [Big-]O(log n) time algorithm, 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 for security, signal processing, etc.
      ☑⁡⁡ Implementations: C/C++, C#, Go, Java, JavaScript, PHP, Python, Ruby and more.
  • ▼ [User] Session (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:

    • ☑⁡⁡ Cookie [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.
        ◆ 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]Cross-Site Scripting) and must be sent from the same domain (ie, 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 (ie, mySite.com to hackerSite.com) in the HTTP[S] 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 (ie, 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 (ie, 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 was 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 (ie, Blowfish).
        ◆ IE, HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret);
  • Like this post? Read more from the ^Security topic.


           : NEWS