Kallithea issues archive

Issue #300: Non-ASCII characters in passwords cause error 500

Reported by: Vladislav Glinsky
State: resolved
Created on: 2017-12-02 23:45
Updated on: 2018-01-20 20:34


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




Comment by Vladislav Glinsky, on 2017-12-03 00:08

Comment by Mads Kiilerich, on 2017-12-07 02:03

How are you running Kallithea? With a plain paster serve? On which platform?

Comment by Mykyta Solomko, on 2018-01-03 18:22

Kallithea is being run using uWSGI + virtualenv.

OS: Slackware64-14.1
uWSGI: 2.0.15
Python: 2.7.14

Comment by Mads Kiilerich, on 2018-01-04 00:23

Can you reproduce the problem with paster serve?

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

Comment by Vladislav Glinsky, on 2018-01-14 19:12


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

File 'kallithea/lib/auth_modules/auth_internal.py', line 89 in auth
  password_match = auth.KallitheaCrypto.hash_check(password, userobj.password)
File 'kallithea/lib/auth.py', 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:


Comment by Vladislav Glinsky, on 2018-01-14 19:12

server log

Comment by Mads Kiilerich, on 2018-01-14 23:35

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.

Comment by Vladislav Glinsky, on 2018-01-16 11:46

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.

Comment by Mads Kiilerich, on 2018-01-17 00:03

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.

Comment by Thomas De Schampheleire, on 2018-01-20 20:34

Issue resolved on stable branch.