Should the Fernet encryption system be used with API keys?

Will require looping through collections to find session data collections. In session data collection the script will need to search for old datetime objects. Mongodb < query operator might help.

Sessions without data should be removed.

#55 Breaks the install system by introducing new dependencies

JavaScript code is currently not namespaced resulting in potential global namespace pollution. This problem is exacerbated by the server blindly concatenating and sending JavaScript without checking to name collisions or code validity.

Additionally it would be nice to build the tracking scripts once rather than dynamically compiling them on page load

In order to rectify these issues a build system is needed. TypeScript seems like a good candidate for this.

Identical code found in 1 other location (mass = 37)

https://lima.codeclimate.com/github/michardy/account-hijacking-prevention/modules/fingerprint.py#issue_58bdf13d19a33a0001000019

https://github.com/michardy/account-hijacking-prevention/blob/unittests/hijackingprevention/api.py#L61

The get_trust API call can be induced to throw a noncommittal 500 internal server error if an attacker lets all their temporary session data expire before asking for trust. Depending on how the application issuing the get_trust API call is implemented this may result in the attacker gaining privilege.

The initial reasons for using Python & Tornado were that:

1. I was familiar with Python
2. Using Python made extending the server easy
3. I knew how to use Tornado
4. Tornado is designed to scale to concurrently handle 10,000 connections and thus it seemed like a good choice for data collection.

Along the way I encountered a few problems:

1. Tornado is single threaded (this is intentional to allow scaling efficiently). Computing expensive hashes blocks the main Tornado thread
2. Tornado's strategy of handling everything on a single thread may allow it to handle the post requests from the data collection system efficiently (these requests don't need an immediate response) but it does not meany that it will render user pages in a timely manner.

Reasons I am considering making this change now:

1. I am already considering a substantial rewrite
2. Changing the database engine away from MongoDB & Motor will require a lot of work to avoid nullifying the advantages of using Tornado.

Salts should be stored base 64 encoded. Binary strings are possibly being depreciated.

Taken from Travis build:

/home/travis/build/michardy/account-hijacking-prevention/tests/../hijackingprevention/client.py:7: DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 3.7
  self.async = []
-- Docs: https://docs.pytest.org/en/latest/warnings.html

This is the line at fault:

It gets imported and reexposed by hijackingprevention.rec

In order to prevent user spoofing and allow for better protection of user privacy any user data that does not need to be computed on is hashed. Unfortunately the current system slows the server down considerably. This is not a bug the hash function in use is designed to significantly increase the cost of brute forcing the hash by intentionally increasing hashing times.

Problems

The potential security gains of hashing are offset by four major problems:

• Calculating the hash blocks the main thread preventing multiple simultaneous authentication requests (This can be fixed by using Tornado correctly but will still limit scaling)
• The all session data is salted with the same key per site minimizing the amount of work required to brute force the hash (this unfortunately cannot be fixed. See #1)
• Even though user data is salted per site and then again individually almost all user data must be in the session pool
• The entropy of the data being salted is ridiculously low. (For example see user agent strings)

Benefits

Session hashing does make it harder for the authentication server owner to perform cross site tracking

Scenario: Attacker steals session cookie and runs NoScript

Result: Assuming the data for the session has not expired the attacker is let in because no data was collected about the attacker.

Solution:

• shorter expire times for collected data
• more continuous data collection like described in #27 (Does not work. Hacker still has session cookie)

Mitigation:
Site owners can and should mitigate this and many other security issues by following recommended session security guidelines:

• Following OWASP guidlines for session security
  • Ensure that session tokens are both adequately long and random
  • Use secure same site cookies (They cannot be used on un-encrypted connections or in connections to other sites)
  • Using SSL/TLS to protect their session cookies.
  • Make sure that session tokens expire, and that they do so at both the client and server ends.
• Following OWASP guidelines for protection against XSS attacks. general, DOM based
  • Properly escape and sanitize all inputs
  • Create a secure content security policy
• Implementing secure cookies so that they can only be used by one IP

Unit tests?

This would be nice but would require a task scheduler that knows when not to wait for a function to run. It also would require restructuring the data submission API.

Unauthorized add data requests fail silently. Instead of returning a 401 and a message saying access had been denied due to an invalid host the server returns a 200 with the message "OK"

Also the client side scripts should log this to console and the server should log this as well.

migrate from print to logging

Scores greater than 1.0 are possible if you re-register a user already scoring 1.0.

If their are multiple registrations for a user and an attacker partially matches multiple of them it is possible that they might get a trust score greater than 0.5.

Collected session data cannot be collected and hashed before the user is known.
Data can be salted with a constant until user is known. (This is a very bad idea)

Mitigation:
API users can mitigate this by not using the user's email for the UID. This means that in the event the API's database is hacked, the data about users cannot be tied to any of the users' accounts.

Move modules to subfolder. Subfolder may need to be added to Python path.

Also cross browser testing.

Should session data should be moved to a Redis cache?

Why it should be in cache:

• There is no particular reason to temporary data on the database
• Redis data can expire without a cleanup job

It probably should not do that.

Global events:

• window.onload
• window.onkeydown
• window.onkeyup

I need to chose a new database system to run the authentication store on top of.

While MongoDB is a good system for rapid application development (which is why I initially chose it), it does not guarantee consistency. This makes it a bad choice to implement an authentication system on top of.

The database code no longer errors with nonexistent users and sessions but instead returns an empty object. These non existent sessions and users have a trust score of zero.

Is this a problem?

Fernet should be used with verification codes. Use of Fernet will also allow for codes to expire.

Allow for the checking of more than one hash per user per data source.
/modules/fingerprint.py#L23

Document Installation, API use, and how to write modules

Add more errors to API. For example throw an error (other than 500) when an API key does not exist.

Also an option to stop collection when a tab loses focus might be nice.

It might be advisable to support a more generic email system. Initially I intended to send email through Sendmail but I have subsequently realized that sendgrid is a lot easier to set up. In order to avoid locking project users into a paid for service I will try to add a more generic email API supporting both SMTP and sendgrid.

Check dependency file for unused dependencies.
I am not sure that I am using Requests.

Similar code found in 1 other location (mass = 115)

https://lima.codeclimate.com/github/michardy/account-hijacking-prevention/modules/fingerprint.py#issue_58bdf13d19a33a0001000017

Move API key -> ID Conversions to root calling function in main.py.

The initial hash function should be one that is slower than SHA512. Bcrypt can be manually salted (I don't know if it should be though). The python library for Bcrypt appears to use os.urandom(16) to generate salts, so the current salt system should do (although the salt length should be shortened from 32 to 16).