runas.exe not accept non-ascii passwords

[Plinio Conti]

Some user password have non standard ascii characters.

Initial Logon Dialog Box accepts them without problems.
No problems with GUI "Run As...", as well. (I mean when you start applications selecting RunAs.. from shift-Right-click menu)

But RUNAS from CMD command line fails.
What can I do?

The character are on my non-english keyboard, they are not so exothic.
They "appears" correctly when you type them in CMD command line.

 

[Drew Cooper [MSFT]]

"runas /savecred" might be a workaround.

If you would tell me the operating system, the language, and the character
that isn't working, I'll pass the information to the folks who work on
runas. I can't promise anything beyond that.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Some user password have non standard ascii characters.

Initial Logon Dialog Box accepts them without problems.
No problems with GUI "Run As...", as well. (I mean when you start

applications selecting RunAs.. from shift-Right-click menu)

 

[Gary Smith]

Some user password have non standard ascii characters.

Initial Logon Dialog Box accepts them without problems.
No problems with GUI "Run As...", as well. (I mean when you start applications selecting RunAs.. from shift-Right-click menu)

But RUNAS from CMD command line fails.
What can I do?

The character are on my non-english keyboard, they are not so exothic.
They "appears" correctly when you type them in CMD command line.

I'd guess that the problem is a mismatch between the console codepage and
the "ANSI" character set used by the GUI. Try this to test the theory:
Open notepad and type some text containing the non-ASCII characters. Sava
as a text file. Then open a command prompt windows and TYPE the file you
created. If the characters don't look right, we've discovered the source
of the problem.

 

[Plinio Conti]

OS: Windows 2000 Prof.
Language: Italian
Characters not working: basically the keys close to Enter in the Italian keyboard. For example (I hope you can read them correctly in the email): è,ò,à,ù, ì (accented vowels), ° (Celsius-grade symbol), etc..
Probably all the characters not in the basic-ascii table, i.e. characters with code > 127, but I didn't try all of them!

"/savecred" is not available on Win2000. Anycase is too insecure.

If some will do something to resolve this, how can I get notice about that?

Thank you.

--
Plinio Conti <pliniocontiATtiscaliDOTit>

"runas /savecred" might be a workaround.

If you would tell me the operating system, the language, and the character
that isn't working, I'll pass the information to the folks who work on
runas. I can't promise anything beyond that.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Some user password have non standard ascii characters.

Initial Logon Dialog Box accepts them without problems.
No problems with GUI "Run As...", as well. (I mean when you start

applications selecting RunAs.. from shift-Right-click menu)

 

[Plinio Conti]

I made your test.
Yes, the characters don't look right in TYPE output.

Default CMD codepage for my country (Italy) is 850 (International aka "Multilingual (Latin I)").
I switched to 437 (US) using command:
"CHCP 437"
but the TYPE output is bad, yet.

What Codepage is using Windows in GUI environment?
I didn't find such a setting in ControlPanel -> International.

What can I do, now?

 

[Plinio Conti]

I found Windows character set should be CodePage 1252.
I tryed at CMD prompt:
"CHCP 1252"

this is the result:
1) TYPE now correctly shows the text file produced by Notepad.
2) RUNAS still does NOT work.

Any idea?
Thank you.
--
Plinio Conti <pliniocontiATtiscaliDOTit>

P.S. (unnecessary notes):
a) "GUI" runas still work without problems.

b) I had to change the CMD window font to a TrueType font to see the characters of the new codepage,
as MS says at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/chcp.mspx
The same manual page says other things probably false or not exact:
- each country supports only 1 code page
- very few codepages (listed) are supported by windows (list not include 1252)

The linked manual page for COUNTRY command http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/country.mspx
says:
- each country supports 2 codepage. US and Italy, for example, support only 437 and 850.

I can say I can successfully switch to 850, 437, 1252, 863 (Canadian-French):
CHCP command renturns the correct "Active code page: xxx" message
and I can see the correct characters produced by TYPE.

 

[Gary Smith]

I found Windows character set should be CodePage 1252.
I tryed at CMD prompt:
"CHCP 1252"

this is the result:
1) TYPE now correctly shows the text file produced by Notepad.
2) RUNAS still does NOT work.

I believe that using CHCP in a console window affects the display but not
the entry of characters. You may be able to get around the problem by
entering the non-ASCII characters using the Alt-key technique. If you
need e with acute for example, use Alt+0233 -- or maybe Alt+233 -- The
zero is significant. The two forms behave differently. Unfortunately I
can't easily do any testing right now, and the interaction between the
Windows native encoding and codepages is complex.

If I were in that situation, I'd change the passwords so that they contain
only ASCII characters

 

[Plinio Conti]

I believe that using CHCP in a console window affects the display but not
the entry of characters. You may be able to get around the problem by
entering the non-ASCII characters using the Alt-key technique. If you
need e with acute for example, use Alt+0233 -- or maybe Alt+233 -- The
zero is significant. The two forms behave differently. Unfortunately I
can't easily do any testing right now, and the interaction between the
Windows native encoding and codepages is complex.

I already tried that. It doesn.t work.
I wonder there is not a way... is there something strange in RUNAS.EXE itself ?

If I were in that situation, I'd change the passwords so that they contain
only ASCII characters

Of course that is a definitive solution.
But there are few valid reasons to use them:
- some are quite natural in languages like italian.
- they are usually not tried by brute-force attacks
- if they are considered by brute-force they impose
a slower search. If I could include one single
unicode character (in a random position) in a 14 chars password it
would be very difficult to "brute-force" it. In facts brute-force attacks usually
search for about 70-90 characters not 65,000.

 

[Drew Cooper [MSFT]]

I let the testers who own runas know about the problem and gave them a link
to this newsgroup thread. I don't really know how you could register for
notice for this issue even if there were a fix, though.

If the problem is actually runas and not cmd.exe, you might be able to use a
different tool like psexec from sysinternals. For that matter, even if the
problem is in cmd you should be able to start->run and type the full command
line for psexec. That might be the easiest workaround for now.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


OS: Windows 2000 Prof.
Language: Italian
Characters not working: basically the keys close to Enter in the Italian
keyboard. For example (I hope you can read them correctly in the email):
è,ò,à,ù, ì (accented vowels), ° (Celsius-grade symbol), etc..
Probably all the characters not in the basic-ascii table, i.e. characters
with code > 127, but I didn't try all of them!

"/savecred" is not available on Win2000. Anycase is too insecure.

If some will do something to resolve this, how can I get notice about that?

Thank you.

--
Plinio Conti <pliniocontiATtiscaliDOTit>

"runas /savecred" might be a workaround.

If you would tell me the operating system, the language, and the character
that isn't working, I'll pass the information to the folks who work on
runas. I can't promise anything beyond that.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Some user password have non standard ascii characters.

Initial Logon Dialog Box accepts them without problems.
No problems with GUI "Run As...", as well. (I mean when you start

applications selecting RunAs.. from shift-Right-click menu)

 

[Gary Smith]

Of course that is a definitive solution.
But there are few valid reasons to use them:
- some are quite natural in languages like italian.
- they are usually not tried by brute-force attacks
- if they are considered by brute-force they impose
a slower search. If I could include one single
unicode character (in a random position) in a 14 chars password it
would be very difficult to "brute-force" it. In facts brute-force attacks usually
search for about 70-90 characters not 65,000.

Certainly, but as always, there's a trade-off between security and
usability. If I were faced with the problem you have, I'd get rid of the
non-ASCII characters and make the passwords longer. So far as I know, you
can'y use Unicode in a console application interface, so you're still
limited to a maximum of 256 possible characters.

If you spend some time experimenting with various alt-number combinations,
you may be able to figure out how to enter the characters you need.
There isn't guaranteed to be a solution, though. It depends on how RunAs
is implemented.

I wonder if you can use control characters in passwords...

 

[Plinio Conti]

Certainly, but as always, there's a trade-off between security and
usability. If I were faced with the problem you have, I'd get rid of the
non-ASCII characters and make the passwords longer. So far as I know, you
can'y use Unicode in a console application interface, so you're still
limited to a maximum of 256 possible characters.

I agree.
Thank you. Best regards.