2.2 Upgrade brakes admin password with German Umlaut ö
-
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.)
-
I actually agree with doktornotor, that this is not an easy task.
Many desktop distributions mess it up over and over again.
So maybe it is safer for pfsense to stay away from the problem.At the end even thought for some it's so bleeding obvious ;D, does not mean that an idiot like me does know this.
I thought that’s the point of a release info and Installation Manual.
Plus I’m still not convinced that Chris Buechler agrees with doktornotor but that's probably politics…Does this means you are 100% aware of the problem?
As you said it yourself somewhere in this Forum on April 23, 2014, 11:34:22 am :
"... maybe you could move your ass to produce an actually working howto." ;)
-
Does this means you are 100% aware of the problem?
This one? No. I'm aware of multiple other problems with characters outside ASCII/Latin-1 breaking configuration altogether, e.g. with captive portal, rules description etc.. Example: instead of š, you got <9A> saved in config, producing nifty "XML error: Invalid character at line …." error and configuration rollback.
Now, granted - things like this should not happen, however I for one do not see any viable way how to fix hashed mangled passwords saved on 2.1.x via configuration upgrade to 2.2. As for the problem here, one way to verify how this happens would be to check with different "stupid" chars and verify whether the password actually works on 2.1.x both when using the WebGUI and SSH. Pretty much doubt so.
A bunch of stupid chars you can try: ěščřžýáéúůďťňó
-
I've confirmed this on a box I was testing using the password 'passwörd'. Exactly as you described, works fine in 2.1.X. Works fine in 2.2 but is not valid after an upgrade.
Works just fine for SSH in 2.2. Not going back to try in 2.1.X. ;)
The issue here is not one of whether or not you should be using these characters. It's that if they are going to be valid input in both versions then they should continue to function across an upgrade.
Steve
