ntpasswd not UTF-8 safe?
I don't think that the ntpasswd function in smbencrypt.c is safe with multi-byte character encodings, such as UTF-8. I think that the problem is in the conversion of the password to Unicode, for the construction of the NT hash. The function assumes a single-byte character-set encoding (which works fine for Latin1, etc) but not for multi-byte encodings such as UTF-8. I'm not quite sure what the best approach to fix this is; does anyone have any suggestions? best regards, josh. Josh Howlett, Networking Specialist, University of Bristol. email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | internal: 7850
Sorry, I meant the "ntpwdhash" function... josh.. On 25 Jul 2006, at 09:51, Josh Howlett wrote:
I don't think that the ntpasswd function in smbencrypt.c is safe with multi-byte character encodings, such as UTF-8.
I think that the problem is in the conversion of the password to Unicode, for the construction of the NT hash. The function assumes a single-byte character-set encoding (which works fine for Latin1, etc) but not for multi-byte encodings such as UTF-8.
I'm not quite sure what the best approach to fix this is; does anyone have any suggestions?
best regards, josh.
Josh Howlett, Networking Specialist, University of Bristol. email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | internal: 7850
-List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/devel.html
Josh Howlett, Networking Specialist, University of Bristol. email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | internal: 7850
Dear Josh Howlett, ntpwdhash currently only supports ASCII (7-bit) passwords and this is documented. Common 8-bit implementation with character sets support is extreamaly hard because of different charsets support on different platforms. E.g. most *nix systems use KOI8-r encoding for Russian, while Microsoft uses Windows-1251 as ANSI and cp866 as OEM encoding. Most simple implementation is to insert translation table from 8-bit charset you are going to use to 16-bit little endian Unicode in ntpwdhash code itself. As for UTF-8 - yes, it's possible and it's easy to implement translation from UTF-8 to unicode within ntpwdhash, but it's not clear how to store and mark UTF-8 attributes within FreeRADIUS. --Tuesday, July 25, 2006, 12:51:16 PM, you wrote to freeradius-devel@lists.freeradius.org: JH> I don't think that the ntpasswd function in smbencrypt.c is safe with JH> multi-byte character encodings, such as UTF-8. JH> I think that the problem is in the conversion of the password to JH> Unicode, for the construction of the NT hash. The function assumes a JH> single-byte character-set encoding (which works fine for Latin1, etc) JH> but not for multi-byte encodings such as UTF-8. JH> I'm not quite sure what the best approach to fix this is; does anyone JH> have any suggestions? JH> best regards, josh. JH> Josh Howlett, Networking Specialist, University of Bristol. JH> email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | JH> internal: 7850 JH> - JH> List info/subscribe/unsubscribe? See JH> http://www.freeradius.org/list/devel.html -- ~/ZARAZA Да, ему чертовски повезло. Эх и паршиво б ему пришлось если бы он выжил! (Твен)
On 25 Jul 2006, at 10:33, 3APA3A wrote:
Dear Josh Howlett,
ntpwdhash currently only supports ASCII (7-bit) passwords and this is documented. Common 8-bit implementation with character sets support is extreamaly hard because of different charsets support on different platforms. E.g. most *nix systems use KOI8-r encoding for Russian, while Microsoft uses Windows-1251 as ANSI and cp866 as OEM encoding. Most simple implementation is to insert translation table from 8-bit charset you are going to use to 16-bit little endian Unicode in ntpwdhash code itself.
Thanks 3APA3A, this confirms what I thought.
As for UTF-8 - yes, it's possible and it's easy to implement translation from UTF-8 to unicode within ntpwdhash,
Is iconv() the best approach?
but it's not clear how to store and mark UTF-8 attributes within FreeRADIUS.
Okay, but in the context of rlm_mschap only, we don't have to worry about this - right? best regards, josh.
--Tuesday, July 25, 2006, 12:51:16 PM, you wrote to freeradius- devel@lists.freeradius.org:
JH> I don't think that the ntpasswd function in smbencrypt.c is safe with JH> multi-byte character encodings, such as UTF-8.
JH> I think that the problem is in the conversion of the password to JH> Unicode, for the construction of the NT hash. The function assumes a JH> single-byte character-set encoding (which works fine for Latin1, etc) JH> but not for multi-byte encodings such as UTF-8.
JH> I'm not quite sure what the best approach to fix this is; does anyone JH> have any suggestions?
JH> best regards, josh.
JH> Josh Howlett, Networking Specialist, University of Bristol. JH> email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | JH> internal: 7850
JH> - JH> List info/subscribe/unsubscribe? See JH> http://www.freeradius.org/list/devel.html
-- ~/ZARAZA Да, ему чертовски повезло. Эх и паршиво б ему пришлось если бы он выжил! (Твен)
Josh Howlett, Networking Specialist, University of Bristol. email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | internal: 7850
Josh Howlett <josh.howlett@bristol.ac.uk> wrote:
As for UTF-8 - yes, it's possible and it's easy to implement translation from UTF-8 to unicode within ntpwdhash,
Is iconv() the best approach?
Probably.
but it's not clear how to store and mark UTF-8 attributes within FreeRADIUS.
Okay, but in the context of rlm_mschap only, we don't have to worry about this - right?
If the password is UTF-8, that has to be handled by rlm_mschap. For the rest, the server handles UTF-8 through the simple expedient of treating attributes like C strings. UTF-8 is backwards compatible with ASCII, so that works. i.e. I've successfully done authenticatin with a User-Name as chinese UTF-8 characters I pulled off of the net. I have no idea what they meant, but authentication worked, and the text in the terminal looked the same as from the web page with the chinese characters. Alan DeKok.
On 25 Jul 2006, at 11:28, Alan DeKok wrote:
but it's not clear how to store and mark UTF-8 attributes within FreeRADIUS.
Okay, but in the context of rlm_mschap only, we don't have to worry about this - right?
If the password is UTF-8, that has to be handled by rlm_mschap.
Do you think the simplest approach is to *always* iconv() the password from UTF-8 to Unicode in "ntpwdhash"? If the password is either ASCII or UTF-8 then it should work (because ASCII is a subset of UTF-8). (If it's some other multi-byte encoding it'll fail, but then it would fail anyway with the existing code.) best regards, josh. Josh Howlett, Networking Specialist, University of Bristol. email: josh.howlett@bristol.ac.uk | phone: +44 (0)7867 907076 | internal: 7850
participants (3)
-
3APA3A -
Alan DeKok -
Josh Howlett