Ben, I'm not sure why you think that brute forcing a password that is 14-15 characters long is so simple. Perhaps if the user includes their username, somewhere, it may be easier, but even with the example provided, if the user changes just a couple of characters, it's simply not feasible to crack. Even across a LAN.
Rainbow tables were supposed to solve password cracking issues, but even storing NTLM rainbow tables (which don't even include every possible hash, but merely some small fraction) for a 15 character password encompassing a-z, A-Z, 0-9 and !-) would take about two skyscrapers worth of 500GB disk drives according to a Security MVP I spoke to, after doing some rough back-of-the-envelope calculations. Jesper Johansson agreed with the calcs. Even if it's out by an order of magnitude, we're looking at several floors full of drives... 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. And the "yes", this needs to be included into the Windows SDK. Cheers Ken ________________________________________ From: Ben Scott [EMAIL PROTECTED] Sent: Monday, 24 December 2007 7:09 PM To: NT System Admin Issues Subject: Re: Audit recommendation On Dec 23, 2007 11:00 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote: >> Brute force attacks can be effective against even long passwords, > > Really? How long do you think it woudl take you to brute force a 15 > character, complex, password, over FTP? It all depends on how you define "long" and "complex". And I missed the part where this was over FTP. But yes, if you have a 20 character password consisting of an evenly-distributed random selection all possible characters one can type on a keyboard, and you're connected via remote Internet link, it will be very hard to brute force in reasonable time. Or even unreasonable time. But if you're on the LAN and the password is "jsmith02051982" or some other similar password that's very likely to be in actual use in the real world, then not so much. 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. > Total effort is more than writing a few lines of code (someone has to do the > documentation, it needs to work other APIs, > ISVs would need to be notified, SDKs/documentation would need to be updated, > regression tests and threat models > written and tested etc) I think you're being needlessly difficult here, so I'll respond in kind: Lack of documentation has never stopped Microsoft before. Working with other APIs is a no-op; this is a delay in the password validation routine, not something that communicates with other code. ISVs can presumably be notified via all the usual press release/newsletter. SDK is a no-op (ibid). Documentation you already mentioned. Threat models? All you need is something that repeatedly tries the same (incorrect) password. I can do that in a batch file. Regression testing is the one significant and legitimate objection in your list. Code/behavior changes can have surprising repercussions, and for something as commonly needed as password validation, there are a lot of places it could hit. Touche. But I maintain, compared to all the resources Microsoft puts into much less productive ends, this would be a justifiable and reasonable persuit. But I suppose Microsoft has better things to do, like writing the next version of Active Windows Desktop Search Live Ultimate Edition .NET Professional. Hurmph. -- Ben ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
