Hacker News Reader

Comment by marcinw | Hacker News Reader

Unfortunately, for a lot of us working in locked down environments, this code makes use of the py-bcrypt module which uses the bcrypt C implementation. If you're running on GAE, you're out of luck. I keep telling myself to port to pure Python, but haven't had time. Anyone interested?

View on HN

I see that Google allows you to use the crypt module, and I would wager that their Python is linked against glibc, in which case, you might be able to use sha-crypt. It's worth checking. e.g.:

  def encode_password(password):
    """Return crypt() encoded password"""
    # Uses glibc SHA-crypt extension via $6$
    salt = b64encode(os.urandom(8)).rstrip('=')
    return crypt(password, '$6$' + salt)

There's a pure-Python implementation of PBKDF2. I know it's not as good as bcrypt or scrypt, but at least it's better than MD5 or one of the SHA's.

I saw a Twitter discussion with Colin a couple weeks ago here he pointed out that Python no longer guarantees constant time for all of the basic binary operations like addition (since fixed width integers can spill over to arbitrary precision math if you overflow them, or breathe on them wrong).

Be careful.

Oh boy. That could get messy.

Password hashing function almost by definition does not handle any data that must be protected from the user, so side channel leaks do not make much sense. Only secret information comes into play in final comparison of hash of user supplied password and your stored hash and I don't see any way of exploiting possible timing leak in that comparison that does not require breaking the hash in the first place.

Side channels don't matter for bcrypt.

Can you explain why this is? (Not doubting you; just curious.)

The online operations exposed to an attacker in a bcrypt system are done almost entirely on attacker-known data.

Reply on news.ycombinator.com