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

Description

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:

Go to log in form
Use existing username
Fill password field with any non-ASCII characters
Submit form

Attachments

out.log

Comments

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

Hello,

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:

LANG=uk_UA.UTF-8
LC_CTYPE="uk_UA.UTF-8"
LC_NUMERIC="uk_UA.UTF-8"
LC_TIME="uk_UA.UTF-8"
LC_COLLATE="uk_UA.UTF-8"
LC_MONETARY="uk_UA.UTF-8"
LC_MESSAGES="uk_UA.UTF-8"
LC_PAPER="uk_UA.UTF-8"
LC_NAME="uk_UA.UTF-8"
LC_ADDRESS="uk_UA.UTF-8"
LC_TELEPHONE="uk_UA.UTF-8"
LC_MEASUREMENT="uk_UA.UTF-8"
LC_IDENTIFICATION="uk_UA.UTF-8"
LC_ALL=

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.

Kallithea issues archive