This has been making the rounds as of late, so I am not sure if it has been posted here: Security Myths and Passwords by Prof. Spafford and something from 2002: Ten Windows Password Myths Now...where I am, Smart Card integration into physical building access is becoming a reality, so I'm really interested to see how this pans out.
> Date: Sun, 30 Apr 2006 12:33:45 -0400> From: [EMAIL PROTECTED]> To: > [email protected]> Subject: Re: [ActiveDir] How Secure is a Domain > Controller?> > The answer to that last isn't terribly difficult. Just ask > yourself> what is it that every administrator has to take to work every day?> > Likely, it's an id badge/card key. Very few companies issue keys any> longer > because it's too expensive to maintain and too difficult to> change as > employees leave or you move buildings. But administrators> often need > all-hours access so what to do? Go to card key access.> > So it would be a > far stretch to issue administrators (possibly only> administrators?) card > keys that are also smart cards.> > You may be wondering if it's better than a > Securid? Depends, but> chances are good you'll need to have something added > to the servers> regardless of the method whether it's a piece of software or > usb key> reader, or... ?> > Anyhow, there are ways to do that for > administrators, but you do have> to figure out what comes to work with the > admin . Nobody gets in the> door without a card key in many places I've seen. If you let just> anybody in the door regardless of identification or physical device> (key) then what's the point of locking the applications again?> > I don't think I've yet bought into the longnastypasswords yet. In> theory and concept it seems great. But I've seen mixed results and> I've seen some of the same issues that users have when it comes to> complex passwords - they find convenience in subversion. Is that> right? No, but you'll have to take the 8th layer into account if> you're going to come up with a good solution to this problem. Some> more definition of the problem is helpful as well.> > Al> > P.S. Can you read this one, joe? :)> > On 4/28/06, joe <[EMAIL PROTECTED]> wrote:> > This is old, I sort of apologize. This is a topic some of us have debated in> > circles over on the MVP / MS Private Security List Server multiple times as> > well. It is always fun because the opinions are all over. I have some> > thoughts for it.> >> > 1. A passphr ase is just like a password only you have bigger "chunks" or> > password building blocks, as soon as this becomes common practice or is> > forced across an entire environment the cracking tools just need to work> > towards adopting this mechanism as well, instead of looping through letters,> > you loop through words. This is done to a limited extent now but it could be> > done much more efficiently, especially if the domain policy says you need 20> > characters or something. \> >> > 2. You don't set 90 day password expiration to only prevent brute force> > attacks. You use it to lessen how far out a password reaches. People are> > horrible with secrets, how many of you as support techs have walked up to a> > desk and said, yeah what is your password and then gotten it? Or maybe> > looked at the sticky notes on the monitor, or if the person was really> > secure look in the bottom drawer. Now, assume you aren't the only person> > smart enough to ask for that password or look. So now the password is out> > there... How long do you wan t it to be valid for before knocking it down?> > For normal users I don't like policies less than 91 days (user exercise to> > figure out why 91 instead of 90 days , I have mentioned it before), it is> > just plain annoying and a 30 or 60 day normal user policy is almost> > guaranteeing some sort of pattern or written down password.> >> > Now for admin accounts password changes every 30 days I don't have much> > trouble with. With service/application IDs I don't have a problem with> > password changes every day. It can be implemented, I have done it. It just> > isn't easy nor the default. Certainly I cringe whenever I hear about someone> > who has a very important very powerful service ID and are asking how to make> > it non-expiring... Just kills me. There was one critical application> > (Corporate Web Portal) whose password I accidently saw when doing a trace on> > a domain controller looking at LDAP packets (LDAP simple bind in the clear)> > and it was a very memorable password, it was the name of an enemy of> > Superman; the on e who didn't have any vowels in his name. I immediately> > approached the app owners to say bad bad bad from many angles. They said> > thanks. I was fired from that position... Then I got rehired 6 months later,> > did another network trace and guess what ID and password I saw again... Why> > didn't they change the password? Because the app made it difficult. That is> > not a good reason.> >> >> > The reference to the -500 accounts is accurate. Very long nasty passwords> > that got locked into envelopes. Never used those accounts in the 5 or so> > years I might have needed a reason. Why not worry about changing them? There> > wasn't a soul that could remember them and no one used the accounts so we> > simply monitored authentications (good and bad) and password changes for the> > account. Any hit on any of them meant something to look into though bad hits> > were pretty common.> >> >> > Thoughts on 2-factor? The second factor (not the one you know but the one> > you have) needs to be something people can't forget to bring to work w ith> > them because companies care more about people working than security, I used> > to run into that all of the time and we only required SecurID FOBS for> > password resets of delegated "admin" IDs. Personally I wanted to say that> > anyone who asked to have an "admin" ID reset that had forgotten their FOB> > and they were willing to admit that A) they forgot their admin password and> > B)forgot their FOB were fired on the spot. Something like the Austin Powers> > push button and their chair flips over and flames shoot up from the hole> > they fall through. Do you really want people like that managing stuff for> > other people?> >> > Anyway... until we start embedding RFIDs in our skulls I don't know how we> > will handle that except for biometrics but folks out there seem to be having> > fun breaking those systems and showing them to be unsafe. I don't have a> > problem with embedding an RFID with my personal info as long as I have a way> > to turn it off or otherwise control what it outputs. I would want it to> > output PISS O FF until I actually wanted something and then I could tell it> > what info I wanted it to kick out.> >> > joe> >> > --> > O'Reilly Active Directory Third Edition -> > http://www.joeware.net/win/ad3e.htm> >> >> > -----Original Message-----> > From: [EMAIL PROTECTED]> > [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA> > aka Ebitz - SBS Rocks [MVP]> > Sent: Monday, April 03, 2006 10:06 PM> > To: [email protected]> > Subject: Re: [ActiveDir] How Secure is a Domain Controller?> >> > Sorry one more thing.. in a Center for Internet Security project to set> > Baseline Operational Security Standards for protecting sensititive data> > (both PII and business confidential)... they are actually leaning strongly> > towards recommending two factor authentication and not just passwords and a> > protection factor.> >> > When LC5 was still around (before Symantec killed it) cracking 7 or less> > character passwords on a network with lanmanhashes enabled ... those got> > broken pretty quickly. 14 characters breaks the lanmanhash setting.> > Ergo the recommendaton for long passphases for admin accounts (and Joe has> > stated that they lock up the 500 accounts and make those pass phrases even> > longer than that)> >> > Someone stated today that maybe we need to consider a password policy that> > does not require a change out of every 90 days as that does tend to make the> > person weaken a password or reuse something.> >> > If instead they used a long and nasty passphrase and only changed it once a> > year.. would that actually be less risk than one changed more often?> >> > Food for thought.> >> > Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:> >> > > The Magical Number Seven:> > > http://www.well.com/user/smalin/miller.html> > >> > > Protecting your Windows Network, Dr. Jesper Johansson and Steve Riley> > > site that study regarding the ability of humans to process> > > information. (Good book btw..entertaining security book)> > >> > >> > >> > >> > > Amazon.com: Protect Your Windows Network : From Perimeter to D ata> > > (Microsoft Technology): Books: Jesper M. Johansson,Steve Riley:> > > http://www.amazon.com/gp/product/0321336437/sr=8-1/qid=1144114723/ref=> > > pd_bbs_1/103-7946857-8851835?%5Fencoding=UTF8> > >> > >> > >> > >> > > Al Mulnick wrote:> > >> > >> I'd be very interested to see the technical data that backs that up> > >> (not you Neil, but the folks from Microsoft that make that claim.)> > >>> > >> Is it related to people being able to remember a limited number of> > >> numbers> > >> perhaps?(http://www.youramazingbrain.org.uk/yourmemory/digitspan.htm> > >> ) Or is there some other empirical data that says that passwords with> > >> greater than 7 characters is likely to be repeated?> > >>> > >> Or could it be that somebody at MS is sore that NTLM had to be> > >> upgraded to beyond two 7 char strings? ;)> > >>> > >> Seriously, I see nothing like that here> > >> http://www.indevis.de/dokumente/gartner_passwords_breakpoint.pdf or> > >> here http://www.passwordresearch.com/stats/statindex.html> > >>> > >> I think that's a load of bologna to make a suggestion to keep> > >> passwords to less than 7 characters. If anything, there's no reason> > >> not to make them longer as the more characters that have to be> > >> guessed, the harder it becomes to brute-force hack them (assuming> > >> that passwords are not stored as two 7 char strings, right?) That> > >> allows the system to be even more useful because you can then extend> > >> the attempts prior to lockout making the system more useful to the> > >> end user.> > >> In the end, there are some assertions that passwords by themselves> > >> are coming to the end of their useful life. Hmm.. Maybe. But I think> > >> coupled with good lockout policies, strong passwords mean we can> > >> mitigate the risks for most situations. Not forever of course> > >>> > >> I'd love to see some of that data that shows that users repeat after> > >> 7 characters if anyone has it.> > >> Al> > >>> > >>> > >>> > >> Just for fun:> > >> http://plus.maths.org/issue31/features/eastaway/index-gifd.html> > >>> > >> On 3/6/06, *neil.rusto [EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]>* <[EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]> > wrote:> > >>> > >> The use of >20 char passwords caught my eye.> > >> In previous discussions with MS et al, it was suggested that> > >> the> > >> majority of users would simply repeat a (at most ( 7 char password> > >> n times, so as to meet the 20+ char pw policy requirement.> > >> As a result, I have heard it suggested that in reality (not> > >> theory) a pw policy of more than 7 chars is actually counter> > >> productive. [Any pw policy with a multiple of 7 chars being most> > >> counter productive.]> > >> Food for thought,> > >> neil> > >>> > >>> > >> ------------------------------------------------------------------------> > >> *From:* [EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]> [mailto:> > >> [EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]>] *On Behalf O f *Ulf B.> > >> Simon-Weidner> > >> *Sent:* 05 March 2006 08:35> > >>> > >> *To:* [email protected]> > >> <mailto:[email protected]>> > >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller?> > >>> > >> I've written down some related thoughts once:> > >>> > >> http://msmvps.com/blogs/ulfbsimonweidner/archive/2004/10/24/16568.asp> > >> x> > >>> > >> Gruesse - Sincerely,> > >>> > >> Ulf B. Simon-Weidner> > >>> > >> MVP-Book "Windows XP - Die Expertentipps":> > >> http://tinyurl.com/44zcz> > >> Weblog: http://msmvps.org/UlfBSimonWeidner> > >> <http://msmvps.org/UlfBSimonWeidner>> > >> Website: _http://www.windowsserverfaq.org_> > >> <http://www.windowsserverfaq.org/>> > >> Profile:> > >>> > http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811> > D> > >>> > >>> > >>> > >> ------------------------------------------------------------------------> > >> *From:* [EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]> [mailto:> > >> [EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED]>] *On Behalf Of> > >> *Edwin> > >> *Sent:* Sunday, March 05, 2006 4:17 AM> > >> *To:* [email protected]> > >> <mailto:[email protected]>> > >> *Subject:* [ActiveDir] How Secure is a Domain Controller?> > >>> > >>> > >> How Secure is a Domain Controller that is fully patched on a> > >> default install of Windows 2003? When promoted the domain> > >> controller has the two default policies, both of which are> > >> recommended not to be modified. But there are things that could> > >> be done better for added security. For example, NTLMv2 refuse> > >> NTLM and LM. Is it common practice to add additional GPO's to the> > >> DC OU? Or is DC protected enough to where all that is needed to> > >> worry about are the member machines?> > >>> > >>> > >> If adding additional GPO's to the DC OU, i s there anything that> > >> should definitely be avoided?> > >>> > >>> > >> Edwin> > >>> > >> PLEASE READ: The information contained in this email is> > >> confidential and> > >> intended for the named recipient(s) only. If you are not an intended> > >> recipient of this email please notify the sender immediately and> > >> delete your> > >> copy from your system. You must not copy, distribute or take any> > >> further> > >> action in reliance on it. Email is not a secure method of> > >> communication and> > >> Nomura International plc ('NIplc') will not, to the extent> > >> permitted by law,> > >> accept responsibility or liability for (a) the accuracy or> > >> completeness of,> > >> or (b) the presence of any virus, worm or similar malicious or> > >> disabling> > >> code in, this message or any attachment(s) to it. If verification> > >> of this> > >> email is sought then please request a hard copy. Unless otherwise> > >> stated> > >> this email : (1) is not, and should not be treated or relied upon as,> > >> investment research; (2) contains views or opinions that are> > >> solely those of> > >> the author and do not necessarily represent those of NIplc; (3) is> > >> intended> > >> for informational purposes only and is not a recommendation,> > >> solicitation or> > >> offer to buy or sell securities or related financial instruments.> > >> NIplc> > >> does not provide investment services to private customers.> > >> Authorised and> > >> regulated by the Financial Services Authority. Registered in England> > >> no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St> > >> Martin's-le-Grand,> > >> London, EC1A 4NP. A member of the Nomura group of companies.> > >>> > >>> > >> >> > --> > Letting your vendors set your risk analysis these days?> > http://www.threatcode.com> >> > List info : http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.c om/activedir%40mail.activedir.org/> >> > List info : http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/> >> ا~m List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
