On Dec 24, 2007 6:45 AM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> I'm not sure why you think that brute forcing a password that is 14-15
> characters long is so simple.
A dumb brute force attack -- one that just tries every possible
character in sequence -- is very simple, just also very slow to run.
A "smart" brute force attack is not simple to implement, but can guess
the sort of weak passwords most people use much quicker. And you're
the one who keeps imposing the 15 character length. If we instead
assume a typical user password -- say, made up of common names and
dates -- we reduce the keyspace dramatically.
> ... even with the example provided, if the user changes just a couple of
> characters ...
And what if they *don't*? That is is my point. From what I've
seen, users will almost always pick the simplest, stupidest possible
password that will pass any complexity requirement in place. And they
use fairly predictable patterns, too. It's been commonly observed
that "Passw0rd!" will be accepted as a very strong password by most
complexity filters. (Longer than eight characters, mixed case,
contains a digit and a non-alphanumeric character, doesn't match any
of the words in my English word list. Must be a fantastic password!)
I'll post this again, since I can already hear the reply coming:
Yes, one can -- and, indeed, should -- decry weak passwords as a big
practical security problem. That doesn't mean the situation isn't
realistic. It also doesn't mean countermeasures against
brute/dictionary attacks should be abandoned.
> Yes - ISVs need to be notified. They may write custom GINAs, or custom
> passfilt.dll files, or hook ksecdd.sys, or inject
> into lsass.exe or all sorts of things. You can't assume that they won't.
To the best of my knowledge, for SAM/AD passwords, GINA is used as a
UI to accept password input from a user. That code path should have
nothing to do with the internal routine which actually validates the
password to see if matches the hash stored in SAM/AD. If a
third-party is using their own password system, protecting that is up
to them. That is nothing new.
To the best of my knowledge, PASSFILT.DLL is used to enforce
password complexity, not validate existing passwords. It shouldn't
even be in the code path we're discussing.
I don't know anything about hooking the kernel security driver or
injecting into the LSA, but given the non-applicability of your first
two objections, I'm not willing to accept on blind faith that they
would be any different. Some quick Google work finds very little
information on them. What little I find suggests they would be the
sort of things normally considered by Microsoft to be unsupported,
undocumented, use-at-you-own-risk anyway.
> And the "yes", this needs to be included into the Windows SDK.
I'm sorry, I didn't realize you had become the Product Manager for
the Windows SDK. Good to know you've decided to institute a strict
policy of documenting everything in Windows so well. That's always
been one my biggest criticisms of Windows.
-- Ben
~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
