Non-ASCII characters in passwords cause error 500

Issue #300 resolved
Vladislav Glinsky created an issue

Kallithea version: 0.3.3

Expected result:

On Unicode input form validation shows message for invalid password and form sumbitted without errors on valid password

Actual result:

"500 Internal Server Error" page shown

Server logs contain error:

WebApp Error: <type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't
encode character u'\u042f' in position 0: ordinal not in range(128)

Steps to reproduce:

  1. Go to log in form
  2. Use existing username
  3. Fill password field with any non-ASCII characters
  4. Submit form

Comments (10)

  1. Mykyta Solomko

    Kallithea is being run using uWSGI + virtualenv.

    OS: Slackware64-14.1
    uWSGI: 2.0.15
    Python: 2.7.14

  2. Mads Kiilerich

    Can you reproduce the problem with paster serve?

    What is LANG and other locale environment variables set to for the WSGI process?

  3. Vladislav Glinsky reporter


    Today I've reproduced the problem clean install with default config using paster serve:

    File 'kallithea/lib/auth_modules/', line 89 in auth
      password_match = auth.KallitheaCrypto.hash_check(password, userobj.password)
    File 'kallithea/lib/', line 129 in hash_check
      return bcrypt.hashpw(password, hashed) == hashed
    UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128)

    password contains: u'\u043f\u0440\u0438\u0432\u0435\u0442'

    Full server log can be found in attachments.

    Locale environment variables:

  4. Mads Kiilerich

    Right, got it, thanks.

    Kallithea has always rejected non-ascii passwords. That was inherited back when we forked. The password change form will reject attempts at setting such passwords with Invalid characters (non-ascii) in password. This crash must thus only be an annoyance when users mistype their password?

    I have pushed fefd7279e798 to the stable branch to fix the 500 error.

  5. Vladislav Glinsky reporter

    Yes, I ran into this problem when I entered my password in wrong keyboard layout.

    Since passwords aren't stored in plaintext, I think there's no point in restricting password contents, except it'll require Unicode normalization.

  6. Mads Kiilerich

    Allowing unicode in passwords would however require us to consistently handle unicode (and normalization) everywhere to avoid users getting locked out. That would be extra annoying for internal accounts - they are the last resort if all other kinds of authentication should fail. Thus, with finite resources, I think it is ok to restrict to pure ascii when setting passwords.

  7. Log in to comment