Re: [fw-wiz] Stanford break in
From: Chuck Vose (vosechu_at_roman-fleuve.com)
Date: 04/22/04
- Previous message: Chuck Vose: "Re: [fw-wiz] Kinko's Waning Security"
- In reply to: Carric Dooley: "Re: [fw-wiz] Stanford break in"
- Next in thread: Adam Shostack: "Re: [fw-wiz] Stanford break in"
- Reply: Adam Shostack: "Re: [fw-wiz] Stanford break in"
- Reply: Carric Dooley: "Re: [fw-wiz] Stanford break in"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Carric Dooley <carric@com2usa.com> Date: Thu, 22 Apr 2004 10:47:10 -0700
> Decide on password guidelines like alpha-numeric, mixed case,
> and one special character, and leave it to a dll like passfilt.dll or
> something similar. Yellow stickies just comes down to end-user education,
> and a good password policy. If the requirements are: "14 random
> alpha-numeric chars, with 5 special chars and mixed case.. OH, and change
> it weekly" you will most likely have a sticky note problem.. if it's: "7
> chars, alpha-numeric, one special char and mixed case changing every 42
> days
Thank you, this was part was especially enlightening. I wonder, I've
read about password generation programs that are supposed to make this
process less painful. In addition to following the guidelines of 7:1:1
passwords they put in a clever key like ilfb67v = i like fuzzy bunnies,
your birthyear, first letter of last name. Or, as that adds guessable
info which takes the password down to 4 characters in reality, just
something like the I like fuzzy bunnies (only 7 characters long with a
number and a special character.)
Anyone had any experience with this sort of thing?
Also, are salts a good idea to change the hash in the shadow file?
For instance, change passwd or yppasswd so that entering ilfb76v is
equivalent to entering /ilfb76v*. Adding in special characters that
change the hash and make it harder for brute force to check. Does it
matter? What are the chances that a hacker would check yppasswd for
modifications?
> AD, LDAP, NDS all give you the ability to control access through context.
> In other words, if the tree is well designed, a user cannot access all
> servers on the network. Access to "a workstation" would be somewhat
> useless in a client server network...
Yeah, I forget once again what the real world is like. I think about
unauthorized access and think about my documents on my harddrive
disappearing, but in the real world nothing goes directly onto harddrive
when you've got something like NAS or SAN, and if you have 300,000 you
have SAN.
> users need to be able to get to
> servers, but only those required to do their jobs, which is pretty much
> the underlying principal to data confidentiality in the CIA
> (confidentiality, integrity, availability) data security model.
As my teacher friend explained this, he uses access like objects inherit
in programming. There's the base access which included things like a
small home directory on a shared server and a roaming desktop with the
ability to log in on the public computers. However if you're in a
specific group you get access to the specific computers in that area,
and the servers that pertain. (I say this more for my benefit and the
archive's benefit)
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Previous message: Chuck Vose: "Re: [fw-wiz] Kinko's Waning Security"
- In reply to: Carric Dooley: "Re: [fw-wiz] Stanford break in"
- Next in thread: Adam Shostack: "Re: [fw-wiz] Stanford break in"
- Reply: Adam Shostack: "Re: [fw-wiz] Stanford break in"
- Reply: Carric Dooley: "Re: [fw-wiz] Stanford break in"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|