Keyboards as security blankets
by Michael S. Kaplan, published on 2005/10/23 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/23/483911.aspx
Dr. International recently posted about using alternate keyboard characters as a method of enhancing security. I am of two minds on this issue.
On the one hand, any method you use that makes it harder for password checkers is potentially interesting, and the trick that Dr. International talks about seems to do just that.
On the other hand, I look at white papers like Selecting Secure Passwords that talk about many characters that this trick apparently will not work for (the characters get mapped to easy letters that would make for less secure pasword choices -- the white paper warns that you could end up with something much less secure).
Clearly the ALT+Numpad text handler is doing much more than meets the eye here. I'd have to suggest avoiding it, at least until some more clarity happens on what really takes place in the login dialog situation.
The table in that white paper certainly brought me up short....
This post brought to you by "û" (U+00fb, a.k.a. LATIN SMALL LETTER U WITH CIRCUMFLEX)
Accessible via <ALT>+0251, though apparently mapped to an uppercase U if that white paper knows what it is talking about)
# Maurits [MSFT] on 23 Oct 2005 6:53 AM:
Odd. The first table has a "..." after "a, b, c"... implying that there are more than three letters. But the Unicode entry has four entries, with no "...", implying that there are exactly four Unicode characters. :)
It's good to see that a good word is put in for including characters from multiple character classes. Certainly dictionary words are weak passwords, and forcing multiple character classes takes care of the dictionary problem.
But...
l33t isn't all that strong a way to force inclusion.
If a hacker is willing to crack using a dictionary, it doesn't seem all that hard to modify the dictionary algorithm to:
1) Try all the words in the dictionary
2) Try all the words in the dictionary, making one l33t-substitution
3) Try all the words in the dictionary, making two l33t-substitutions
4) ...
And it shouldn't take more than a couple of thousand times as long to crack the average l33t-substituted password using this algorithm.
# Michael S. Kaplan on 23 Oct 2005 11:37 AM:
Yes, there are many reasons to find that white paper disturbing, the ones you note being just a few of them....
# Dean Harding on 24 Oct 2005 12:27 AM:
I believe it only converts those characters for the LM hash. The full NTLM hash should use the characters, unmodified. I might be wrong though... Also, you can disable LM hashing, but only if you don't have any Windows 9X or Mac clients on your network. See:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&
I would tend to agree, though, that using extended characters for passwords is probably not that good an idea. Even for the "sensitive" accounts - in fact, *especially* for sensitive account. The thing is, you're not often going to log in as domain admin, so you need to use a password that you're going to remember. It would be much better to have a nice long pass phrase that you can actually remember than some shorter "strong" password that you have to write down to remember.
# Michael S. Kaplan on 24 Oct 2005 10:02 AM:
Hi Dean --
The white paper seems to suggest otherwise. Like I said, there is lots in there that confuses and bothers me.
Please consider a
donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
go to newer or older post, or back to index or month or day