From ge at linuxbox.org Wed Nov 11 12:54:22 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 11 Nov 2009 14:54:22 +0200 Subject: [psysec] OkCupid statistics on introduction messages success Message-ID: <4AFAB3FE.6080408@linuxbox.org> I am always impressed by the statistics gathering at OkCupid. They have a fascinating blog. Whether you are "in the market" or not, you will find this interesting. http://blog.okcupid.com/index.php/2009/09/14/online-dating-advice-exactly-what-to-say-in-a-first-message/ Thanks to Imri for sharing this with me. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From rMslade at shaw.ca Tue Nov 17 22:06:04 2009 From: rMslade at shaw.ca (Rob, grandpa of Ryan, Trevor, Devon & Hannah) Date: Tue, 17 Nov 2009 14:06:04 -0800 Subject: [psysec] REVIEW: "Security and Usability", Lorrie Faith Cranor/Simson Garfinkel Message-ID: <4B02ADCC.346.12EE467@localhost> BKSECUSA.RVW 20090727 "Security and Usability", Lorrie Faith Cranor/Simson Garfinkel, 2005, 0-596-00827-9, U$44.95/C$62.95 %E Lorrie Faith Cranor %E Simson Garfinkel %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2005 %G 0-596-00827-9 %I O'Reilly & Associates, Inc. %O U$44.95/C$62.95 800-998-9938 fax: 707-829-0104 nuts at ora.com %O http://www.amazon.com/exec/obidos/ASIN/0596008279/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596008279/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596008279/robsladesin03-20 %O Audience i- Tech 2 Writing 1 (see revfaq.htm for explanation) %P 714 p. %T "Security and Usability" The editors state that they intended this collection of essays more to address the academic, than the practical, side of the security field. Thus, the papers are chosen to reflect theory and principle, rather than specific practice. A prudent choice, since theory dates less quickly than specific procedure. The thirty-four compositions in this work are divided into six sections. Part one states that security and usability are not antithetical, part two addresses authentication mechanisms and techniques, part three examines how system software can contribute to security, part four deals with privacy controls, part five examines the vendor perspective of provision of security, while part six finishes off the book with a few papers considered to be of lasting value. The papers contain interesting points, but sometimes both theoretical and practical utility are lacking. For example the first paper, entitled "Psychological Acceptability Revisited," challenges the idea that security mechanisms must be complex and difficult to use in order to be effective. Unfortunately, while the author clearly demonstrates that a system can be both insecure and useless, he does not prove the opposite, which is the condition we want. A good many papers simply state that human factors should be considered, and that security provisions should be usable: these points are true, but not helpful. With one exception (a good paper on password choice) all the pieces on authentication present research having nothing to do with usability. Most of the papers in the book describe security research that is interesting, and which frequently has relations with human factors, but the relevance to the provision of systems that are both usable and secure is not often clear. Even as a compilation of security bedtime reading, the essays collected in this volume are somewhat lacking. In terms of both principles and practice, any volume of the "Information Security Management Handbook" (cf. BKINSCMH.RVW) has superior selection, and better structure, as well. copyright Robert M. Slade, 2009 BKSECUSA.RVW 20090727 ====================== (quote inserted randomly by Pegasus Mailer) rslade at vcn.bc.ca slade at victoria.tc.ca rslade at computercrime.org To iterate is human; to recurse, divine. victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html http://blogs.securiteam.com/index.php/archives/author/p1/ http://twitter.com/NoticeBored http://twitter.com/rslade From ge at linuxbox.org Wed Nov 25 01:27:51 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 25 Nov 2009 03:27:51 +0200 Subject: [psysec] WTF! Or, wow, this never happened to me before! Message-ID: <4B0C8817.6000200@linuxbox.org> I was invited to lecture today at a conference in the army. The lecture went great, we were having a lot of fun and I made sure both the subject and the way I presented it were interesting. The tension was peaking, people were sitting on the edge of their seats when suddenly.. BOOM! The door banged open: "Drill! Drill! Drill! Fire in the building! Everybody OUT!" And there was silence. We all literally went: "?!" People were deeply engaged with the subject, we connected, and they were almost hypnotized. This sudden interruption was like an exit() function, breaking out and killing the program unceremoniously. Hypnotists would call this a break pattern. This is what I wanted to share with the list, but if you are interested in the state-machine of what I think I could have done to "disable" the guy to a distant planet, take a look at my personal blog where I spend way too many words on this: http://gevron.livejournal.com/29557.html What would you have done? Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From rMslade at shaw.ca Wed Nov 25 02:28:34 2009 From: rMslade at shaw.ca (Rob, grandpa of Ryan, Trevor, Devon & Hannah) Date: Tue, 24 Nov 2009 18:28:34 -0800 Subject: [psysec] WTF! Or, wow, this never happened to me before! In-Reply-To: <4B0C8817.6000200@linuxbox.org> Message-ID: <4B0C25D2.20978.1E5C9F0@localhost> Date sent: Wed, 25 Nov 2009 03:27:51 +0200 From: Gadi Evron > What would you have done? a) I'm in favour of drills. b) I'm in favour of a policy of "no exceptions, do as if real" on drills. c) I'm in favour of (almost) no exceptions on policy. I would have left. But, yeah, it would have been an interesting experiment in social engineering to see if you could trip the machine. (I've had my lectures and seminars interrupted by fire drills and alarms numerous times. It makes for interesting examples in physical security. Such as the building where the fire alarm was almost inaudible in the training room, but literally headache-inducing in the exit stairwell. Or the buidling where we evacuated to a most unsafe area [fourth floor parking lot within the building], and then had to go back through a ridiculous security process, exacerbated by the fact that everything, including laptops that had been checked in in the morning, had been left in the training room. Took more than an hour to restart that course.) ====================== (quote inserted randomly by Pegasus Mailer) rslade at vcn.bc.ca slade at victoria.tc.ca rslade at computercrime.org If a professor tells you that computer science is x but not y, have compassion for his students. - Alan J. Perlis victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html http://blogs.securiteam.com/index.php/archives/author/p1/ http://twitter.com/NoticeBored http://twitter.com/rslade From marcin at kajtek.org Wed Nov 25 04:42:51 2009 From: marcin at kajtek.org (Marcin Antkiewicz) Date: Tue, 24 Nov 2009 22:42:51 -0600 Subject: [psysec] WTF! Or, wow, this never happened to me before! In-Reply-To: <4B0C25D2.20978.1E5C9F0@localhost> References: <4B0C8817.6000200@linuxbox.org> <4B0C25D2.20978.1E5C9F0@localhost> Message-ID: <7ed5f2120911242042p598a2508jd256a52b4ddccea3@mail.gmail.com> > I would have left. Agreed. I am sure that your lecture was very important to the group that has invited you, but from the safety perspective not interrupting lectures ensures a special case that's really hard to test. It's not how fast and auditorium can exit, but the impact of that mass of people on the crowd movement. I think your logic is related to the mindset that does not allow pentesting of critical components in production, 'because that might interrupt something." > But, yeah, it would have been an interesting experiment in social engineering to > see if you could trip the machine. That would be an unsolicited lesson for them :-) You should not be able to, or they need to retrain the wardens. -- Marcin Antkiewicz