2.2 Upgrade brakes admin password with German Umlaut ö
-
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
-
OFF:
Dear doctornotor, jahonix and me were just pointing you to your attitude other culture. If you would have simply used the word "special" instead of "stupid", you wouldn't have offended anyone.
Plus, there are many customers from non-English areas of the world who actually pay and support this project, at least their culture should deserve a little respect.
It's not about the "shooting yourself in foot" joke and the time needed to test things etc.
ON -
Th other day I saw 2.2 would be based FreeBSD-10 and my 2.1.5 was on FreeBSD-8, I decided an upgrade route would be risky. So I made a parallel fresh install and imported the config-XML.
-
For the default installation of pfsense, I realized that I can login over SSH if I use as Translation ISO-8859-1.
All characters unknown to Latin-1 got refused in any way by pfsense 2.1.5.So with the fact that my MD5 Hashes were the same in pfsense 2.1.5 and 2.2 I realized that the solution was quite obvious.
Upgrading pfsense 2.1.5 to 2.2, means a change from Latin-1 -> UTF8.
So this is not a bug.
The password is simply lost in translation!Explanation:
In UTF-8, accented (non-ASCII) characters are multibyte, whereas in Latin-1 they are single bytes. The password hash function would see them as different passwords typed in (and the UTF-8 is longer).
I still believe there should be a notice in the release info of pfsense 2.2 under Translations explaining what's going on.
In my opinion, every password with non-ASCII characters (such as accented "French" characters) should be changed by the admin before upgrading to pfsense 2.2.
As pfsense uses now UTF-8, all Special Characters in a password should be possible but as doktornotor and the pfsense release info states be aware of this problems when using other software that's not using UTF-8.
Thanks to all for the input.
-
Exactly. Not a software bug but a documentation issue.
Steve
