Bug #14256
closedspecial characters in username not checked
0%
Description
I created an account containing German umlauts ("özgün") and without any complain typo3 created the account (should there be regexp check?). The Problem is: I cannot log in with that account.
Since the md5 checksum in the challange response authentification seems to be wrongly implemented on the javascript side I googled the web for alternatives and found out that http://pajhome.org.uk/crypt/md5/index.html works flawlessly with the corresponding php method. The file appended is the one I overwrote the original typo js-source with.
(issue imported from #M254)
Files
Updated by old_fholzke over 20 years ago
I have to add that replacing the md5.js file is not that easy since some typo functions may rely on functions in the original md5.js code. Due to the lack of indepth typo3 knowledge I simply concated both files and disabled MD5 func from the original source.
Updated by Rupert Germann over 19 years ago
this was fixed in 3.7.0
I tested the FE-login on TYPO3 3.7.0 and 3.8.0dev and it works with umlauts in username and password.
Updated by Wolfgang Klinger about 19 years ago
This does not work with backend user accounts.
http://tuga.at/index.php?id=602&tx_maillisttofaq_pi1[showUid]=6462
Updated by Bernhard Kraft about 19 years ago
The attached patch "01_BELogin_utf8.patch.diff" fixes the problem with the BE-Login. The problem is that the string which get MD5 encoded get read character by character with the JS function string.getCharCodeAt(pos). But this function doesn not return values between 0 and 255 as a MD5 encoding method would expect from bytes but also values above 255 when it is a unicode character. Therefore the string has to get converted to a binary utf-8 representation before feed to the MD5 function.
Also it is required to replace the md5.js script because the MD5 function which was used until now in TYPO3 works just well with characters below 128 (default ascii characters). With characters above this value it generates an invalid hash (compared to the hash PHP generates).
Of course this will only work if "forceCharset=utf-8" is set. Since the MD5 function is replaced it will possibly also work with other forceCharset's than utf-8
Tested under Firefox and IE.
Updated by Bernhard Kraft about 19 years ago
Just an improved version of the patch. With this version it is also possible to have Umlauts or Japanese characters in usernames/passwords also when forceCharset is not enabled. But for this to work you will have to set the newly introduced option in the Install Tool :
TYPO3_CONF_VARS[BE][loginLanguageSelector]
After enabling the patch you will have to set the Username/Password of the account with special characters again. And also please don't forget to verify that the modified JS scripts get loaded correctly by the browser ....
When everything goes fine you shall have an extra select box in the login screen where a user can choose in which language his username/password combination is ....
If you have just ASCII values below 127 in your username/password you should be able to log in using any language. But please note that the selected language doesn't change the language used in the BE.
Updated by Ralf Hettinger almost 18 years ago
For FELogins:
I recognized that at least under the circumstance that forceCharset is set (eg by the Install Tool), the problem will still persist (might as well be a new one with the same symptoms) since the username won't be queried correctly from the db.
As a first glance I have tracked the problem down to be hotfixable in typo3/sysext/sv/class.tx_sv_auth.ph for a specific installation (no patch attached since this is no good meaning general solution).
The following diff (against RC 4.03) shows as example how this could be fixed for forceCharstet==utf-8 and might be of help for those who have a better knowledge about the authorization process of TYPO3
--- class.tx_sv_auth.php.bak 2006-12-11 12:16:43.926364432 0100
++ class.tx_sv_auth.php 2006-12-11 12:21:39.156482632 +0100@ -66,7 +66,9
@
if ($this->login['status']=='login' AND $this->login['uident']) {
- $user = $this->fetchUserRecord($this->login['uname']);
+ $user = ($GLOBALS['TYPO3_CONF_VARS']['BE']['forceCharset'] == 'utf-8')?
+ $this->fetchUserRecord(utf8_encode($this->login['uname'])):
+ $this->fetchUserRecord($this->login['uname']);
if(!is_array($user)) {
// Failed login attempt (no username found)
Updated by Ralf Hettinger almost 16 years ago
Just a further observation unfortunately without digging into details on this very very old one.
FE LOGINS
Considering the following constellation I haven't been able to get md5 encrypted passwords for FE logins (fe_user) having special characters working at all with the shipped typo3/md5.js in 4.2.2. There seems to be a difference of how md5 hashes are built between php and the typo3/md5.js MD5
The following constellation works for me (unfortunately with hacking EXT:md5passwords a bit to strip slashes) for special characters in passwords being set by forget passwords function (fe_login), user self registration (sr_feuser_registration with using above typo3/md5.js) and using the backend to set passwords (again using above typo3/md5.js):
- TYPO3 4.2.2
- $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
- fe_login 1.0.0
- md5passwords 1.0.3 activated=1 (patched to strip slashes ' " \ in passwords)
- sr_feuser_register 2.5.19 useMd5Password=1
- md5.js from above replacing typo3/md5.js
So I would think the above md5.js attached in 2004 (!) still being crucial for special characters within any string that gets passed through MD5 in typo3/md5.js... hopefully I'm wrong ;)
BE LOGINS
Regarding the backend login: It didn't seem to matter wich typo3/md5.js being used if used consistently (not to astonishing I suppose since backend forms and backend login refer to the same typo3/md5.js). So in general passwords with ' " \ and special characters do work no matter which typo3/md5.js is used.
Understandably, backend logins with passwords containing special characters will fail to work for passwords being set with the "old" typo3/md5.js after replacing that typo3/md5.js with the above.
However, having a special character in backend username did prevent logging in no matter which md5.js is used. Maybe Bernhard's patches do the trick - this is still to be tested.
Having " in backend username, I was able to log in but had a backend not working in FF3 (Modules in the left weren't clickable.
Updated by Nils Winkler over 15 years ago
Hello,
is there a plan when the MD5 / UTF-8 problem will be fixed?
I have the same problem with special characters in user name and password fields.
I'm using TYPO3 4.2 and TYPO3 4.2.6 / PHP 5.2.6
Best regards, Nils.
Updated by Steffen Gebert almost 14 years ago
It works with saltedpasswords (which is the future :))
Nevertheless, I've set #22328 as 4.6.0 target, hopefully we can fix this until then.
Updated by Helmut Hummel about 13 years ago
- Status changed from Accepted to Needs Feedback
- Target version deleted (
0) - TYPO3 Version changed from 3.8.0 to 4.2
- PHP Version deleted (
4)
Cannot reproduce with backend login in version 4.6 and password set to "äöü"
Frontend login with md5 is not part of the core and cannot be fixed there, besides that I agree with Steffen. Saltedpasswords will be default in 4.6, so this is obsolete anyway
Updated by Helmut Hummel about 13 years ago
OK, can confirm it for umlauts in username. Nevertheless it works with rsaauth and saltedpasswords
Updated by Steffen Gebert almost 13 years ago
- Status changed from Needs Feedback to Resolved
- Assignee changed from Bernhard Kraft to Steffen Gebert
Resolved by #22328