2.2 Upgrade brakes admin password with German Umlaut ö
-
What makes you think this was caused by the umlaut? Did you see an error?
The only locale error I've seen threw out a load of PHP errors in the webgui.
Steve
-
I created yesterday a new admin on another pfsense 2.1.5, with the ö Umlaut and reproduced the same problem after upgrading.
The only special character in comparison to my other admin password was ö.php-fpm[92108]: /index.php: webConfigurator authentication error
As I said, I will try to reproduce this as soon as possible on a default 2.1.5 install.
-
Definitely a Bug in pfsense 2.2 upgrade!
I was able to reproduce the problem by using a default 2.1.5 install and adding Umlaut ö in the password.
As soon you upgrade to 2.2 your password is no more valid.
As said before, in pfsense 2.2 you can create a working password with the character ö.Could this be an encoding problem (UTF-8) in PHP?
This is now far out of my comfort zone but is it possible that the character ö, ASCII code page layout position 246, gets not correctly translated in pfsense 2.2?
http://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout
http://en.wikipedia.org/wiki/UTF-8
-
OK - just to see clear:
- ö in a password works fine in a fresh v2.1.5
- ö in a password works fine in a fresh v2.2
- ö in a password breaks when upgrading from v2.1.5 to v2.2
???
-
Yes.
-
In case my suspicion is correct following characters should also pose a problem :
õ ; ÷ ; ø ; ù ; ú ; û ; ü ; ý ; þ ; ÿ
And maybe :
À ; Á
Will try this as soon I have the time…
-
Hmm, that's odd. The password is stored as a hash and I can't see how that could be changed across an update. My best guess is that the hashing algorithm changed between pfSense/FreeBSD versions so the old hash no longer matches.
Steve
-
The problem could be before hashing, probably utf-8 encoder changes.
-
I was able to reproduce the same problem with : õ ; ÷ ; ø ; ù ; ú ; û ; ü.
As well as : ä and è.I did not test further, but I presume this is the same behavior for all International/Special Characters.
Can somebody else confirm that this is a bug?
I was aware that International/Special Characters caused problems with user names, LDAP authentication server, XML config and maybe others but not in user passwords.
I get this log in 2.1.5 after creating admin users (Also admin users where there are no International/Special Characters):
Feb 8 00:42:05 php: /system_usermanager.php: The command '/usr/sbin/pw groupmod admins -g 1999 -M 0,2000 2>&1' returned exit code '67', the output was 'pw: user `2000' does not exist'
Feb 8 00:42:05 php: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing.Log for non admin user:
Feb 8 00:52:43 php: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing.
Users with no International/Special Characters do work after upgrade!
I compared the XML files (2.1.5 and 2.2) and did not see any problem there.
-
mutters something about shooting yourself in foot and moves on
-
-
mutters something about shooting yourself in foot and moves on
Not helpful :-(
As I said I get this log in 2.1.5 also with passwords that work after the upgrade!
Please enlighten me. -
Yes. Do not use stupid characters in passwords. Do not use stupid characters in usernames that are supposed to be used across platforms either. Stuff like these funny POSIX portable filename character set or POSIX user name restrictions exist for a reason. Beyond that, typing these characters somewhere is internet cafe with a keyboard missing those characters is a huge "fun" as well.
-
Weirdly enough I partially agree with you.
So let’s state in the manual we allow only these characters to be used.But the real world works different, as you can see from Chris Buechlers answer here:
https://redmine.pfsense.org/issues/4201
I did hope somebody else could confirm this problem.
Nobody there but me?
So maybe you are right and I’m the only idiot who shoot himself in the foot but at least I learned something.
Thought it was worth to share my pain in this forum. ;)
P.S.: Using a PC in an Internet Cafe, you are joking, now you shoot yourself in the foot. :D
-
I agree with you. If those characters are not allowed then fine just declare that and reject them. The issue here is that only are they allowed but that also they appear to work fine, in both versions. Somewhere in the chain the method by which the password hash in generated from the entered password has subtly changed. This seems like a bug to me, have you created a bug report on redmine?
Steve
-
No.
I'm waiting for someone to confirm it. -
Ok, I'll try to do that this evening.
-
Do not use stupid characters in passwords.
OFF
Titling such characters "stupid" is a bit tough statement. Please don't state them as stupid, because people using them as part of their language and culture may get offended.
“In 1776, one vote gave America the English language instead of German.”
ONAdditionally: using such characters in a password is recommended where possible IMHO, as the chances to break them decrease substantially, simply looking at the simple fact that brute force attackers have to test and try a bigger character set than simply English (I admit that's just my paranoia though, but hey… never say never).
It's the responsibility of the end users what passwords they use, pfSense should handle properly these characters too, if not stated otherwise.
-
Yes. Do not use stupid characters in passwords. Do not use stupid characters in usernames …
These characters are regular characters in other parts of the world. Just because you don't have them does not mean they are stupid. Your ignorance is smelling badly! Period.
-
These characters are regular characters in other parts of the world. Just because you don't have them does not mean they are stupid.
Yeah. So are Chinese. Or Arabic. Or whatever. How much testing you think e.g. usage of Chinese chars in password, PSKs or similar has received in pfSense? Can pretty accurately estimate it to zero. People have better things to do with their limited time, really, or even have no way to test such stuff. Still feel like shooting yourself in foot? Enjoy.
(Anything pre-2.2 was using ISO-8859-1, not UTF-8. Anything outside Latin-1 charset got mangled badly as soon as you did hit the Apply/Save/whatever button - numerous examples can be found on Redmine.)
