htpage

Security features

I am not a security expert. htpage was not written by a security expert. Keep this in mind.

That said, I have of course tried to make htpage as secure as I have deemed both possible and feasible, and to a certain extent, its purpose has been to serve as an educational project for myself in implementing as many intelligent security features as possible. If I discover an article about XSRF exploits, or session hijacking, I’ll read the article to understand the problem and update htpage to practice implementing the solution.

Caveat emptor, as always, and you aren’t paying money for this; but it’s not a system devoid of precautions, and I will even do you the courtesy of openly presenting some of the highlights.

Session security

• All page views require or initiate a session. Thus, all session-related values are available on every request.

• The session is identified by three tokens;

  • A “public key” cookie, which is a normal cookie, accessible to JavaScript;

  • A secret key (“key”) cookie, with the HttpOnly property set, which in UAs that support this feature makes it harder to steal via Javascript or inspecting the DOM. (The good news is that most modern browsers do support the HttpOnly flag: Opera 9.5, Internet Explorer 7, and Firefox 3. The Firefox bug mentioned in Atwood’s article has since been fixed.)

  • A form token provided with POST submits. For idea security, this should be a cryptographic nonce. However, this would sacrifice usability a little more than I am comfortable with: The same POST token is used across all pages within a session.

  Each of the three tokens is a randomly generated value of ≥128 bits.

• Every visit verifies the session using both tokens.

• Every page receives a token for verification, as protection against XSRF attacks.

• POST requests verify both token, and the POST XSRF token, and a “security hash” that is the MD5 checksum of, the POST token with the “pkey” cookie appended to it. This ensures that a POST request comes from an agent with simultaneous access to the cookie and the DOM (as opposed to an attacker who steals the token by somehow accessing the DOM, and uses an XSRF attack to submit an attack with the legitimate cookies blindly attached).

• All of these features are active in guest and user sessions alike. Login merely associates a user with the pre-existing (guest) session, “promoting” it to a logged-in session.

User management

The htpage platform stores user information securely. Passwords are salted with random cryptographic nonces. (The salt is currently 128 bits; if you need a stronger salt than this, then your attacker has one hell of a rainbow table and you should use a proven platform that is far more secure than htpage!)

No passwords will ever be stored in plain format; password reset requests email randomly-generated passwords to the user. (Obviously, these emailed passwords are really only as secure as your email.) If you’re paranoid, make sure that you access password-protected pages over HTTPS only. But if you’re that paranoid, you already know that...

Footnotes

Random values

htpage uses a “best effort” approach to good random values. If a true random number generator is available (and it generally will be), it will be used; if not, the standard pseudo-random number generator is, alas, used instead. The code used is (essentially)

try:
    from random import SystemRandom
    _rand_generator = SystemRandom()
except ImportError:
    import random
    _rand_generator = random

Translating into plain English (sort of), the user/session classes will use SystemRandom, which in turn relies on os.urandom(), if it is available. os.urandom() returns a string of n random bytes suitable for cryptographic use:

This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a UNIX-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom. If a randomness source is not found, NotImplementedError will be raised.

On the off chance that your (non-*nix, non-Windows) platform, or your Python implementation, does not provide os.urandom(), the standard library PRNG will be used instead. This will be less secure.