tag:blogger.com,1999:blog-89760890950470075432024-02-20T14:35:25.246-05:00Off-the-Wall SecurityAnswers: $10 Answers correct: $100 Answers requiring thought: $1000
<br>
Dumb looks are still free!Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-8976089095047007543.post-23447750788579539282023-10-28T19:21:00.000-04:002023-10-28T19:21:02.399-04:00Threat Modeling for Software Development Kits (SDKs)<p>I generally don't ask for help in my blog, but writing up my questions here is the easiest way to share via social networks. <br /></p><p>I was wondering if
anyone could point me at an example or 2 off a formal threat model
that was done on some Software Development Kit (SDK), that is a
software library. Not a web service API, where the attack surface is
more obvious, but a traditional library.
</p>
<p style="line-height: 100%; margin-bottom: 0in;">I would like to do
one for <a href="https://owasp.org/www-project-enterprise-security-api/">OWASP
ESAPI</a>. The closest I’ve gotten to this in the past was this
document I wrote in 2010: <a href="https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-core-2.0-crypto-design-goals.doc">OWASP
ESAPI for JavaEE 2.0: Design Goals in OWASP ESAPI Cryptography</a>,
which had at its roots lessons learned from a proprietary
cryptographic key service that I lead my AppSec team to design for a
former employer and for which I did a formal design goal, but only a
minor part of that was an SDK.</p>
<p style="line-height: 100%; margin-bottom: 0in;">A major reason why
I’ve been thinking about it recently is because just last week, I
published a new ESAPI Security Bulletin and an accompanying <a href="https://github.com/ESAPI/esapi-java-legacy/security/advisories/GHSA-7c2q-5qmr-v76q">GitHub
Security Advisory</a> that had to do with File Uploads and in it, I
tried to explain why ESAPI couldn’t do more. In that simplified
explanation I tried (and most likely largely failed) to convey some
of the major DoS related threats associated that we couldn’t
account for unless ESAPI were to enforce particular use cases on
developers. And therein lies the problem. I thought, it I had threat
model to hold up and share with developers around various file upload
use cases, I would have had a shot. But when you have a general
purpose library that tries not to impose any specific use case, how
do you go about describing a threat model for that? Even drawing a
DFD for that is problematic as it likely would only be one of several
possible ones. (E.g., for file uploads, authenticated vs anonymous
file uploads are 2 very different use cases that in my opinion would
have 2 very different threat models.)</p>
<p style="line-height: 100%; margin-bottom: 0in;">I think it is
obvious from a library of several general security controls like
ESAPI which tries to provide controls that can be used to address
most of the OWASP Top Ten, that one would first have to start by
decomposing it into basic components such as authentication,
authorization, data validation, output encoding, safe logging,
cryptography, etc. and likely have to address it as a collection of
several separate, much smaller threat models. Otherwise, you would
never be able to deal with all the different abstractions in a
context level DFD that would be simple enough and concrete enough for
it to be comprehensible to anyone, much less developers. Part of the
problem in fact is that several of the components (e.g., data
validation, output encoders, safe logging to name just three) already
deal only with “strings” as input and output and it is extremely
difficult to relate a general string to usual concrete asset.</p>
<p style="line-height: 100%; margin-bottom: 0in;">An example of this
is ESAPI’s <a href="https://javadoc.io/static/org.owasp.esapi/esapi/2.5.2.0/org/owasp/esapi/Logger.html">Logger</a>
component which attempts to provide “safe logging”, where “safe
logging” in meant to 1) prevent “<a href="https://vulncat.fortify.com/en/weakness?q=log%20forgery">Log
Forging</a>” (aka, “Log Injection”), that is <a href="https://cwe.mitre.org/data/definitions/117.html">CWE-117</a>
as well as 2) provide some level of basic attention against XSS
attack strings inserted into logs that may be viewed in via HTML
browser. However, one thing that ESAPI’s Logger and its concept of
“safe logging” does not address at all is to prevent sensitive /
confidential information ending up in log files. Given that the
tainted input to the methods are general Java Strings, it is not
possible to look at those in the context free manner that ESAPI sees
them to know if it is in fact sensitive data that should not be
placed into a log. That potentially could be don’t with a slightly
different interface or customization by application developers, but
seems a stretch for a general purpose security library.</p>
<p style="line-height: 100%; margin-bottom: 0in;">However, I think
that a well-developed overall ESAPI threat model would help the ESAPI
team communicate to developers to let the know them where the
security guardrails are that ESAPI is able to handle and where they
are on their own. I have communicated with many application
developers using ESAPI who seem to struggle with these basic
concepts. Sometimes it is because our Javadoc is sorely lacking or we
have little design documents. (I think we only have 2. One for the
ESAPI cryptography that I mentioned earlier and a much more basic one
that is a half-page covering the Logger that was originally just an
email between ESAPI team members.) Similarly, we only have 1 high
level user guide for any of the components (for the symmetric
cryptography introduced in ESAPI 2.0). I think developers can learn a
lot by reading through well-constructed threat models.</p>
<p style="line-height: 100%; margin-bottom: 0in;">But that brings me
to main question. How does one construct a threat model for a general
library? What does a good one look like and how would one for a
library (which may have no <i>specific</i> use cases in mind)
different from threat models from applications or overall specific
systems.</p>
<p style="line-height: 100%; margin-bottom: 0in;">And my second
question (assuming someone can answer the main questions above), is
would anyone be willing to assist me in developing a threat model for
OWASP ESAPI?</p>
<p><style type="text/css">p { line-height: 115%; margin-bottom: 0.1in; background: transparent }a:link { color: #000080; text-decoration: underline }</style></p>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-11421968745548682622023-02-16T00:36:00.001-05:002023-02-17T08:29:07.639-05:00<p>
</p><h1 style="line-height: 100%; margin-bottom: 0in; text-align: left;">Why I don’t Myth
the Old Days (or there’s no accounting for bug fix costs)</h1>
<p style="line-height: 100%; margin-bottom: 0in;"><br />
</p>
<p style="line-height: 100%; margin-bottom: 0in;">This is a commentary
on a portion of Mark Curphey’s blog post “<a href="https://blog.crashoverride.com/on-the-left-on-the-right-and-wiggle-in-the-middle">On
the left, on the right, and wiggle in the middle</a>”.</p>
<p style="line-height: 100%; margin-bottom: 0in;">It’s not that I
disagree with Curphey’s overall message that “shift-left is a
dangerous urban myth”, but I think perhaps both he and Lauren
Bossavit, from whom he quotes from Bossavit’s <a href="https://gist.github.com/Morendil/258a523726f187334168f11fc8331569">Gist
post</a> might not be considering the proper context of the presumed
myth “<span style="font-size: small;">it's 100x cheaper to
fix bugs in development than it is in production”. </span>Specifically,
I think the citation that Pressman used in his 1981 book was for a
completely different era of software development and I think that
makes a significant difference that is not being accounted for and
ever since then—because it benefits ROI marketing hype for certain companies--it’s been constantly pulled out of context and taken on
a life of it’s own.I</p>
<p style="line-height: 100%; margin-bottom: 0in;">However, in a
nutshell, when Pressman originally wrote it—for the worst case
scenarios at least—it probably was close to being in the right
ballpark. That doesn’t excuse companies from still repeating it
(whom Mark rightfully calls out) but I don’t doubt those figures
were close to being correct back in 1981. So I think there’s a
bigger picture that is being missed here.</p>
<p style="line-height: 100%; margin-bottom: 0in;">Let me explain. And
for those of you who have not as old as dirt, as am I, let me give you
some history.</p>
<p style="line-height: 100%; margin-bottom: 0in;">In the early 1980s,
the hardware was archaic by today’s standard and the waterfall
methodology for software development was the only game in town. If
you were lucky, you got to work on a machine that had 16-bit
addressing and either Version 7 or PWB Unix. At (then AT&T) Bell
Labs at the time, it was not uncommon for 20+ developers to share a
Unix system on a DEC PDP-11/70 (or worse) and connect to it at 9600
baud using DEC VT-100 terminals. Programming was generally done in C
or assembly language (or often a mixture) using the ‘ed’ text
editor. Compiling the Unix kernel from scratch would take 3 or 4
hours in single-user mode, but much longer on fully loaded system.
The only debugger at the time was ‘adb’ and it only displayed the
code in the native PDP-11 assembly language. But most importantly
perhaps was that all software was distributed by <a href="https://en.wikipedia.org/wiki/9-track_tape">9-track
tape</a>.</p>
<p style="line-height: 100%; margin-bottom: 0in;">If you put all those
things together, it’s not hard to see how the cost of catching a
bug in early in the development process could easily be a factor of
10 or more than catching it and fixing post release.</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">The
first project I was on at Bell Labs was called AMARC. (I think AMARC
was an acronym for “Automated Messaging and Accounting Center”.)
Like most other projects at the at Bell Labs, AMARC was on a two-year
release cycle. When we did a regular AMARC release, the would be
written on 9-track tapes and delivered, often by special courier, to
most of Baby Bell (officially known as Regional Bell Operating
Company (RBOC)) central offices. (AMARC collected long distance
billing information and charging for long distance at that time was
one of the primary ways that AT&T funded Bell Labs R&D.)</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">But
occasionally, when a bug surfaced, it was serious enough that AMARC
had to ship emergency patches. I remember one such patch. AMARC was a
proprietary custom duplex real-time operating system (this was before
DMERT for those of you old enough to remember that) that ran on dual
PDP-11/70s. The was a bug that was causing AMARC to crash and when
its paired mate rebooted the crashed processor, it got stuck in an
infinite cycle of reboots: when the initially rebooted mate came back
up, it caused the other one to crash and then it would reboot. So
there was this wicked cycle of endless reboots until each were shut
down. But the bigger problem is that AMARC recorded (of to 2 hours
worth) of its billing data on 9-track tapes. When the machine would
crash, that tape would get trashed. So that required an emergency
patch. (If I recall correctly, the Bell System called those emergency
patches Broadcast Warning Messages or BWMs for short. Whatever the
actual term was, I will henceforth refer to them as BWMs in this
post.)</p><p align="left" style="line-height: 100%; margin-bottom: 0in;">The BWMs were often generated using ‘adb’ in write mode
(-w) to allow for patching binaries. Back in the day, AMARC would
allocate patch space by writing large sections of NOP instructions
which would latter be filled in with the actual fix and then a jump
instruction would jump to the proper spot. So even if the bug was in
some C code (which it often was) the patch would be in assembly code
and then adb would be used to patch the actual AMARC baseline binary
(all the patches were done in octal by the way!) to create a new
point release of AMARC that became part of the BWM package.</p><p align="left" style="line-height: 100%; margin-bottom: 0in;">The creation of a BWM patch alone was a
very error prone and tedious process. Depending on how complex
the accompanying BWM installation instructions were, AMARC management would actually put several Bell Labs engineers on a
flight, along with their precious 9-track BWM cargo which they would
hand carry to the RBOC central offices and assist the RBOC in
installing.</p><p align="left" style="line-height: 100%; margin-bottom: 0in;">So it wouldn’t surprise me in the least if those
worst case scenarios wouldn’t add another cost factor of 2 or 3 at
a minimum. There was a lot of labor costs involved with those BWMs as
well as travel-related expenses. It was a different day than it is
today where software is delivered online. Most people forget how much
of a pain it was to install software from DVDs and some may even
remember floppy disks, but 9-track takes were worse. There were cases
reported where they would get to a central office and couldn’t
install a tape because it turned out the read/write heads on the TU10
tape drive were out of alignment so they hard to send a new tape.
(They did try reading the tape on a different one than the TU10 that
had recorded it to ensure that those heads were within spec.)</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">Now if
there were a major design error that would have caused a problem like
the one I described, instead of some coding error, it would have been
even more costly, especially if you would account for all the lost
revenue because AMARC crashed and lost about 2 hours of long distance
billing data.</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">I can’t
speak for the cited IBM figures that Roger Pressman cited because I’m
not aware of their development processes or how their revenue stream
worked. But if you consider something like all the additional
expenses and all the lost revenue in these worst case scenarios, it’s
certainly plausible that a bug found early in the design process
could cost 100x or so less to fix than one discovered post-release.
It’s a very different world that we live in.</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">So, in
my mind, if Pressman is to be blamed for anything, it’s that he’s
never bothered to update those figures for common day development
processes. Unfortunately, once outdated hyperbole like this gets
started, they take on a life of their own, so yeah, there’s
definitely damage done.</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">One
last thing...I remember reading and discussing a proprietary Bell
Labs Technical Memorandum with a different project team somewhere
around 1985-1987 or so. The supervisor of the test team for the
Network Control Point (NCP) project, Dennis L. McKiernan [yeah, the
same one who has <a href="https://www.bookseriesinorder.com/dennis-l-mckiernan/">authored
many fantasy series novels</a>] brought it to our attention. The
details are fuzzy, but I think the author of that Technical
Memorandum studied the #5ESS project (which was Bell Labs biggest
project at the time in terms of lines of code) and reported a more
modest factor of 20 in bugs found and fixed early in the software
development projects vs those fixed post-release. I don’t recall
the author of that TM’s name, but if you know any old hats from
Bell Labs (besides me), they might remember. (Some of the surviving
dinosaurs from that era at Bell Labs had much larger brains than I.
:) I don’t think the report made it into the BSTJ, but it might
have; if we could find the author’s name, we may be able to dig it
up especially if it was ever published in the BSTJ.</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;"><br />
</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">-kevin
“Mr. TL;DR Dinosaur” wall</p>
<p align="left" style="line-height: 100%; margin-bottom: 0in;">P.S.- I
wish I could say that the situation of intellectual laziness has
improved for those citing statistics in IT / computer science
projects, but even papers written by CS professors in academia
frequently omit so many details to make any experimental results hard
to verify because the experiments are seldom repeatable. (There are
some, but it is far from the norm, especially when it comes to
software engineering practice and metrics. Maybe that would make a
nice topic for a future Crash Override blog post. I would attempt it,
but this one completely wore me out and it takes a lot longer for
dinosaur batteries to recharge. ;-)</p>
<p><style type="text/css">p { margin-bottom: 0.1in; line-height: 115% }a:link { so-language: zxx }</style></p>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-79600150158707198912019-02-08T21:14:00.001-05:002019-02-08T21:17:29.115-05:00Self @deprecation -- My life as a Javadoc commentMy current job for the past 5+ years involves doing security code reviews.<br />
<br />
During the past 2 days, we had been having a lengthy conversation of how we map a third party assessment finding for Server-Side Request Forgery (SSRF) to one of our team's categories...essentially a task of pounding a square peg into a round hole. A mini-debate ensued when a colleague asked for an example or two of SSRF, which I offered. That colleague then decided to write up a small code snippet to test one of our internal proprietary tools to see if he could get it to recognize SSRF. One of the lines from his example code snippet had this gem in it:<br />
<br />
<span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;"> <span style="color: red;">request.getFromKevin("url");</span></span></span><br />
<br />
<h3>
My Reply</h3>
For some reason—perhaps simply in an attempt to put the seemingly endless email thread to bed—I decided to poke fun at myself in a self deprecating way. Here was my response to the email. (It's probably too long, and no one will read it though. :)<br />
<br />
<div class="MsoNormal">
<span style="font-size: large;"><span style="color: #1f497d;">Wait, what? HttpServletRequest.<wbr></wbr>getFromKevin(String) ??? I want to see the Javadoc for that one.</span></span></div>
<span style="font-size: large;">
</span>
<div class="MsoNormal">
<br /></div>
<span style="font-size: large;">
</span>
<div class="MsoNormal">
<span style="font-size: large;"><span style="color: #1f497d;">It probably reads something like:</span></span></div>
<div class="MsoNormal">
<br /></div>
<table border="0" cellpadding="0" cellspacing="0" class="m_-7887262145607347559MsoNormalTable" style="background: #dbe5f1; border-collapse: collapse; margin-left: 30.2pt;">
<tbody>
<tr>
<td style="border: solid windowtext 1.0pt; padding: 0in 5.4pt 0in 5.4pt; width: 467.5pt;" valign="top" width="623"><div class="MsoNormal">
<span style="color: #1f497d; font-size: 14.0pt;">getFromKevin</span></div>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in;">
<span style="color: #353833; font-family: "&quot" , serif; font-size: 13.5pt;"><a data-saferedirecturl="https://www.google.com/url?q=http://docs.oracle.com/javase/7/docs/api/java/lang/String.html?is-external%3Dtrue&source=gmail&ust=1549761839204000&usg=AFQjCNHAUQf07azUF9m35Bj_t8uPRkzLKQ" href="http://docs.oracle.com/javase/7/docs/api/java/lang/String.html?is-external=true" target="_blank" title="class or interface in java.lang"><span style="color: #4a6782;">String</span></a> <span style="color: orange;">getFromKevin(</span><a data-saferedirecturl="https://www.google.com/url?q=http://docs.oracle.com/javase/7/docs/api/java/lang/String.html?is-external%3Dtrue&source=gmail&ust=1549761839204000&usg=AFQjCNHAUQf07azUF9m35Bj_t8uPRkzLKQ" href="http://docs.oracle.com/javase/7/docs/api/java/lang/String.html?is-external=true" target="_blank" title="class or interface in java.lang"><span style="color: #4a6782;">String</span></a> <wbr></wbr><span style="color: orange;">url)</span></span><span style="color: #353833; font-family: "&quot" , serif; font-size: 13.5pt;"></span></div>
<div class="MsoNormal" style="margin-left: .5in;">
<span style="font-size: small;"><span style="color: orange;"><span style="font-family: "dejavu serif" , serif;">A promising sounding method that in fact does nothing, much like Kevin. In fact, the</span><span style="font-family: "&quot" , serif;">
</span><span style="color: #6fa8dc;"><span style="font-family: "courier new";">url</span></span><span style="font-family: "&quot" , serif;">
</span><span style="font-family: "dejavu serif" , serif;">parameter is completely ignored and the contents of</span><span style="font-family: "&quot" , serif;">
</span><b><span style="font-family: "courier new";">/dev/urandom</span></b><span style="font-family: "&quot" , serif;">
</span><span style="font-family: "dejavu serif" , serif;">are
read from for 3GB or until the application crashes, whichever comes
first. This is method is used to simulate reading Kevin’s random babble
that he posts to simple Yes/No
questions and instead makes you forced to drink from a fire hose until
your insides burst.</span></span></span></div>
<div class="MsoNormal" style="line-height: 14.7pt; margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in;">
<span style="font-size: large;"><span style="color: yellow;"><span class="m_-7887262145607347559paramlabel"><b><span style="font-family: "&quot" , serif;">Parameters:</span></b></span></span></span><b><span style="color: #4e4e4e; font-family: "&quot" , serif;"></span></b></div>
<div class="MsoNormal" style="line-height: 14.7pt; margin-bottom: 7.5pt; margin-left: .5in; margin-right: 0in;">
<span style="font-size: small;"><span style="color: #6fa8dc;"><span style="font-family: "courier new";">url</span></span><span style="color: #474747; font-family: "dejavu serif" , serif;"><span style="color: orange;"> -</span> <span style="color: orange;">a
</span></span><span style="color: orange;"><span style="color: #6fa8dc;"><span style="font-family: "courier new" , "courier" , monospace;">String</span></span><span style="font-family: "dejavu serif" , serif;"> which is ignored, just like we try to do with Kevin</span></span></span></div>
<div class="MsoNormal" style="line-height: 14.7pt; margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in;">
<span style="font-size: large;"><span style="color: yellow;"><span class="m_-7887262145607347559returnlabel"><b><span style="font-family: "&quot" , serif;">Returns:</span></b></span></span></span><b><span style="color: #4e4e4e; font-family: "&quot" , serif;"></span></b></div>
<div class="MsoNormal" style="line-height: 14.7pt; margin-bottom: 7.5pt; margin-left: .5in; margin-right: 0in;">
<span style="font-size: small;"><span style="color: orange;"><span style="font-family: "dejavu serif" , serif;">a </span><span style="color: #6fa8dc;"><span style="font-family: "courier new";">String</span></span><span style="font-family: "dejavu serif" , serif;">
</span><span style="font-family: "dejavu serif" , serif;">containing random babble or a
</span><span style="color: #6fa8dc;"><span style="font-family: "courier new";">PleaseMakeHimStopException</span></span><span style="font-family: "dejavu serif" , serif;">
</span><span style="font-family: "dejavu serif" , serif;">is thrown if the application runs out of memory trying to process the request</span></span></span></div>
<br />
<span style="color: #474747; font-family: "dejavu serif" , serif; font-size: 10.5pt;"></span>Anyway, let me know what you think. For those who are familiar with my TL;DR tendencies, you're probably thinking this fits me to a tee.<br />
<br />
-kevin<br />
P.S.- Follow me on Twitter @KevinWWall and RT if you enjoyed this. (Of course, others are saying "No, no. Don't encourage him or he will never shut up.")Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-17067795734097814122016-10-15T12:24:00.001-04:002016-10-15T12:24:19.415-04:00Crypto Humor
<style type="text/css">p { margin-bottom: 0.1in; line-height: 120%; }a:link { }</style>
<br />
On October 6, 2016,
I presented a talk at the <a href="https://www.rochestersecurity.org/">Rochester
Security Summit</a> titled<a href="https://www.rochestersecurity.org/schedule/owasp-track/#o3"> "Common
Developer Crypto Mistakes". </a><div style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in;">
When I found out
that my time slot was going to be the one right after lunch, I
thought perhaps a little relevant humor would be good to help wake up
the audience.</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
So, I did a bunch of
research (okay, okay, this was way too much fun to qualify as
“research”, but hey) and searched the Internet for jokes related
to cryptography. (Using crypto-related cartoons / drawings—of which
there are a lot more--was basically out because of my company's
legal department's concern with potential copyright issues.)</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
The favorite joke
that I found that I really wanted to use was this one, but since I
was presenting the slides from a PDF slide deck, it was a bit hard to
do without prematurely revealing the punch line:</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">Q: How many cryptographers does it take to change a light bulb?</span></div>
<span style="color: orange;">
</span><div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">
A: ^T2u#�5�e|�Z�Lj�lz�jC#M</span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
So instead, I ended
up going with this joke:</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">I was going to start off by telling you a couple of good cryptography
jokes, but unfortunately you can't tell the difference between them
and random gibberish, so I decided against it.</span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
Here are a few
others that I found somewhat humorous that I was not able to fit into
the prezo or considered ill-suited for the audience. You may or may
not enjoy these, depending on how warped your sense of humor is and
how much of a background in crypto you have:</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">Have you heard about the cryptographer who replaced his door with one
that is 3 feet thick?</span></div>
<span style="color: orange;">
</span><div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">
The lock on the old door could only take short keys.</span></div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">Two hashes walk into a bar, one was a salted.</span></div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">I was nearly arrested for SHA1 checksumming a doctor’s
prescription. Luckily the hash was for medicinal purposes.</span></div>
<div align="right" style="line-height: 100%; margin-bottom: 0in;">
-- Ben
Lynn <a href="mailto:blynn@cs.stanford.edu">blynn@cs.stanford.edu</a></div>
<div align="left" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
I also ran across
also this long(ish), but rather humorous discourse by John Gordon</div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<a href="http://downlode.org/Etext/alicebob.html">The Alice and Bob
After Dinner Speech</a></div>
<div style="line-height: 100%; margin-bottom: 0in;">
that you might
enjoy.</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
And lastly, there's
my email .sig that I've been using ever since the Snowden
revelations:</div>
<div style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in;">
<span style="color: orange;">NSA: All your crypto bit are belong to us.</span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
which many people
like, but I didn't use in the presentation because some also
apparently find it offensive.</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<br />
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
Anyhow, thanks for
smiling!</div>
<div style="line-height: 100%; margin-bottom: 0in;">
-kevin</div>
Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-1614459594271687052014-03-28T21:43:00.000-04:002014-03-28T21:43:40.468-04:00ESAPI No Longer an OWASP Flagship Project
<h2>
<span style="color: yellow;">I read the news today oh, boy…</span></h2>
By now, you’ve probably heard about several of the OWASP board members (and
perhaps, some bored members as well) coming to the conclusion that several of
the current OWASP flagship code projects should be demoted and others should take
their places. (If you’re not up on the news, you can read about it in these 3
email threads archived <a href="http://lists.owasp.org/pipermail/owasp-board/2014-March/013357.html"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">here</span></a>,
<a href="http://lists.owasp.org/pipermail/owasp-board/2014-March/013362.html"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">here</span></a>,
and <a href="http://lists.owasp.org/pipermail/owasp-board/2014-March/013364.html"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">here</span></a>.)<br />
<br />
Among the flagship projects suggested for being demoted is OWASP <a href="https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">ESAPI</span></a>,
of which I am the project owner for the Java implementation.<span style="mso-spacerun: yes;"> </span>After hearing about the recent ESAPI
Hackathon, you may be puzzled or perhaps even surprised by this news. You
shouldn’t be. While it may sound like heresy coming from an ESAPI believer,
although I am not happy about it, I think this action is long overdue and is
best for OWASP. So I guess I’m sorry if I disappoint those of you who are ESAPI
fans because I’m not standing up for ESAPI and defending it, especially since it's not yet a done-deal.<br />
<br />
I’m not, because I can’t. I, for one, can see the writing on the wall. (Pun intended.) All of the allegations that are being made against
ESAPI are spot-on:<br />
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Only one minor point release in since July 2011.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>164 open issues, including 4 marked Critical and
11 marked as High.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Far too many dependencies, something that has
never been addressed despite being promised for almost 3 years.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Wiki page still in the old OWASP format.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Minimal signs of life of for ESAPI 3.0 in GitHub
and ESAPI 2.x for Java on Google Code. Zero signs of life for implementations
in other programming languages. [Note: Discounting the SalesForce one as I’ve
not kept track of it.]</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>For ESAPI for Java, a boogered up architecture
where everything is a singleton making some things such as mock-testing all but
impossible. Less than 80% test code coverage, in part, because of that.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Lack of any significant user documentation
outside of the Javadoc and the ESAPI crypto documentation.</div>
<div style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Disappointing participation at the ESAPI
Hackathon.</div>
<br />
I could go on, but I won’t.<br />
<br />
ESAPI has dropped the baton and I’ll take as much blame for that as anyone.
I have neither the contacts nor the people skills needed to entice developers
to participate in ESAPI. Of the 3 or 4 people that I have recruited at one time
or another, they’ve not contributed to even a single bug fix. And it goes
beyond that. I’ve still not yet put together a release based on the few updates
(a couple minor bug fixes and a small enhancement in handling configuration
files) that were done by those participating at the ESAPI Hackathon. I have also still
yet to release a fix for CVE-2013-5960. (Aside: Hey! Could use a little help
here! Ideally someone who knows a thing or three about crypto.)<br />
<br />
It’s time that ESAPI yield the baton to some of the other worthy candidates
like OWASP HTML Sanitizer, OWASP Dependency Check, and OWASP Java Encoder to
name just a few.<br />
<h2>
<span style="color: yellow;">What does this mean for ESAPI support?</span></h2>
Well, probably nothing. I mean, honestly, the support <i style="mso-bidi-font-style: normal;">really </i>hasn’t been that great in the past 3 years. I do suspect that it might radically give those thinking about adopting it for a new project a reason to rethink that commitment though.<br />
<br />
I will personally commit to
trying to fix any known bugs in the ESAPI crypto (including a few you didn’t
even know were there; well, okay, maybe “annoyances” would be a better tem),
including a fix to CVE-2013-5960. But I am likely through with any planned
feature enhancements other than the minor ones that I’ve been working on. If I
do any further enhancements for the crypto features, I will split off ESAPI
Crypto into its own new incubator project. No more promises of time frames though. I work a 40+ hour job like most of you and the ESAPI work is volunteer hours and I have family and other commitments as well.<br />
<br />
As for ESAPI 3, will it flourish or die out before it even gets started?
Well, that’s up to you, OWASP Community. I certainly am a believer in the ESAPI
concept of a common set of interfaces for common security controls, but the
problem has always been the implementation, not the concept. As they say, the
devil is in the details.<br />
<br />
So if you want to volunteer to work on ESAPI, give us a shout out on the <a href="mailto:esapi-dev@lists.owasp.org"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">ESAPI-Dev list</span></a>.
If you aren’t already signed up, you can sign up <a href="https://lists.owasp.org/listinfo/esapi-dev"><span style="mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: major-fareast;">here</span></a>.<br />
<br />
Best regards,<br />
-kevin<br />
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="267">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com6tag:blogger.com,1999:blog-8976089095047007543.post-9751473364581330062013-06-23T17:31:00.001-04:002013-06-24T05:17:54.755-04:00Appalachian Security<div dir="ltr" id="docs-internal-guid-70828580-72ce-5ee9-6a05-cba0e6daac7a" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">This is just too funny to keep to myself.</span> This was written about 3 years ago by a former colleague of mine who was the
PM for our Application Security group. He wrote it when I announced
that I was leaving the Application Security team to join the
Information Security team under Corporate Security. I happened to run
across it again as I was cleaning out stuff in preparation for my last
day at CenturyLink (which was Friday, 6/21/2013). It was originally posted along with a photo of <i>The Beverly Hillbillies' </i>character, Jed Clampett. Out of respect for Buddy Ebsen, who played Jed </span><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Clampett</span>, I've chosen not to include the photo so as not to diminish Ebsen's legacy by being associated with me.</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Naturally, this was meant to be accompanied by the original theme song from the <a href="http://www.youtube.com/watch?v=YD22a4APsCg" rel="nofollow" target="_blank"><i>Beverly Hillbillies</i></a>. Now maybe if I can just get
<a href="http://www.cigital.com/~gem/" target="_blank">Gary McGraw</a> and <a href="http://www.wheresaubrey.com/" target="_blank">Where’s Aubrey</a> to record it... :)</span></span></div>
<span style="color: white;"><br /></span><span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Enjoy,</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">-kevin</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="color: yellow;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 24px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Appalachian Security</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;"><span style="color: yellow;">by Mark Hersman (July 2010)</span></span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Come and listen to a story about a man named Kev</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">A poor engineer, barely kept his family fed,</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Then one day he was "working" on an app,</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">His pager started beeping, nearly woke him from his nap.</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Awake that is , Consciousness.</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Well the first thing you know ol Kevs got a scare,</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">His judgement says "Kev get away from there"</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Says "The Lavratory is the place you ought to be"</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">So he slips Hanbin the pager, and he goes to take a ……...</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">A break, that is. Quiet time.</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Well now its time to say goodbye to Kev and all the guys.</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">And they would like to thank fer usin ClearTrust APIs.</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">You're all invited back again to this locality</span></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">To have a heapin helpin of app security</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Kevin style that is. Set a spell, Take your shoes off.</span></span></div>
<span style="color: white;"><br /></span>
<span style="color: white;"></span><br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: white;"><span style="background-color: transparent; font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Y'all come back now, y'hear?</span></span></div>
Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-55972954916032061292012-11-12T18:49:00.001-05:002012-11-12T18:49:48.289-05:00RSA Distributed Credential Protection: Solving the Wrong Problem?Recently, RSA Distributed Credential Protection (DCP) was <a href="http://www.emc.com/about/news/press/2012/20121009-01.htm" target="_blank">announced by RSA Security</a>. I’ve read the literature, sat through a presentation by an RSA sales representative, and watched the YouTube videos. And most of all, have formed an opinion.<br />
<br />
Being a crypto geek of sorts, I’ll be the first to admit that this seems like a really cool and interesting application of secret splitting. But, as much as RSA makes it sound like the most innovative thing since sliced bread, I believe that is fundamentally a solution to the wrong security problem. Let’s have a look at why.<br />
<br />
As I’ve written many times, security is fundamentally about ensuring trust and managing risk. When attempting to lower risk, there is always a cost / benefit balance that needs to be studied. Just as one would not spend $10,000 for a home safe only to store $1000 in it, IT is not going to spend six figures on a solution that will not reduce the perceived cost of the risk at least that much. (Note that while I am not certain of the pricing of RCA DCP, it is not farfetched to think that an enterprise rollout would be near the six figure range.)<br />
<br />
RSA advertises DCP to be transparent to the end users, and so it is. However, that is not the only thing that is important here. Another major factor that only came out during the live presentation by RSA was that any application wishing to take advantage of DCP needed to change their application to adapt to its API. This means of course if you have N applications all authenticating users to an SQL database (or perhaps an LDAP directory store, if the API works with that), all N of those applications need to be changed. If you fail to change one application, then you still need the user’s stored in a single data store where DCP is not applied and consequently still remain unprotected. So take the cost of licensing the RSA DCP software and add to it the cost of each of your N applications integrating the DCP API and you will have something closer to the total cost of deployment. Of course, the operational costs are also likely to increase somewhat as well. Whereas before you had but a single data store for said credentials, now you have two. The end result is that the total cost to incorporate RSA DCP into your environments is likely to exceed the six figure level even if the software licensing costs is nowhere near that amount.<br />
<br />
Well, still, that might be OK, right? After all, if the perceived benefits greatly exceed the total costs of mitigation, we still have a security win.<br />
<br />
So what benefits does RSA DCP bring to the enterprise? According to the <a href="http://www.emc.com/about/news/press/2012/20121009-01.htm" target="_blank">RSA press release</a> as well as <a href="http://www.youtube.com/watch?v=C0k_EMf2qqw&feature=youtu.be" target="_blank">this YouTube video</a>, the threat that RSA is trying to prevent is the “smash-and-grab” of credentials by an attacker. Specifically, DCP is designed to make it more difficult for an attacker who has infiltrated your company network and has managed to get direct access to your database server to obtain credentials (either plaintext or hashes). DCP also would likely mitigate a rogue DBA doing a “smash-and-grab” of your company’s credential data as well, as long as care was taken to provide separation of duties and not give a single administrator a DBA role on both DCP servers.<br />
<br />
So we still need to answer this question: Is this a common way for an attacker to gather user credentials? In my opinion, it is not. By far, the biggest attack vector for adversaries stealing credential material is via SQL (or possibly LDAP) injection attacks. Will DCP do anything to mitigate SQLi attacks? The answer would appear to be “no” (at least according to the RSA sales rep that we talked to). In fact, given that one has to bolt new DCP API code into one’s application to use DCP, there is a chance that new SQLi vulnerabilities may be introduced as developers change the application code.<br />
<br />
So is there a place where using RSA DCP would make sense? I believe so, but I think it is a niche market rather than the broad market RSA Security would like it to be. RSA DCP could be very valuable where you have an extremely high-value target (credentials or otherwise) that are difficult to upgrade. The perfect example that comes to my mind is protection of the RSA Security SecurID seeds. Compromise of those SecurID seeds required RSA to replace all the hard token SecurID devices. In fact, it is not unreasonable to speculate that this product came directly out of researching ways to protect those high-value credentials from the smash-and-grab type of direct attacks resulting out of that breach. If RSA Security wishes to broaden the market for their new DCP product, I believe that the best approach is for them to integrate DCP seamlessly in with their other products, starting with RSA Access Manager. If you are going to make a believer of us security folk, you first have to be willing to eat your own dog food.<br />
<br />
However, in the meantime, for your regular user passwords, salting with a sufficiently long random salt, enforcing password complexity rules when users select their passwords, and enforcing account lockout are likely to be sufficient protection for your customer passwords. If doing those things is not sufficient, you seriously need to consider whether passwords are a strong enough form of authentication for your users.<br />
<br />
Note that the views expressed herein are wholly my own and do not represent those of my company, of OWASP, nor any other organizations with whom I am associated.<br />
<br />
Regards,<br />
<br />
-kevinKevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com3tag:blogger.com,1999:blog-8976089095047007543.post-47545738502442362302012-01-20T13:20:00.000-05:002012-01-20T13:20:32.530-05:00USACM Policy Statement on SOPA and PIPAFor now, the immediate battle seems to have been won, but you can be sure that the MPAA and their cohorts will be back soon.<br />
<br />
However, I wanted to point everyone to this <a href="http://techpolicy.acm.org/blog/wp-trackback.php?p=1877">USACM blog post</a> that provides their policy statement regarding SOPA and PIPA. If you don't want to read their full policy statement, I would at least encourage you to take a quick look at their very approachable (by non-Geeks ;-) "<a href="http://usacm.acm.org/images/documents/DNSDNSSEC.pdf">Analysis of SOPAʼs impact on DNS and DNSSEC</a>".Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com2tag:blogger.com,1999:blog-8976089095047007543.post-11739083637761776742012-01-06T21:45:00.000-05:002012-01-06T21:45:33.700-05:00Misunderstanding Trust<h1 class="western" style="color: yellow;"><span style="font-size: medium;">Background</span></h1><span style="font-size: small;">Last July, I blogged about “<a href="http://off-the-wall-security.blogspot.com/2011/07/understanding-trust.html">Understanding Trust</a>”, in which I attempted to describe several properties of trust. Because I thought that most of these properties were obvious, I was somewhat surprised to see someone with an interest in security authoritatively quote a well-known Microsoft software developer in post on a cryptography mailing list that “trust is not transitive”.</span><br />
<br />
<span style="font-size: small;">Of course I strongly disagreed. If you are interested in the specific context, you can find the full text of my post in the crypto mailing list <a href="http://lists.randombit.net/pipermail/cryptography/2011-September/001431.html">archives</a>. However, based on the research that I did and this specific post made me aware that there are still several software and security engineers who still have a misunderstanding of trust. So I decided that perhaps I should attempt to clear up this misunderstanding.</span><br />
<h1 class="western" style="color: yellow; page-break-after: avoid;"><span style="font-family: Arial,sans-serif;"><span style="font-size: medium;">Is Trust Transitive or Isn't It?</span></span></h1><span style="font-size: small;">The post to the cryptography mailing list that I attempted to refute started out by citing Microsoft developer, Peter Biddle, stating “<i>More fundamentally, as Peter Biddle points out, trust isn't transitive</i><span style="font-style: normal;">”.</span></span><br />
<span style="font-size: small;">So, before writing a rebuttal to his response, I thought it would be a good idea to track down the source of Peter Biddle's comments. I eventually found the source in Peter Biddle's blog post titled “<a href="http://peternbiddle.wordpress.com/2008/03/26/trust-isnt-transitive-or-someone-fired-a-gun-in-an-airplane-cockpit-and-it-was-probably-the-pilot/">Trust Isn’t Transitive (or, 'Someone fired a gun in an airplane cockpit, and it was probably the pilot')</a>”.</span><br />
<br />
<span style="font-size: small;">Myself and I think most security pundits really believe that Peter Biddle is wrong about trust not being transitive. If you read carefully through Peter Biddle's blog on this topic, you will see (as Keith Irwin so aptly pointed out in a reply to the Randombits.net cryptography mailing list) that Biddle is mixing contexts here. In a nutshell, in Biddle's blog, he is making the argument that trust in two completely different contexts equates to trust in general (i.e., any context) and therefore concludes trust is not transitive.</span><br />
<br />
<span style="font-size: small;"> </span> <br />
<span style="font-size: small;">However, trust <i>clearly</i> is context dependent and when considering whether or not trust is transitive, we need to consider the <i>same</i> context.</span><br />
<br />
<span style="font-size: small;">Specifically, if C1 and C2 are two different contexts, it does NOT logically follow that:</span><br />
<span style="font-size: small;"> There exists a context C1 such that “Alice trusts(C1) Bob”</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">There exists a context C2, where C1 != C2, such that “Bob trusts<C2> Carol”</span><br />
<span style="font-size: small;">Therefore,</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Alice trusts<C> Carol for all contexts, C.</span><br />
<span style="font-size: small;">where trusts<<i>C</i>> means “trust in context <i>C</i>”.</span><br />
<br />
<span style="font-size: small;">That seems to be the way that Biddle is arguing about trust not being transitive. Well, if that's the way he's defining it, then of course it's not transitive.</span><br />
<br />
<span style="font-size: small;">If it is just that...well, that's the WRONG way to reason about transitivity in general, and trust being transitive in particular.</span><br />
<br />
<span style="font-size: small;">Transitivity is a mathematical property of some relationship R and says for x, y, and z are members belonging to some well-defined set, then we call relationship <i>R</i> <i>transitive</i> if:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">( x<i>R</i>y <span style="font-family: Times New Roman,serif;">˄</span> y<i>R</i>z ) <span style="font-family: Times New Roman,serif;"><span style="font-weight: normal;">→</span></span><span style="font-family: Times New Roman,serif;"> </span>x<i>R</i>z</span><br />
<span style="font-size: small;">for all x, y, and z elements of some set S. (See the Wikipedis article on <a href="http://en.wikipedia.org/wiki/Transitive_relation">transitive relationships</a> for more thorough, but very comprehensible treatment of this.)</span><br />
<br />
<span style="font-size: small;">However, in Biddle's blog where he gives his examples, all the examples that he mentions is is talking about two different contexts (e.g., flying planes and handling firearms, or working on cars and taking care of kids).</span><br />
<br />
<span style="font-size: small;">That is, Biddle is really discussing two <i>different</i> relationships</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">trust<flying planes></span><br />
<span style="font-size: small;">and</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">trust<handling firearms></span><br />
<span style="font-size: small;">and what he is then trying to conclude is that</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">( x trust<flying planes> y ) AND ( y trust<handling firearms> z ) IMPLIES ( x trust<C> z )</span><br />
<br />
<span style="font-size: small;">for any context C. Well, duh! If you make a fallacious straw man argument about trust being transitive in this manner, of course your conclusion this going to be that "trust is NOT transitive". But you would also, IMHO, be wrong. If we stick to a specific context / attribute however, then I think you will find the logic concludes that trust is transitive. (But, I'll show later it's not really quite <i>that</i> simple.)</span><br />
<br />
<br />
<br />
<span style="font-size: small;">Here's a really nutty case restricted to a specific context that I hope will make the point. Let's conjecture that both</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Passengers trust<flying planes> Pilot P</span><br />
<span style="font-size: small;">and</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Pilot P trust<flying planes> Chimpanzees</span><br />
<span style="font-size: small;">are true. (That is, “passengers trust some specific pilot P in flying planes” and “some (same) specific pilot P trusts chimpanzees in flying planes.) So, some pilot P brings his trusted chimpanzee into the cockpit and shortly after takeoff, he decides to take a little nap so handles the controls over to his chimp pal. And all this occurs unbeknownst to the passengers. So what do we conclude? Well, logic dictates that based on the premises, we may conclude:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Passengers trust<flying planes> Chimpanzees</span><br />
<br />
<span style="font-size: small;">But wait! That's absurd you say. Well, perhaps. But then again, whether the passengers know it or not, the Chimp who is supposedly flying the plane is pretty much holding the lives of the passengers in his hands (or is that paws?).</span><br />
<br />
<span style="font-size: small;">On one hand, these passengers are literally (unbeknownst to them) trusting that chimp to safely fly that plane. (Or course, on the other hand, if there where a dozen parachutes on the plan, there would be a blood bath seeing who would get them. ;-)</span><br />
<br />
<span style="font-size: small;">Now lets make a little change in the premise. Let's substitute 'Auto Pilot System' for 'Chimpanzees'.</span><br />
<br />
<span style="font-size: small;">The conclusion is now:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Passengers trust<flying planes> Auto Pilot System</span><br />
<br />
<span style="font-size: small;">All I've done is exchanged one symbol (Chimpanzee) with another (Auto Pilot System), but all of sudden most of us feel a whole lot better.</span><br />
<br />
<span style="font-size: small;">So what does that tell us about 'trust'? Well, for one, the <b>human </b>concept of trust is much more complex than some simplistic quantifiable mathematical property as we have been trying to model it thus far. And herein a big problem in security. Why? Because the software systems that we construct can no way approach the complexity of all these nuances. (Not that it matters a whole lot. History has shown that we can't even get the simpler model correct, but I digress.)</span><br />
<h1 class="western" style="color: yellow; page-break-after: avoid;"><span style="font-family: Arial,sans-serif;"><span style="font-size: medium;">But Wait, There's More</span></span></h1><span style="font-size: small;">In the post that I responded to where the poster was arguing that trust was transitive, they continued with this example:</span><br />
<div style="margin-left: 0.49in;"><span style="font-size: small;">When CAs [Certificate Authorities] get in the habit of delegating their power, that process is at risk of being bypassed and in any case starts to happen much less transparently. There are plenty of cases in the real world where someone is trusted with the power to take an action, but not automatically trusted with the power to delegate that power to others without external oversight. And that makes sense, because trust isn't transitive.</span></div><br />
<span style="font-size: small;">This statement makes sense, but NOT because 'trust isn't transitive'. Here the mistake in reasoning is not in trying to equate two different contexts. Rather, it makes sense because of another aspect of trust that I have discussed before on my “<a href="http://off-the-wall-security.blogspot.com/2011/07/understanding-trust.html">Understanding Trust</a>” blog post. Specifically,</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Trust is not binary.</span><br />
<br />
<span style="font-size: small;">Trust is not black or white; it is shades of gray. As humans, for a given context, we "assign" more trust to some and less to others. This "level of trust" is largely based on our <i>perception</i> of experience and reputation, the latter which we sometimes try to model in reputation-based systems.</span><br />
<span style="font-size: small;">An example...unfortunately, you need brain surgery. (If you are reading this blog, that should be proof enough. I rest my case. ;-) You have two surgeons to choose from:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Surgeon #1: 10 years of experience and over 300 operations.</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Surgeon #2: 1 year of experience and 6 operations.</span><br />
<br />
<span style="font-size: small;">All other things being equal, who you gonna choose? Surgeon #1, right? (Well, unless in those 300 operations, s/he has had 250 malpractice results. ;-) And at least <i>by comparison</i>, you probably do NOT trust Surgeon #2.</span><br />
<br />
<span style="font-size: small;">So, with that in mind, let's get back to the transitivity part:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">You trust<brain surgery> Surgeon #1</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">Surgeon #1 trust<brain surgery> Surgeon #2</span><br />
<span style="font-size: small;">so, obviously,</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">You trust<brain surgery> Surgeon #2.</span><br />
<br />
<span style="font-size: small;">Whoa! Wait a minute. Didn't we just say that we did NOT trust Surgeon #2. Yep!</span><br />
<br />
<span style="font-size: small;">So what went wrong here? Well, that went wrong is that we are assuming that trust behaves as a <i>binary</i> relationship...that I either have complete trust or zero trust. But trust is not binary. It is shades of gray. That means that to more accurately model trust in the real world, we need some property for that relationship that indicates a <i>level</i> of trust, rather than trust just being T/F. So we need that <i><b>in addition to</b></i> a context.</span><br />
<br />
<span style="font-size: small;">So now we see we need (at least) something like:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">trust<level, context></span><br />
<span style="font-size: small;">to model trust. Where before we just were (implicitly) using something like</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">trust<{T,F}, context></span><br />
<span style="font-size: small;">(which allowed us to model only complete trust or no trust), we find we now need something more like:</span><br />
<span style="font-size: small;"> </span><span style="font-size: small;">trust<[0,1], context></span><br />
<br />
<span style="font-size: small;">That is, we model level as a real number in the range 0 to 1, inclusive.</span><br />
<br />
<span style="font-size: small;">Cryptographer and software engineer Ben Laurie pointed out that trusted modeled in this way is very similar to <a href="http://keyman.aldigital.co.uk/">KeyMan</a>, a piece of software that he and Matthew Byng-Maddick developed back in 2002 to facilitate the management of keys, certificates and signatures used in signing software in a distributed and exportable network of trust.</span><br />
<br />
<span style="font-size: small;">So... we're done now, right? Well, not so fast Sparky. There are other important properties of trust that I already covered in my “<a href="http://off-the-wall-security.blogspot.com/2011/07/understanding-trust.html">Understanding Trust</a>” blog post last July. If you have not already done so, I would encourage you to go back and read it.</span><br />
<h1 class="western" style="color: yellow; page-break-after: avoid;"><span style="font-family: Arial,sans-serif;"><span style="font-size: medium;">Recasting Trust</span></span></h1><span style="font-size: small;">The term “trust” is overloaded with several meanings and therefore causes a lot of confusion. On the Randombit.net crypto mailing list, Marsh Ray suggested that we use the term “relies on” as suggested by his former colleague <span lang="en-US">Mark S. Miller</span>.</span><br />
<br />
<span style="font-size: small;">I think in general, this is a great idea. If we say that “A relies on B” and “B relies on C”, then it is intuitively obvious that “A relies on C”, and hence transitivity immediately follows.</span><br />
<br />
<span style="font-size: small;">Using “relies on” works in many situations when we normally might use the word “trust” as a verb. I for one intend on starting to use it much more often than I do, because you have no idea how many times I almost accidentally made an embarrassing typo and misspelled “trust” as “tryst”. But perhaps that's the true hidden cryptographic meaning of cryptographers using Alice, Bob, and Carol in their discussions. As with many things cryptographic, maybe there's more going on there than is apparent. (I'll kindly spare you the obvious pun in this case.)</span><br />
<br />
<span style="font-size: small;">Regards,</span><br />
<span style="font-size: small;">-kevin</span><br />
<div style="margin-bottom: 0in;">P.S.- I promise I will try to be a little more consistent with my blogging in 2012. (Did I just make a New Year's resolution? ;-) But thanks to all of you who have been faithful in reading and haven't completely given up on me.</div><div style="margin-bottom: 0in;"> </div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com6tag:blogger.com,1999:blog-8976089095047007543.post-85826863567087555602011-08-21T22:39:00.001-04:002011-08-21T23:02:56.946-04:00Colombus OWASP presentation postedOn Thursday, 2011/08/18, I made a presentation about OWASP ESAPI and my thoughts about it to the Columbus, OH local OWASP chapter. Bill Sempf, one of the chapter leaders, was kind enough to put the slides up to make them available to everyone.<br />
<br />
If you are interested in what I presented, the slides are up on the main OWASPI wiki, at:<br />
<a href="https://www.owasp.org/index.php/File:OWASP_ESAPI-2011.ppt">https://www.owasp.org/index.php/File:OWASP_ESAPI-2011.ppt</a><br />
<br />
<br />
<br />
<br />
Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-85652182556117172112011-07-20T20:10:00.000-04:002011-07-20T20:10:53.622-04:00Understanding TrustIt's often been said that Confidentiality, Integrity, and Availability, the so-called CIA triad, are the core principles of information security. However, I want to examine even something more fundamental than these principles; I want to look at the <i>goals </i><span style="font-style: normal;">of information security. And not just goals such as preventing unauthorized access, disclosure, disruption of use, etc. which really are just extensions of the CIA triad, but the core, essential goals that are at information security's foundation.</span> <br />
<div style="font-style: normal; margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;">At its core, information </span>security is largely about the two goals of “ensuring trust” and “managing risk”. We may deal with managing risk some other time, but today I want to focus on ensuring trust.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">In order to ensure trust, we first must understand not only what it is, but what its properties are.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Let's start with a definition. <a href="http://www.merriam-webster.com/">Merriam-Webster's dictionary</a> defines the noun, <a href="http://www.merriam-webster.com/dictionary/trust%5B1%5D?show=0&t=1311127236">trust</a> as:</div><div align="LEFT" style="line-height: 100%; margin-bottom: 0in; margin-left: 0.49in; margin-top: 0.06in;"><span style="color: black;"><span style="text-decoration: none;"><span style="font-family: Times New Roman,serif;"><span style="font-size: small;"><span style="font-style: normal;"><span style="font-weight: normal;"><span style="text-decoration: none;"><span style="color: #38761d;">1</span> </span></span></span></span></span></span></span><i>a</i> <b>:</b> <a href="http://www.merriam-webster.com/dictionary/assured%5B1%5D">assured</a> reliance on the character, ability, strength, or truth of someone or something <i>b</i> <b>:</b> one in which confidence is placed </div><div style="margin-bottom: 0in; margin-left: 0.49in;"><span style="color: #38761d;">2</span> <i>a</i> <b>:</b> dependence on something future or <a href="http://www.merriam-webster.com/dictionary/contingent">contingent</a> <b>:</b> <a href="http://www.merriam-webster.com/dictionary/hope">hope</a> <i>b</i> <b>:</b> reliance on future payment for property (as merchandise) delivered <b>:</b> <a href="http://www.merriam-webster.com/dictionary/credit">credit</a> <bought furniture on <i>trust</i>> </div><div style="margin-bottom: 0in; margin-left: 0.49in;"><span style="color: #38761d;">3</span> <i>a</i> <b>:</b> a property <a href="http://www.merriam-webster.com/dictionary/interest%5B1%5D">interest</a> held by one person for the benefit of another <i>b</i> <b>:</b> a combination of firms or corporations formed by a legal agreement; <i>especially</i> <b>:</b> one that reduces or threatens to reduce competition </div><div style="margin-bottom: 0in; margin-left: 0.49in;"><span style="color: #38761d;">4</span> <i>archaic</i> <b>:</b> <a href="http://www.merriam-webster.com/dictionary/trustworthiness">trustworthiness</a> </div><div style="margin-bottom: 0in; margin-left: 0.49in;"><span style="color: #38761d;">5</span> <i>a (1)</i> <b>:</b> a charge or duty imposed in faith or confidence or as a condition of some relationship <i>(2)</i> <b>:</b> something committed or entrusted to one to be used or cared for in the interest of another <i>b</i> <b>:</b> responsible <a href="http://www.merriam-webster.com/dictionary/charge%5B1%5D">charge</a> or office <i>c</i> <b>:</b> <a href="http://www.merriam-webster.com/dictionary/care">care</a>, <a href="http://www.merriam-webster.com/dictionary/custody">custody</a> <the child committed to her <i>trust</i>> </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">One thing that I'd like to draw your attention to is that none of these definitions (with the possible exception of #3) implies that any sort of qualitative measure for trust exists. Trust is one of those things that we think that we completely understand when we talk about it, but when we explore it a bit deeper, we discover that it has some properties that are not all that intuitive, at least not in the normal manner that we refer to trust. My intent is to help us gaze at some of these properties and in so doing, see the disconnect of how we use the word “trust” in everyday usage versus how we use it in the security world. As we will discover, it is some of these very properties that make trust so difficult to ensure in the world of information security.</div><h1 class="western" style="color: red;">Properties of Trust</h1><h2 class="western" style="color: yellow;">Trust is not commutative</h2><div style="margin-bottom: 0in; margin-left: 0.49in;">If Alice trusts Bob, it does not follow that Bob trusts Alice. To any parent, this seems pretty obvious, at least when your children are of a certain age where they still trust you. You trust you doctor, but they likely do not trust you in a similar manner. You trust your bank, but they don't trust you in the same way. Trust is not symmetrical in this way.</div><h2 class="western" style="color: yellow;">Trust is transitive</h2><div style="margin-left: 0.49in;">This means “If Alice trusts Bob, and Bob trusts Carol, then Alice trusts Carol”. This one doesn't seem quite so obvious to us. That's because in the real world where we interact with other people, we don't treat trust in this manner. If I trust my wife and my wife trusts her friend, I don't usually automatically extend my trust to her friend. But therein lies the problem. In the information security context at least, trust <i>implicitly extends</i><span style="font-style: normal;"> in this way.</span><br />
<br />
<span style="font-style: normal;"> </span> </div><div style="margin-left: 0.49in;"><span style="font-style: normal;">Think of the analogy where Alice, Bob, and Carol are all names of servers and there are trust relationships established by virtue of a </span><span style="font-family: Courier New,monospace;"><span style="font-size: x-small;"><span style="font-style: normal;"><b>/etc/hosts.equiv</b></span></span></span><span style="font-style: normal;"> on each of these servers. When described this way, it is easier to see how trust extends to be transitive even though Alice may not be aware of Bob's trust of Carol. (In a latter blog post, I hope to illustrate how this affects trust boundaries.) Alice (usually implicitly) extends here trust to Carol via Bob's trusting Carol. The big issue here is whether or not Alice's trust of Bob is warranted in the first place and that is muddied by the fact that rational humans (at least those who are worthy of that trust) will act in a moral way so as not to abuse it. But in computer security, we need to think beyond this. The big issue in making such trust decisions involving transitivity is that Alice may not be aware of any of the trust relationships that Bob has with any other parties. For example, if Alice knows Carol to be untrustworthy, she may rethink her position on trusting Bob. In other words, Alice's trust in Bob may be misplaced. The bottom line is that there's little that Alice can do to tell, except to go on Bob's </span><i>known</i><span style="font-style: normal;"> reputation. Where this really gets sticky of course is that it can extend indefinitely. Alice trusts Bob, Bob trusts Carol, Carol trusts David, David trusts Emily, so... transitivity implies that Alice trusts Emily. We can quickly get lost. Of all the aspects of trust, I think that it is this disconnect that humans have with trust being transitive that makes securing computers so difficult. We simply don't think this way intuitively when it comes to securing our systems.</span><br />
</div><div style="font-style: normal; margin-left: 0.49in;">Let's try to clarify this with an example. Let's say that you (Alice) trust a merchant (Bob's Bakery) with your credit card number. You do this by paying for your weekly doughnut supply with your credit card (online or in person, it really doesn't matter). Bob's Bakery relies on a credit agency (Carol's Credit Check) to do credit checks on its customer's credit cards before accepting each payment.<br />
</div><div style="margin-left: 0.49in;"><span style="font-style: normal;">No problem so far, right? Now you (Alice) may or may not be aware that Bob's Bakery does a credit check. As long as they accept your payment and you get your sweets, you probably don't care. You probably are not consciously thinking about any credit agency or credit card payment service. Most people are not even aware of the connection. Regardless, you are </span><i>implicitly </i><span style="font-style: normal;">extending your trust to this credit agency when you you complete such a transaction.</span><br />
</div><div style="font-style: normal; margin-left: 0.49in;">No problem, still, you say. My credit card issuer will cover any fraudulent charges. But note that is a red herring. That is why you trust your bank and your credit card, not why you trust Bob's Bakery or Carol's Credit Check.<br />
</div><div style="font-style: normal; margin-left: 0.49in;">So let's change up the scenario a bit. Let's assume that Carol's Credit Check is really run by organized crime and the purpose of their existence is to perpetuate credit card fraud. Does this change your trust of Carol's Credit Check (assuming you new of the relationship with Bob's Bakery)? Probably. Does it change your trust in Bob's Bakery? It may, if Bob's Bakery were aware that Carol's Credit Check was run by crooks. But why does you trust change? Nothing has changed except your awareness / perception. In abstract terms, it's still the same Alice trusts Bob, Bob trusts Carol, therefore Alice trusts Carol.</div><h2 class="western" style="color: yellow;">Trust is not binary</h2><div style="margin-left: 0.49in;">Trust is a matter of degree; it is gray scale, not something that is merely black or white, on or off. If this were not true, there would be no way for us to state that we trust one party more than some other party. If trust were only a binary yes/no, if Alice separately trusted Bob and Carol, Alice would never has any reason to trust Bob more than she trusts Carol. Obviously that is not how we act in the real world. Often times, even when we do not personally know someone, we grant different levels of trust based solely on reputation.</div><h2 class="western" style="color: yellow;">Trust is context dependent</h2><div style="margin-left: 0.49in;">Alice may trust Bob in some situations, but not in other situations. While this is true in computer security, it is a rather difficult property for us to model. But there is no doubt that we believe this in the real world. In real life, Alice may trust Bob to cut her hair or work on her car, but not to baby sit her kids, and almost certainly not to preform brain surgery on her (even if Bob has taken the time to read <i>Brain Surgery for Dummies</i><span style="font-style: normal;">).</span><br />
</div><div style="font-style: normal; margin-left: 0.49in;">In real life, we humans are quite adept at switching between these various contexts. So much so, that we hardly give it conscious thought. However, when we try to codify these contexts into a programmatic information model, we realize that this is a very difficult concept to formalize.</div><h2 class="western" style="color: yellow;">Trust is not constant over time</h2><div style="margin-left: 0.49in;">Alice may trust Bob at time <i>t</i><span style="font-style: normal;">, but not at some later time </span><i>t+</i><span style="color: black;"><span style="text-decoration: none;"><span style="font-family: Mangal;"><span style="font-size: small;"><i><span style="font-weight: normal;"><span style="text-decoration: none;">Δ</span></span></i></span></span></span></span><i>t.</i><span style="font-style: normal;"> In real life, Bob may do something to screw up. For instance, Alice may trust Bob while she is dating him, but after she sees Bob chasing after Carol, not so much. In computer security, we have similar analogies. For instance, we trust a session ID until after it has expired, or we trust a certificate until it has expired. It is at the basis of why we recommend that passwords expire after a time. This property of trust is one reason that authentication protocols use things like expiration times and/or freshness indicators.</span></div><h2 class="western" style="font-style: normal;"> </h2><h1 class="western" style="color: red;">Final Observations </h1><div style="font-style: normal;">These last two properties (trust is context dependent, trust is not constant over time) mean that when we discuss ensuring trust, we must do so within a specific context and time-frame. (Sometimes the time-frame is explicit and sometimes it is implied.) Generally, in computer security, we should strive to make all trust relationships explicit and leave nothing to chance or misinterpretation. That's one key step in defining a trust model, which I hope to discuss in a future blog post. In the meantime, I hope you will keep in mind some of the properties we discussed today when you are trying to secure your systems.</div><div style="font-style: normal;"><br />
</div><div style="font-style: normal;">And one more thing, my apologies for not being consistent as of late posting to this blog. Not only have I been busy for with ESAPI for C++, but I've also been at loss for interesting topics. So if you have something that you'd like to see me ramble on about, please shot me a note. (But don't be surprised if I recommend that you get so serious counseling if you do so. ;-) Thanks!</div><div style="font-style: normal;">-kevin</div><div style="margin-bottom: 0in;"></div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-60988021955797424102011-04-06T01:13:00.001-04:002011-04-06T01:17:04.087-04:00Please Stop Already—Links in HTML Emails Considered E-V-I-L<div style="color: yellow;"><b><i>Phishy or Not?</i></b></div>OK, what's wrong with this picture... you receive an unsolicited email from a financial institute with whom you have a prior existing business relationship. The email sounds very official and has none of the usual sloppy spelling or grammatical errors that are the usual tip-offs to most phishing attempts. (Thank God that the most of the idiots constructing these phishing attempts to exploit the naïve don't know how to use spelling and grammar checkers in their word processing software! ;-)<br />
<br />
However, the email is also written in HTML<a href="#stop-fn1"><sup>1</sup></a> and it obfuscates the URL they wish you to visit with the ubiquitous “Click here to activate your account” link. Furthermore, it states that once you login with your user name and password, you will be requested to enter your Social Security Number. So the email is starting to smell somewhat phishy to me.<br />
<br />
This particular email was purportedly from Morgan Stanley Smith Barney. (I'm sorry, but they deserved to be called out and shamed by this!) Naturally, I checked out the 'Received' email headers and note that they in fact do come from Citigroup, who indeed now owns MSSB. (I had to run a whois on a few of the domains I wasn't sure about, but in the end the all the domains listed in the Received headers checked out as being associated with Citigroup.)<br />
<br />
Still, I wasn't about to just hand over my SSN without being a bit more cautious. After all, one never knows if Citigroup introduced a recent misconfigured open mail relay somewhere that some phisher was trying to exploit. So I send the email with all email headers to our company spam police. After several hours, they got back to me and assured me that the email was legitimate and that it had to do with the conversion of Qwest shares to CenturyLink shares,which I thought it might and was why I didn't completely dismiss the email outright.<br />
<br />
<div style="color: yellow;"><b><i>Do As We Say, Not As We Do</i></b></div>So here is the issue. Financial institution of all kinds—whether it be banks, broker agencies, credit card companies, etc.—are constantly reminding their patrons to “not click on links from suspicious emails that appear to come from us”. If anything, they tell you to manually enter their URL into your browser's Location / Address bar. They tell us not to provide our SSN or user names and passwords to such sites. But then they turn right around and send their own customers out HTML emails with obfuscated links asking them to do the very thing that they spent several earlier emails and newsletters repeatedly educating their users not to do.<br />
<br />
<b><i>I ask you, is this practice not insane?</i></b> While I'm focusing on financial institutes here because of the MSSB email from them today, they are by no means the only culprit. I've seen this very same practice done by Microsoft in some of their emails. In fact, I'm sure that I've seen one or two that were security related emails (in HTML naturally, even though I've signed up for the plain text variety) to their subscribers where in one paragraph they warn you about clicking on links provided in suspicious emails and a few paragraphs latter they are advertising a link where you can click on it to download some free Microsoft software like Silverlight or Security Essentials or Windows Defender. And often those links are redirected through some 3rd party mass email distribution company—just for that extra secure feeling I guess.<br />
<br />
<b><i>Argh!!! Please stop it already!</i></b> Don't the people composing these emails out realize that they are reinforcing the very practice that they claim to be trying to educate users to stop doing? Oh, the irony of it all. Are they trying to lampoon themselves?<br />
<br />
So please don't be telling me how we ought to require that regular users be better educated about security matters so as to make the rest of us all safer if this is the best that we have to offer in user education. Some have gone as far as suggesting that ordinary citizens be required to get some sort of license before they are allowed to connect to the Internet. Yea, right. Like we're doing such an excellent job educating folks now. This is like politicians talking out of both sides of their mouth at once. We can't have it both ways, so let's get our own house in order first before we start pointing out how clueless everyone else is. Perhaps, just perhaps, its been because we've been sending them mixed messages.<br />
<br />
Let me hear your rants and/or reactions on this topic and thanks for your time.<br />
-kevin<br />
_________________<br />
<a name="stop-fn1">1.</a> Eye candy is <i>way</i> more important than security, because after all, who <i>wouldn't</i> leave their bank or broker if they didn't send out slick looking emails. Sigh...Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-29039992672996814062011-04-03T19:16:00.000-04:002011-04-03T19:16:19.744-04:00Mobile Devices: Are We Repeating History?<style type="text/css">
p { margin-top: 0.08in; margin-bottom: 0.08in; background: none repeat scroll 0% 0% transparent; }a:link { }
</style> <br />
<div align="CENTER" style="color: red; margin: 0in 0.5in;"><i>"Those who cannot remember the past are condemned to repeat it."</i> – George Santayana</div><div style="margin-bottom: 0in; margin-top: 0in;"><br />
</div><div style="margin-top: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">During the past month or so, I have moved into the “modern” era. I stopped using my 3 year old cell phone and started using a smart phone (Droid X). During the same time, I also purchased a <a href="http://www.barnesandnoble.com/nookcolor/index.asp">Barnes & Noble NookColor</a> eBook reader. Of course, being the security geek that I am, I immediately rooted</span></span><sup><span style="font-style: normal;"><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543#rh-fn1"><span style="font-weight: normal;">1</span></a></span></sup><span style="font-style: normal;"><span style="font-weight: normal;"> each of them to see what makes them tick as well as to make them more useful to me. Here are my initial security thoughts on this technology.</span></span><br />
<span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></div><div style="margin-top: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">Since both of these mobile devices are Android based, I can't speak with any degree of experience for other devices based on Apple's iOS or Microsoft Windows, but I would be surprised if things are that much different there either.</span></span></div><p><div style="color: yellow; margin-top: 0in;"><b><span style="font-style: italic;">History 101</span></b></div><div style="margin-top: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">In the early days of personal computing (and I'm collectively including </span></span><span style="font-weight: normal;">all </span><span style="font-style: normal;"><span style="font-weight: normal;">personal computers here, everything from Commodore 64 to Apple Macs, not just IBM PCs and their clones), none of these were originally designed with the concept of really being multi-user devices. Instead, it was assumed that either these early computers were either used only by a single person, or perhaps shared by the entire family with the assumption that there was no need of privacy or separation.</span></span><br />
<span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">Jump ahead about ten years, to the mid-1990s, and by then all the major vendors who were left (basically Microsoft and Apple) realized that this was the wrong assumption. So, for example, we see in Windows 95, the concept of a login screen (if one desired to use it), but under the hood, still no real integrated multi-user concept—a legacy that lived on until Windows XP. However, by then, the “damage” was done; parents had been “trained” that only a single login was required and for their children's PCs, they would just provide one login for their son or daughter. More often than not, that user account was one that had an administrator role.</span></span></i></div><p><div style="color: yellow; margin-top: 0in;"><b><span style="font-style: italic;">Lessons from the Past</span></b></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">The result, at least in most of the households that I observed, was chaos. Teenagers—who were frequently more technically adept than their parents, but lacking the general wisdom of adults—would download and install various malware-infected games, P2P software, etc. In short, personal computing platforms of many households were so mired in malware as to be rendered completely unusable.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">During the ten year period from about 1995 until up 2005, I assisted numerous friends with malware removal. More often than not, the attack vector was from something that a teenage son or daughter deliberately had downloaded to share music, pictures, or videos with their friends. (Note: nothing magical happened in 2005, other than I switched almost exclusively to using Linux so I had an “excuse” when someone asked for assistance with the latest Windows OS. In reality, I simply got wise enough to graciously say “no, I won't fix your computer” without friends taking offense. I wonder if surgeons are ever asked to perform free appendectomies by their friends. ;-)</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">But I think that the lesson learned by Microsoft and Apple was that compartmentalizing user data by user accounts was important, not only from a privacy perspective, but also from a security stability perspective. Of course, Linux growing out of UNIX roots had the multi-user concept from the start, but in a few cases even some of the Linux distros attempted to “dumb things down” a bit (e.g., via automated login) to appeal more to the casual users more familiar with Windows and MacOS environments.</span></span></i></div><p><div style="color: yellow; margin-top: 0in;"><b><span style="font-style: italic;">The Present</span></b></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">Flash forward to the present. We see mobile devices—namely smart phones and tablet PCs—that are being treated by the manufactures / distributors as </span></span></i><i><i><span style="font-weight: normal;">single user devices</span></i></i><i><span style="font-style: normal;"><span style="font-weight: normal;">.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">From a vendor perspective, this makes sense...there simply is less code to develop. From a user interface, it simplifies things there as well. But remember this single user approach originally seemed acceptable, for a short while at least, for OS vendors of early personal computers. They too approached computing platforms from a single user approach, only later to realize it proving detrimental. In the long term, going back and having to redo things soon after they've originally been implemented improperly always is a disability because of the dreaded “backward compatibility curse” and the additional complexity required for the retrofit.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">So a fair question to ask is “Is industry missing the mark with their assumption that these mobile devices will be exclusively used by a single individual?”. I'm willing to concede that for cell phones this may be a reasonable assumption, but based on how I've seen tablet PCs being used, I'd have to say the answer there is definitive “yes, vendors have missed the mark”. My son has already used my rooted NookColor tablet and I have a friend whose entire family shares their iPad. I don't see it being that much different in other families unless those families are sufficiently well-to-do to by each of the family members their own tablet device.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">The code used to root the NookColor seems to be influenced heavily by the Motorola Xoom system, so maybe I'm jumping to conclusions here. But for the both the original B&N NookColor as well as the rooted versions, there is no concept of access by different user accounts. The closest I see to a login screen for either is a 4-digit security code and once the device is unlocked, the user is able to do anything.</span></span></i><i><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543#rh-fn2"><sup><span style="font-style: normal;"><span style="font-weight: normal;">2</span></span></sup></a></i><i><span style="font-style: normal;"><span style="font-weight: normal;"> According to may friend, a similar situation exists with the iPad. It only supports one user account that connects to Apple's iTunes.</span></span></i></div><p><div style="color: yellow; margin-top: 0in;"><b><span style="font-style: italic;">Repeating History</span></b></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">You might ask, why is sharing a tablet PC with your family members a problem? Well, if you are willing to risk the security of your tablet PC and all the data on it to your teenage son or daughter, it isn't. (Not to mention that a compromised tablet PC may also provide a jumping off point inside your router's firewall that allows easier access to your other computers and their data.) Most kids that I know are not too discriminating about what they might download. It's doubtful that most of them would even take the time to </span></span></i><i><i><span style="font-weight: normal;">read</span></i></i><i><span style="font-style: normal;"><span style="font-weight: normal;"> through a list of permissions that an Android app is requesting let alone fully understand the implications involved. While Apple and Google do their best to prevent malware and spyware on from their respective official download sites, there are other sites that one can download iPad and Android apps from might not do this at all. And while you may never visit these sites, your kids might. (You might argue that this is not possible if your device has not been jail-breaked or rooted, and you may be correct. But this is an almost trivially accomplished feat well within the technical skills of today's youth. Furthermore, returning it to the stock OS—</span></span></i><i><i><span style="font-weight: normal;">after</span></i></i><i><span style="font-style: normal;"><span style="font-weight: normal;"> one downloads and installs that favorite free warez version of Angry Birds—is also fairly easy.)</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">The question is why does it have to be this way? Android OS not only already supports multiple user ids, but is uses them so that each of the different apps runs using a different user account. (I can't speak as to iOS as I've not yet researched it. As for Windows OS for mobile devices, I suspect that the stock OS also supports multiple user accounts under the hood although it may not support multiple end user accounts.)</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">If we have learned anything over the past 30 years, it is that there are inherent dangers associated with having a user run with a single, all-powerful account. At the minimum, there should be two accounts supported and presented to end users—one an administrative account used only for installing, upgrading, and deleting apps and other systems management functions, and one a limited-user account that has no special privileges at all. Ideally, for mobile devices likely to be shared, there also ought to be separate limited user accounts at as well. With multiple limited end user accounts you won't have situations where 13 year old Bobbie makes unauthorized posts of embarrassing pictures to his 16 year old sister's Facebook page. The only alternative that I see is for families </span></span></i><i><i><span style="font-weight: normal;">not</span></i></i><i><span style="font-style: normal;"><span style="font-weight: normal;"> to use the automated sign-on into social networking sites. (But convenience wins over security almost every time; recall McGraw's and Felten's “<a href="http://en.wikipedia.org/wiki/Dancing_pigs">dancing pigs</a>” comment—well, at least until Bobbie posts a picture of his sister wearing her ratty bathrobe, hair up in curlers, and face covered in acne cream. ;-)</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">Even more importantly, consider the idyllic vision that some mobile device moguls seem to dream about where your mobile device (usually cell phone, but perhaps small tablets as well) contains all your credit information enabling you to make automatic payments using with your mobile device through the use of a <a href="http://en.wikipedia.org/wiki/Near_field_communication">Near Field Communications</a> (NFC) chip. We need multiple end user accounts even more there. Surely one doesn't want your children to have access to use Dad's credit cards simply by waving a mobile device near the POS device. True, one could protect such electronic payments with a PIN as well, but most would find this an inconvenience and would either likely disable it or choose the same PIN that they use for the device itself to avoid committing yet another PIN / password to memory.</span></span></i></div><p><div style="color: yellow; margin-top: 0in;"><b><span style="font-style: italic;">The Not-Too-Distant Future</span></b></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">The good news is, I think manufacturers and sponsors of mobile devices still have time to get this right. Currently, I don't think that the target is lucrative enough to entice all the malware writers to switch gears and immediately begin targeting mobile devices rather than PCs and Macs. I predict this will change within a few years, especially if the vision of making e-payments from mobile devices comes sooner rather than later. So if mobile device manufacturers are going to do something, the time is short.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">The bad news is there is absolutely no consumer outcry to entice this to happen. Neither do I see anyone in the security community discussing it either. So perhaps it never will change ha until consumers have suitably suffered enough from resulting security breaches to get angry. Until then, we will have to make do with a patchwork of AV and other bolt-on security solutions.</span></span></i><br />
<i><span style="font-style: normal;"><span style="font-weight: normal;"><br />
<p></span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">So, the question is what should we do as security professionals? </span></span></i><i><i><span style="font-weight: normal;">Should</span></i></i><i><span style="font-style: normal;"><span style="font-weight: normal;"> we call this out as an issue, or am I just a misguided old fool telling people that the sky is falling?</span></span></i><i><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543#rh-fn3"><sup><span style="font-style: normal;"><span style="font-weight: normal;">3</span></span></sup></a></i></div><div style="margin-top: 0in;"><p><i><span style="font-style: normal;"><span style="font-weight: normal;">You decide and let me know what you think.</span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">-kevin</span></span></i></div><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;">_____________</span></span></i></div><ol><li><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;"><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543" name="rh-fn1">No hardware was harmed in the process. “Rooting” on an Android OS is similar in concept to “jail-breaking” an Apple iOS device. In Android OS, it leads to obtaining superuser access, thus the term “rooting”. Now where did I put that “I void warranties” T-shirt?</a></span></span></i></div></li>
<li><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;"><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543" name="rh-fn2">Note that there is special software from the Google Apps Marketplace from at least one AV vendor that allows you to password restrict specific applications, but if anything, this seems to bear testimony to the fact that someone else realizes there are potential security issues here as well.</a></span></span></i></div></li>
<li><div style="margin-top: 0in;"><i><span style="font-style: normal;"><span style="font-weight: normal;"><a href="http://www.blogger.com/post-create.g?blogID=8976089095047007543" name="rh-fn3">Note that these points are not necessarily mutually exclusive. It could be both/and. I frequently tell my son that I used to be young and foolish, but now, I'm old...and foolish.</a></span></span></i></div></li>
</ol>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com1tag:blogger.com,1999:blog-8976089095047007543.post-89924894837916834042011-03-30T17:54:00.001-04:002011-03-30T17:54:47.675-04:00Signs of Broken Authentication (Part 4)<style type="text/css">
p { margin-bottom: 0.08in; }h3 { margin-bottom: 0.08in; }h4 { margin-top: 0in; margin-bottom: 0in; page-break-after: auto; }h4.western { font-family: "Thorndale AMT",serif; font-size: 10pt; font-style: italic; }h4.cjk { font-family: "Albany AMT"; font-size: 8pt; font-style: italic; }h4.ctl { font-family: "Albany AMT"; font-size: 10pt; font-style: italic; }a:link { }
</style> <br />
<div style="margin-bottom: 0in;">So today's post is the last of the series of “Six Signs of Broken Authentication”.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">So let's review. Thus far, we have covered the following red flags:</div><ol><li><div style="margin-bottom: 0in;">Restricting the maximum length of a password.</div></li>
<li><div style="margin-bottom: 0in;">Restricting the set of characters you are allowed to use in your password.</div></li>
<li><div style="margin-bottom: 0in;">Mapping all your password characters to digits 0 through 9 so you may enter it via an ordinary telephone keypad.</div></li>
<li><div style="margin-bottom: 0in;">No password lockout.</div></li>
</ol><div style="margin-bottom: 0in;">Today, we will be covering the last two warning signs of broken authentication:</div><ol start="5"><li><div style="margin-bottom: 0in;">Missing or inappropriate use of SSL/TLS</div></li>
<li><div style="margin-bottom: 0in;">Password reset via poorly implemented “security questions”</div></li>
</ol><h3 style="color: red; font-weight: normal;"><i>Red Flag #5: Missing or Inappropriate use of SSL/TLS</i></h3><div style="margin-bottom: 0in;">You go to a web site and you notice that that login page is not using https (i.e., HTTP over “Secure Socket Layer” (SSL) or “Transport Layer Security” (TLS)). Or for those of who've been trained to look to see if the little lock is showing, you notice that it is conspicuously absent.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Of course, there are the obvious signs and—depending on which browser you are using, your particular browser configurations, and which browser plug-ins you may be using—the not so obvious signs that things are awry.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Let's start with the more visible ones and then we will follow up with the less obvious ones.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Note: In the rest of this ensuing discussion I will be using the term “SSL” to refer to both SSLv3 and TLSv1 unless otherwise specified. Also note that this list is not complete, but is intended to cover the most common and egregious issues. Post a reply to this blog to provide your feedback if your favorite one is missing.</div><div style="margin-bottom: 0in;"><br />
</div><h4 class="western" style="color: yellow;">The Web Site's Login Form Is Not Using SSL/TLS At All</h4>Setting up an SSL site when the only thing that needs protecting is users' passwords seems like such a waste of time to many IT teams. And sure, there's always the argument to be made that if the rest of the site isn't using SSL at all, is there really that much to be gained? (But, that's probably not the right question to be asking to begin with; the more appropriate question is “what is your threat model?”. Only after answering that can you answer whether the rest of your site should be using SSL/TLS or not.)<br />
One might think this is an uncommon practice and that major sites would never make such a <i>faus pax</i>, but until rather recently, the general login pages for Facebook did <i><b>not</b></i> default to use SSL.<br />
Now this practice might be OK in the world predating open Wi-Fi hotspots, but nowadays it is trivial for someone to snoop the ether for user name / password combinations not transported over SSL. That combined with the fact that the average netizen (certainly <i>not</i> you astute folks reading this blog! :) has a tendency to reuse a small handful of passwords makes capturing someone password a potentially valuable exercise to those ready to exploit such things.<br />
So while Gene Spafford's advice of “Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench” may have been appropriate advice when LANs were over traditional Ethernet, with the advent of open Wi-Fi hotspots such advice is outdated at best.<br />
<br />
<h4 class="western" style="color: yellow;">The Web Site's Login Form Uses SSL, But the Form Is Displayed Using http</h4>Today, it seems to be in vogue for web sites to have a link to the login form directly off their main page. This seems to be especially popular with telecommunications companies and their residential “My Account” portals; witness <a href="http://www.qwest.com/">Qwest</a>, <a href="http://www.verizonwireless.com/b2c/index.html">Verizon</a>, and <a href="http://www.att.com/">AT&T</a>.<br />
Now, while these sites do post the login requests to their respective servers using https, the fact that the login forms are displayed on an non-https page is somewhat disturbing.<br />
The issue is that a man-in-the-middle (MITM) attacker can mirror the main site, but alter the login page so that the authentication is redirected to a rogue site used to capture your password. (Depending on their sophistication, some may pass through your password to the actual intended site, while others may simply return a “login failed” indication.) Often this attack occurs using a technique known as “<a href="http://en.wikipedia.org/wiki/Pharming">pharming</a>”, whereby an attacker—usually placed conveniently near an open Wi-Fi—hijacks DNS requests to a web site. If it is one they have set up a mirrored rogue site for, the DNS request returns something with a similar name. The attacker may also attempt to obfuscate the URL by various means in hope that their social engineering attack won't be noticed.<br />
<u>What you, as users, can do to make things safer</u>: Most of these sites will redirect you to a more bare bones, all SSL, login form if you simply click on their “Submit” or “Login” buttons from the main (non-SSL) containing page. For example, if you were to click on the “Sign In” button from <a href="http://www.qwest.com/">Qwest's main page</a>, you will be redirected to <a href="https://www.qwest.com/MasterWebPortal/freeRange/Login_validateUserLoginAction.action">https://www.qwest.com/MasterWebPortal/freeRange/Login_validateUserLoginAction.action</a>, which of course is using SSL. From there, you can verify the certificate, in particular that it belongs to whom you think it should, to make sure this is the site that you intended to visit.<br />
<br />
<h4 class="western" style="color: yellow;">The Web Site's Login Form Uses SSL, But the Form Is Using Components Not Using SSL</h4>This is similar to, but in general not quite as bad, as the above case. Here there is some component of the login page that is not using SSL whereas the rest of the page is. Generally, this is caused by the site using vanilla http to load an image, some JavaScript, or a cascading style sheet. Also, generally most modern browsers will provide some sort of warning for this (although many people have disabled this warning because they see it so often).<br />
In theory, such a thing can still be exploited by a MITM attack, although the difficulty of this varies greatly depending on what the pages are that are loading over vanilla http, whether that page is cached in a proxy somewhere, and many other variables. This attack is usually much more difficult than simple DNS hijacking. If a proxy cache is involved and the specific page is cacheable, then sometimes a proxy cache-poisoning approach will work for an attacker. (This can be accomplished in many different different ways, such as <a href="http://www.owasp.org/index.php/Response_Splitting">HTTP response splitting</a>, <a href="http://www.owasp.org/index.php/HTTP_Request_Smuggling">HTTP request smuggling</a>, <a href="http://en.wikipedia.org/wiki/DNS_cache_poisoning">DNS cache poisoning</a>, etc. The details are beyond the scope of this blog post.)<br />
Generally, if you see this warning in your browser, you can either choose to heed the warning or take your chances. If you decide to take your chances, you might at least wish to explore why the warning is being issued. From Firefox, you can do this by right-clicking on a page and selecting 'View Page Info'. From the 'Page Info' dialog box, select 'Media'. In the top section, right click and choose 'Select All', followed by right click 'Copy'. Then paste the copied addresses into a text editor and search through them. But caution: unless you understand HTTP, HTML, and web application security, you are are better off just reporting this situation to the web master. There be dragons in these waters, so tread carefully.<br />
<br />
<h4 class="western" style="color: yellow;">The Web Site's Login Form Uses GET Rather Than POST</h4>The default action for HTML forms is to make an HTTP POST, but occasionally a web developer will use an HTTP GET for the HTML form's “action”. While both work, a GET will pass the form parameters as query parameters. HTTP web servers generally log all GET requests including any query parameters are part of the requested URL. In such cases, your user name and password likely will end up in someone's log files. Furthermore, by default these parameters will also go into your browser's history, so if you are using a web browser from a kiosk (probably a bad idea in in the first place) your user name and password ends up there as well.<br />
<br />
<h4 class="western" style="color: yellow;">The Web Site Uses a Dubious Certificate</h4>[Note: This subsection could probably be called “Why Certificates and Public Key Infrastructure Do Not Work”, but that's a topic for another day. If interested, Google what CS professor and cryptographer Peter Gutmann has written about the subject.]<br />
When a web site is configured to use SSL, the web server will be configured to use an X.509 server-side certificate. Often these certificates are not correctly configured. Generally, these misconfigurations will cause a warning in your browser. (I will not attempt to describe the wording warnings here because they vary greatly depending on which browser you are using and even with browser version. However, the browser developers put these warnings there for a reason and you should generally heed them when they advise you to “run away”, the law of “<a href="http://en.wikipedia.org/wiki/Dancing_pigs">dancing pigs</a>” not withstanding.)<br />
Here are some of the more common certificate-related problems.<br />
<ol type="a"><li>Self-signed Certificate or Certificate Not Signed by Trusted CA<br />
Your web browser has several dozen “trusted” (by the vendor of your browser, not necessarily by you) certificates issued by various Certificate Authorities (CAs). An SSL server certificate issued by one of these trusted CAs will be trusted by your browser because it was properly signed by a trusted CA. But occasionally, in an attempt to save money (or because of general cluelessness of the IT staff administering the web site) a web site will use a self-signed (i.e., self-issued) certificate instead of one signed by a trusted CA. (A variant of this is that they will sign a certificate by one of their internal CAs that your browser does not trust.) In either case, your browser should issue a warning if you have not disabled this specific warning. (If it doesn't, it's time to switch to a different browser.)<br />
The problem here is that for self-signed certificates, anyone can create one, so unless you can trust this <i>specific</i> self-signed certificate (for example, by verifying beforehand and out-of-band that this specific certificate's fingerprint from a trustworthy source), a MITM attack is again possible. (Not trivial mind you, but certainly possible.) If you must use such a site, you are strongly advised to choose a unique password for it. And if that site happens to be your bank..., well, then I'd advise you to find a new bank, at least until their IT staff gets it fixed.<br />
</li>
<li>Certificate's CN Does Not Match Host Name of Web Site for Login Page<br />
Earlier, I mentioned Eugene Spafford's quote about how using encryption on the Internet overkill. This never meant that SSL was useless. Indeed, in pre-open Wi-Fi times, arguably the most important purpose of SSL was the server-side authentication that your browser performed as it made an SSL connection. This server-side authentication consists of validating that the digital signature on the SSL server-side certificate is valid and was signed by one of your browser's trusted CAs as well as ensuring that the host name on the SSL server certificate matches the host name that your browser believes that it is trying to connect to. To do this, your browser compares the host name portion of the URL it is visiting to the 'CN' (Common Name) on the SSL server-side certificate. If there is a mismatch, your browser will issue a warning.<br />
This server-side authentication is important in preventing simple phishing attacks. Without this check, an attacker could redirect your browser to a rogue site that (say) looks like your bank's site and get you to authenticate to their site instead, thereby handing over your bank account to them. So, as users, don't get into the habit of just accepting mismatched host names on certificates or you will be setting up yourself for future phishing attacks.<br />
</li>
<li>Site Is Using A Revoked Certificate<br />
Either a CA or the owner a certificate may “revoke” a certificate because they believe that the private key associated with the public key on the certificate has been compromised. So chances are, if you encounter a revoked certificate on a web site, you are dealing with a rogue web site set up to mimic the real web site's appearance. Stay away and notify those running the site that you were originally intending to visit as it is possible (though unlikely) that the site's legitimate owner has accidentally put the revoked certificate back up.<br />
</li>
<li>Certificate Supports No Revocation Checking<br />
Your browser relies on hints on the SSL server certificate or the signed CA's root certificate for details whether or not a certificate has been revoked. Your browser does this by examining these certificates for certain optional extensions which instruct it how and where to check for revoked certificates. (The details are again beyond this particular blog post.) Furthermore, depending on your browser and its version, this revocation checking may or may not be automatically enabled in your browser. If it isn't enabled, your browser generally won't be able to detect revoked certificates with the exception of those revoked certificates built into the browser itself. (Check your browser's documentation for details of how to enable revocation checking for your specific browser version.)<br />
However, occasionally, a browser will use a cheap(er) CA and that CA might not support revocation checking. (I suspect most CAs do; perhaps even all, if they support X.509v3 certificates at all. But it certainly is a possibility. I'll leave that as an exercise for the users of all the browsers to check if all your browser's built-in CAs support revocation checking. If any of the CAs have issued version 1 X.509 root certificates, these probably do not support revocation checking because they do not support certificate extensions.) Also, I cannot speak as to which, if any, browsers would issue a warning for such CAs. If you know, please post a comment to educate us.<br />
</li>
</ol>Finally, you will notice that I did <i><b>not</b></i> include “Expired Certificate” in this list of dubious certificates. I would describe that as a “pink” flag, not a red flag. The primary reason for CAs expiring certificates to begin with is to ensure a continued revenue stream. Yes, there are some valid arguments for expiring certificates, but assuming that one takes reasonable precautions to protect the associated private keys and one is using a reasonably sized public/private key size (<span style="font-family: Albany AMT,sans-serif;">≥</span> 1024-bits for RSA; sorry NIST!), an expiration period of 3 to 5 years <i>should</i> <i>be</i> very reasonable. But as I don't really want to get into the politics of CAs, I am not going to belabor this point. If a certificate has been expired for several years, it probably is a red flag, indicating that the IT staff is either oblivious or apathetic (as this almost always generates a huge warning in almost every browser available). Of course it might also indicate that the site is as popular as a skunk sniffing contest and no one other than the IT staff actually visit their site. ;-)<br />
<h3 style="color: red; font-weight: normal;"><i>Red Flag #6: Password Reset via Poorly Implemented “Security Questions”</i></h3><div style="margin-bottom: 0in;">So is that is? Anything else? Of course. I've saved the best (or would that be the worst) for last? The last authentication red flag on my list of authentication e-v-i-l-s is sites that allow you to reset your passwords based your answer to the ubiquitous “security question”. </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">You know the ones... They ask you to chose a “security” question such as:</div><ul><li><div style="margin-bottom: 0in;">What is your favorite sports team?</div></li>
<li><div style="margin-bottom: 0in;">Who is your favorite author?</div></li>
<li><div style="margin-bottom: 0in;">What was the name of the school you attended in first grade?</div></li>
<li><div style="margin-bottom: 0in;">What was your first car?</div></li>
<li><div style="margin-bottom: 0in;">Where is your favorite vacation spot?</div></li>
</ul><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">etc., and then to provide your answer that they check when you need your password reset.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;">Depending on whose figures you quote, one hears of help desk assisted password resets running between $50 to $150 per call. Also one hears figures that between 20-40% of all help desk calls are to reset passwords. So given such costs, it is not surprising that companies have decided to automate their password resets. Unfortunately, since most companies don't have a second form of authentication that they support for all of their customers, their self-help mechanism for resetting passwords is often demoted to using “security” questions. Since any more, this practice includes almost every web site authenticating users with a password, one can't use this criteria alone to classify poor security practice. So instead, we will try provide insight on how to recognize the bad from the worse.</span></div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;">We will take a three pronged approach in discussing this topic:</span></div><ol type="i"><li><div style="margin-bottom: 0in;"><span style="font-style: normal;">How to recognize bad practice from the worst practice (aimed at both users and developers)</span></div></li>
<li><div style="margin-bottom: 0in;"><span style="font-style: normal;">Offer suggestions of how users can make the best of a bad practice</span></div></li>
<li><div style="margin-bottom: 0in;"><span style="font-style: normal;">Offer suggestions of how developers can better implement password resets</span></div></li>
</ol><div style="margin-bottom: 0in;"><br />
</div><h4 class="western" style="color: yellow;"><i><span style="font-style: normal;">Recognizing Bad Practice</span></i></h4><div style="margin-bottom: 0in;"><span style="font-style: normal;">First, as noted in <a href="http://www.goodsecurityquestions.com/">Good Security Questions</a>,</span></div><div style="color: #9fc5e8; margin-bottom: 0in;"><br />
</div><div style="color: #9fc5e8; margin-bottom: 0in; margin-left: 0.49in; margin-right: 0.92in;"><span style="color: #6fa8dc;">“</span><span style="color: #6fa8dc; font-style: normal;">... there really are NO GOOD security questions; only fair or bad questions. 'Good' gives the impression that these questions are acceptable and protect the user. The reality is, security questions present an opportunity for breach and even the best security questions are not good enough to screen out all attacks. There is a trade-off; self-service vs. security risks.”</span></div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">So, from an external perspective, how do we recognize the fair questions from the bad questions? GoodSecurityQuestions.com distinguishes four criteria. That site states that a “good” (relatively speaking) security question is one whose answer will have these four characteristics:</div><ol><li><div style="margin-bottom: 0in;">cannot be easily guessed or researched (safe),</div></li>
<li><div style="margin-bottom: 0in;">doesn't change over time (stable),</div></li>
<li><div style="margin-bottom: 0in;">is memorable,</div></li>
<li><div style="margin-bottom: 0in;">is definitive or simple.</div></li>
</ol><div style="margin-bottom: 0in;">While some sites are getting better at formulating canned questions, few meet all four of these above characteristics. Most web sites still only have questions that lead their audience to very predictable one or two word answers. On the plus side though, more and more sites now are now allowing their users to pose your their own questions (such as “What is my password?” ;-) and answers.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">The password reset process typically works by a user starting out by clicking on a “Forgot Password” link. Upon clicking on this the link, the user will be prompted for their user name. Once this is done, most sites prompt you to answer these security question(s) correctly (sometimes you will need to answer multiple questions correctly). After you provide the correct answer(s) to the posed question(s), the web site will send you an email to your email address that you used to register with that web site. That email message will typically contain either a temporary password that you can use at the main login screen or a special link—often only valid for a short amount of time, such as a few hours—and that link allows you to reset your forgotten password. The better designed systems will send you a special link to your email address on record that will allow you to answer your security question(s), and <i>only then—</i><span style="font-style: normal;">if</span><i> </i>you answer them correctly—will allow you to proceed immediately to reset your password. This has the advantage of not allowing an adversary to see your specific questions first in order to research them.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">However, a few of the sites still allow you to reset your password directly just by answering your security question directly—no email or SMS text, etc. side-channel is involved. A few others have the poor practice of displaying the email address that the new temporary password is being sent do. If their site does the latter, that opens up possible social engineering exploits to their help desk—such as an attacker claiming that they no longer use <i>that </i><span style="font-style: normal;">email address and could the help desk personnel please change it to this </span><i>other </i><span style="font-style: normal;">email address that they now use. Then all the attacker need to is to guess the answer(s) to your security question(s) correctly.</span></div><div style="margin-bottom: 0in;"><br />
</div><h4 class="western"></h4><h4 class="western" style="color: yellow;"><span style="font-style: normal;"><i>Advice</i> <i>For</i> <i>Users</i></span></h4><div style="margin-bottom: 0in;">Fortunately, many ordinary citizens <i>are </i><span style="font-style: normal;">getting smarter with this, and when posed with some canned question such as “What was the name of the school you attended in first grade?” will answer “spaghetti”. (In truth [seriously], “spaghetti” seems to be a favorite answer of these questions, so you may want to start trying something else, like perhaps “linguine”. :)</span></div><div style="font-style: normal; margin-bottom: 0in;"><br />
</div><div style="font-style: normal; margin-bottom: 0in;">Unfortunately, many people don't understand how answer these questions realistically can work against them. For when faced with answering the security question “What was your first car?”, they might answer “1969 Plymouth Satellite” (or in my case, that would be “1909 Ford Model T”...JK; actually it was a “Paleolithic Era Flintstones Mobile”) . But seriously, which is easier for an attacker to do? To guess your 8 character password (assuming that your password isn't “password” :) or to guess the answer to your security question? Generally, it's the latter. It's not to hard for me to write a small program that will guess all reasonable permutations of year, make, and model of cars or all the sports teams or whatever your security question happens to be. After all, how many possible “favorite sports teams” are there? Maybe thousands at the most. Developers could go a long way to help out here by not permitting unlimited attempts at guessing the answer to these security questions, but they seldom do. So it's up to you—as users—to chose some technique to use to defeat this avenue of compromising your web site user account. Pick some standard technique that you remember. For example, maybe add a common preamble to the all your security answers, like “xyzzy-” or “plugh:” or “meh/” or whatever you want. Or you can always answer all such security questions by some common (but secret) pass phrase, such as “I think that all politicians should serve a term in office and then a term in jail.”, etc. But because there is no common recognized “best practice” for password resets, it is going to be a long time until the development community catches up. But then again, “best practice” for a “poor practice” is an oxymoron. As noted from GoodSecurityQuestions.com earlier, there are no “good” security questions, only fair or bad questions. So it is up to you, as users, to protect yourself until something better comes along.</div><div style="font-style: normal; margin-bottom: 0in;"><br />
</div><div style="font-style: normal; margin-bottom: 0in;">Lastly, if you, as users, are able to define your own security question / answer, that can provide a higher level of security than stock questions, assuming that you give your question some thought beforehand. I often advise friends to select a question that might be somewhat embarrassing to them if it were discovered. (Although, use with caution; as users, you can never assume that the developers are actually encrypting the questions and answers.) So, for example, a question like “What was the nick name that bullies used to taunt me with in grade school?” or “What is the name of the girl that I had a secret crush on in ninth grade?” might be appropriate, whereas a question such as “How much money have I embezzled from my last employer?”, not so good. Common sense should prevail here.</div><div style="font-style: normal; margin-bottom: 0in;"><br />
</div><h4 class="western" style="color: yellow; font-style: normal;"><i>Advice For Developers</i></h4><span style="font-style: normal;">There is no consensus for what constitutes “best practice” for password resets using security questions / answers. Most likely, this is in part, because most security experts recognize that passwords are a weak form of authentication themselves and these password reset techniques are even weaker. But that said, from a pragmatic perspective—for the moment at least—we need to play the cards we are dealt.</span><br />
<span style="font-style: normal;">There is evidence that the security industry is starting to pay attention to this issue. For instance, FishNet Security's Dave Ferguson published a <a href="http://www.fishnetsecurity.com/Resource_/PageResource/White_Papers/FishNetSecurity_SecureForgotPassword.pdf">white paper</a> on this in 2010 as well as participating in a recent <a href="http://www.owasp.org/download/jmanico/owasp_podcast_83.mp3">OWASP Podcast</a> on the subject. Based on Ferguson's, OWASP has started on a “<a href="http://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet">Forgot Password Cheat Sheet</a>” (which still needs a lot of work, but its an extraordinary start by Dave Ferguson and Jim Manico). [NOTE: The OWASP “cheat sheet” page is also a bit misnamed as it assumes that the </span><i>only </i><span style="font-style: normal;">mechanism to reset passwords is via security questions / answers; if a site were using multi-factor authentication, it probably would be better to involve those other authentication factors in the process, but admittedly, outside the banking / finance industry and the military, multi-factor authentication is a rare practice.]</span><br />
<span style="font-style: normal;">At the risk of repeating a lot of what is already spelled out in the OWASP Forgot Password Cheat Sheet, here is what I would advise. (I hope to get these comments folded into the cheat sheet in the not too distant future.)</span><br />
<span style="font-style: normal;">Step 1) Gather Identity Data</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">Not much to disagree with here except for the obvious don't be collecting social security numbers unless it is something that your site actually has legitimate need for. The same goes for collecting only the last 4 digits of the SSN.</span></div><span style="font-style: normal;">Step 2) Selecting Initial Security Questions / Answers</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">The appropriate time to require that a user choose security the time the user initial registers with your site. Ideally, allow them to select their own security question. If this is not possible or desirable for some reason, then all them to select from a large set of <a href="http://www.goodsecurityquestions.com/examples.htm">well thought out security questions</a>. It is a good idea to require that the answer to any security question be longer than some minimal length (say, 8 to 10 characters), otherwise brute force attempts become likely. Finally, regarding the storage of the security questions / answers, questions should be encrypted (especially if they are chosen by the user) and any security questions should be hashed.</span></div><span style="font-style: normal;">Step 3) Send a Time-Limited Token Over a Side-Channel</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">This is </span><i>follows</i><span style="font-style: normal;"> the step to verify security questions in the OWASP cheat sheet, but I think it is better that it precedes this verification so as to not even allow the possibility of answering the security questions until one has received this out-of-band token. A random 8 character token is sufficient for SMS, but using something like <a href="http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/crypto/CryptoToken.html">ESAPI's CryptoToken</a> is better if generating an emailed link. Making this step precede the verification of the security questions increases the difficulty of a potential attacker researching the answers ahead of time (unless there are only a small set of possible questions). In addition, the token usage should ideally be restricted to a particular time duration after which it was created, say two hours or so.</span></div><span style="font-style: normal;">Step 4) Require User Return the Token</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">The user must return the token sent to her over a side-channel. So they must reply to the SMS text message or click on the link sent to their email address on record. Furthermore, they must do so within the required amount of time, otherwise the token becomes invalid.</span></div><span style="font-style: normal;">Step 5) Redirect the User to a Secure Page to Verify Security Question(s)</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">If the token is valid, take the user to a page (using SSL/TLS) where they can answer the questions. Do </span><span style="font-style: normal;"><b>not</b></span><span style="font-style: normal;"> allow the user to select which question they desire to answer (assuming that there are multiple question / answer pairs; ideally, make them correctly answer them all). Developers should also take precautions to limit the effectiveness of guessing. For example, using CAPTCHAs to reduce the success rate of automated attacks and allowing only (say) 5 consecutive failed attempts before temporarily locking out the account from further attempts to answer the security question. (A temporary lockout of a few minutes should be sufficient.) Finally, if the account is locked out because of N consecutive failed attempts, note it in a security audit log as well as notifying the user via email or an SMS text message.</span></div><span style="font-style: normal;">Step 6) Allow User to Change Password</span><br />
<div style="margin-left: 0.49in;"><span style="font-style: normal;">Once the user has correctly answered all required security questions (one or more, based on risk of potential lost of compromised password), allow the user to change the password. Then (optionally) redirect the user to the login page and require they re-login with their newly selected password. (Requiring that they re-enter their password again will reinforce their password in their mind. Of course, one must weigh this benefit against the inconvenience of the user experience.)</span></div><h3 style="color: red; font-weight: normal;"><i>Conclusion</i></h3><div style="font-style: normal; margin-bottom: 0in;">Well, that's enough ranting for this topic of warning signs of poorly implemented authentication practice. Tell me what are your thoughts on this. Have you seen any additional authentication red flags that I've forgotten? If so, let me know.</div><div style="font-style: normal; margin-bottom: 0in;"><br />
</div><div style="font-style: normal; margin-bottom: 0in;">Regards,</div><div style="font-style: normal; margin-bottom: 0in;">-kevin</div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-20064551282555966562011-03-19T11:26:00.000-04:002011-03-19T11:26:44.824-04:00Signs of Broken Authentication (Part 3)<style type="text/css">
p { margin-bottom: 0.08in; }h3 { margin-bottom: 0.08in; }a:link { }
</style> <br />
<div style="margin-bottom: 0in;">Today, I'll cover two more warning signs of broken authentication. But first, a word from our sponsor. (Warning: Shameless plug ahead.)</div><div style="margin-bottom: 0in;"><style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style> </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in; margin-left: 0.49in; margin-right: 0.61in;">Hey boys and girls! Do you have trouble thinking up new secure passwords for each new web site that you visit and have resorted to using passwords like “password1”, “password2”, “password3”, etc. because you know someone has told you to use different passwords for each site? Or you actually <i>have</i> secure passwords for your sites, but you have trouble remembering them? Well, look no further than Kevin Wall's <a href="https://sites.google.com/site/kevinwwall/Home/presentations/good-passwords" target="_new">Creating Good Passwords</a>. You'll be glad you did.</div><br />
<div style="margin-bottom: 0in;"></div><div style="margin-bottom: 0in;">We now return you to our regularly scheduled blog.</div><h3 style="color: red; font-weight: normal;"><i>Red Flag #3: Mapping Password Characters to Digits for Entry via Telephone Keypad</i></h3><div style="margin-bottom: 0in;">Another red flag which I have been running across much more frequently, are sites where they allow you to enter your password via a standard telephone key pad. You can check this if you are aware of sites that allow this. For instance, if your password was “JeHgr72w”, can you enter your password as “53447729” from the numeric keypad of your phone? If you can, you know that they are very likely mapping the characters in your password to digits 0 through 9 as arranged on a phone keypad. In such cases, this really dumbs down the entropy of your password—much worse than simply restricting which characters they allow you to use. If you run across such sites, I would advise you to choose the maximum length password that they allow. You would think that this would not be too common with sites that hand confidential data, but just last year, I discovered that a site handling our benefits weas doing this. I ran across it when I called their customer service desk and they asked me to confirm who I was via my password. When I asked how to enter alphabetic characters on a telephone key pad and they incredulously answered “for A, B, or C, enter 2; for D, E, or F, enter 3; etc.”. I should have been suspicious when their web site didn't allow me to choose any special characters at all. (See <a href="http://off-the-wall-security.blogspot.com/2011/03/signs-of-broken-authentication-part-2.html">Red Flag #2</a>.) So far, the sites where I've encountered have been limited to IVR systems associated with customer support. I guess one could argue that this is better than requesting sites requesting things like your SSN for verification of identity—especially in cases when they shouldn't be using your SSN any longer any longer (health care services come to mind). But the down side is that this site is dumbing down potentially strong passwords without the knowledge of their users, so consumers beware!</div><h3 style="color: red; font-weight: normal;"><i>Red Flag #4: No Account Lockout</i></h3><div style="margin-bottom: 0in;">Another authentication red flag are sites that support no account lockout after so many consecutive failed login attempts. If a web site allows someone to guess unlimited attempts of your password, you had better have a really strong password because there's nothing there to slow the attacker down.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">So what should developers do? Well, it should be obvious that what they <span style="font-style: normal;">do</span><i> NOT</i> want to do is to <i>permanently</i> lock out an user account. If you thought help desk calls about password resets were expensive before, just try implementing a permanent lockout. Some hacker will come along and hit your site with something that guesses user names (in general, not very difficult to guess especially if you have a list of first and last names for users) and just try N intentionally incorrect passwords for each user name (where N is the threshold for failed attempts where the site locks out the account). If you are the developer of such a site that implements this permanent lockout policy, lets just say for your sake, I hope you are away on vacation in the deep woods of Canada where no one can find you if / when this happens.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">So what's the correct approach? Well, the idea is to sufficiently slow down an attacker who is doing an off-line attack. So pick some reasonable number of password attempts (5 seems about right), and if there are (say) 5 <i>consecutive </i>failed login attempts for a specific user name, then <i><b>temporarily </b></i><span style="font-style: normal;"><span style="font-weight: normal;">lock out that user account for some short amount of time (between 5 to 10 minutes is good). On the password attempt, you should display an error message that says something like:</span></span></div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in; margin-left: 0.49in;"><span style="font-style: normal;"><span style="font-weight: normal;">You're user account has been temporarily locked out for </span></span><i><span style="font-weight: normal;">T</span></i><span style="font-style: normal;"><span style="font-weight: normal;"> minutes after </span></span><i><span style="font-weight: normal;">N</span></i><span style="font-style: normal;"><span style="font-weight: normal;"> consecutive failed attempts. Please try again in </span></span><i><span style="font-weight: normal;">T</span></i><span style="font-style: normal;"><span style="font-weight: normal;"> minutes.</span></span></div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">where </span></span><i><span style="font-weight: normal;">T</span></i><span style="font-style: normal;"><span style="font-weight: normal;"> and </span></span><i><span style="font-weight: normal;">N </span></i><span style="font-style: normal;"><span style="font-weight: normal;">are the lockout duration and failed attempt threshold respectively. A similar error message would be displayed if a login attempt was made while the account is temporarily locked out.</span></span></div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">Once a user successfully authenticates after an account had been temporarily locked out, it also a good idea to display a message that effectively gives notice to the user that this had happened and the time when it occurred. This helps the user know that someone else may have been trying to crack their account, and if so, they may wish to change their password as a result.</span></span></div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;"><span style="font-style: normal;"><b>POLICY NOTE</b></span><span style="font-style: normal;"><span style="font-weight: normal;">: If your company has a policy to not divulge failed whether a login attempt failed because the user name or password was incorrect (e.g.,”Login failed: Invalid user name or password” rather than “Login failed: Invalid user name” / “Login failed: Invalid password”), then you need to temporarily lock out even invalid user accounts! Otherwise, an attacker can use this account lockout information to discern whether or not a guessed user name is valid.</span></span></div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com1tag:blogger.com,1999:blog-8976089095047007543.post-36892112781577393192011-03-16T23:51:00.000-04:002011-03-16T23:51:20.435-04:00Builders vs. Breakers DichotomyI've just posted a reply to <a href="http://www.darkreading.com/blog/229300690/how-i-ve-become-one-with-the-rest-of-the-world.html">Marisa Fagan's Dark Reading blog</a>. Even though my reply is short (well, for me at least ;-). Marisa weighs in on the adversarial relationship between developers and security people. I've added my $.02 as to why that's not necessarily a bad thing as long as respect between the two roles is maintained. I am not going to repost it here. If you are interested, you can find it <a href="http://www.darkreading.com/blog/229300690/how-i-ve-become-one-with-the-rest-of-the-world.html?fmid=24708">here</a>.<br />
<br />
-kevinKevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-48275694545919288142011-03-15T00:15:00.000-04:002011-03-15T00:15:45.291-04:00Response to Mark Curphey's Blog “OWASP—Has It Reached a Tipping Point”<style type="text/css">
p { margin-bottom: 0.08in; }h3 { margin-bottom: 0.08in; }a:link { }
</style> <br />
<div style="margin-bottom: 0in;">Back on February 18, 2011, Mark Curphey, the original founder of OWASP, wrote a very <a href="http://www.curphey.com/2011/02/owasp-has-it-reached-a-tipping-point/">thought provoking blog</a> regarding the direction that OWASP seemed to be taking.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">And while I hadn't originally intended on commenting on it, <a href="http://lists.virus.org/securecoding-1103/msg00008.html">Rohit Sethi's post to the Secure Coding mailing list</a>, caused me to rethink this. (Pardon me for not addressing everything in the sequential order that Mark brings them up.)</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Curphey's blog refers to tweets coming from the OWASP Summit in Portugal as the singular event that precipitated his reflections about OWASP's directions. He points out the tweet that caught his eye was one that where John Wilander tweeted that an OWASP Summit attendee remarked on stage that “<a href="http://twitter.com/johnwilander/status/35037398362492928">Developers don't know shit about security</a>”. Curphey refers to John Wilander's post “Security People vs. Developers” which Wilander blogged about 5 days after his initial Twitter post. Wilander also has a very thoughtful post. In Wilander's blog, he says he latter added the comment “Well, I got news. You don't know shit about development”, obviously in reference to the OWASP Summit attendee who originally made the comment.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Well, I'm going to respond in part to both Curphey's and Wilander's blog posts, and perhaps an a little (in)sanity to the mix. Why? Well, for one, I have extensive experience in <i><b>both </b></i><span style="font-style: normal;"><span style="font-weight: normal;">development and security. I've been a developer for 30+ years, and been involved with application security for about 12 years. So, IMNSHO, I know “shit” about <i>both</i> developer and security and it is that frame of reference that I am posting this.</span></span></div><h3 style="font-weight: normal;"><span style="color: yellow;"><i>So Who Is Right?</i></span></h3><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> So let's start out trying to answer the question, who is correct here? Which if any of these are the correct point of view:</div><ul><li><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> Developers don't know jack about security.</div></li>
<li><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> Security people don't know jack about development.</div></li>
</ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> Or perhaps, let's go even further and contemplate:</div><ul><li><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> Developers don't know squat about development.</div></li>
<li><div style="font-style: normal; font-weight: normal; margin-bottom: 0in;"> Security professionals don't know squat about security.</div></li>
</ul><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">Well, I could answer “none of the above” or I could just as easily answer “all of the above”. That alone should tell us that we are trying to answer the wrong question. But I have honestly seen developers (some of them even with PhDs in computer science) who couldn't write code if their life depended on it and architects who no longer remember how to code. I've also seen security professionals who are great pretenders. They know all the right buzzwords and have all the right certifications (e.g., ISC</span></span><sup><span style="font-style: normal;"><span style="font-weight: normal;">2</span></span></sup><span style="font-style: normal;"><span style="font-weight: normal;">'s CISSP, GIAC's Information Security Professional, etc.), but ask them to write up a threat model for some system and all the can give you is a blank stare.</span></span></div><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">That is not the point here!</span></span></div><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">A former colleague and close friend of mine once told me that he thought that about 20-25% of the people in </span></span><i><span style="font-weight: normal;">any </span></i><span style="font-style: normal;"><span style="font-weight: normal;">profession are clueless @holes. Any while that may be true (I think that the percentage is a rather high, and am in no position to judge other professions so I will refrain from further comment), that isn't the point. Companies, professional societies, and society as a whole <i>have to play they hand we've been dealt</i>. Companies generally don't have the option to use another company's employees.So the real point is <b><i>not</i></b> “who is correct?” in this debate, but rather “how can we help IT as a whole to move into a direction of more secure code without sacrificing developer (and perhaps more importantly, business) interests?”.</span></span></div><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">Which brings us back to the original "developers don't know shit about security comment". While I completely understand one's needs occasionally to vent frustration (and a cage wrestling match between Linus Torvalds and Bruce Schneier </span></span><i><span style="font-weight: normal;">might</span></i><span style="font-style: normal;"><span style="font-weight: normal;"> even prove amusing ;-), sniping at each other is seldom a productive way to reach your goals, as all it does is alienate the two parties that need very much to be working together to solve these issues. Taking an “us versus them” mentality is bound to fail, but by taking a “collective 'we'” stance, we might just make some progress. </span></span> </div><h3 style="font-weight: normal;"><span style="color: yellow;"><i>So What <u>Does</u> Matter?</i></span></h3><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Well, we could start with respect, for one. Now I will be the first to admit that I do a poor job at this. All too often, I confuse the issues of “trust” vs “respect”. I believe that it is OK to require that people earn some degree of trust. It is not OK to try to make them earn respect. There should be a certain amount of respect that we have for our both our development and security colleagues just based on common dignity of humankind and the common profession to which we belong.</div><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">What is not respectful is to assume that you clearly understand the motivations of individuals. At times, we are all probably guilty of this. So we might make the assumption that all VB programmers are stupid. I must confess that I have propagated this myth by quoting <a href="http://www.cs.utexas.edu/%7EEWD/transcriptions/EWD04xx/EWD498.html">Dijkstra's comment on BASIC</a> numerous times in my email .sig and </span></span><i><span style="font-weight: normal;">that </span></i><span style="font-style: normal;"><span style="font-weight: normal;">is disrespectful. Likewise for my .sig with Richard Clarke's quote “The reason you have people breaking into your software all over the place is because your software sucks...”. So I just want to be the first to step up and admit my guilt and to try to begin the healing process. I am unfortunately rather jaded over my 30+ years in IT, seeing the same dumb things repeated over and over again, often by the same people (myself included). But that is no reason to be disrespectful to them. So if I've offended anyone, I apologize for being so inconsiderate and ask your forgiveness. And even though the Dijkstra and Clarke quotes are two of my favorites, I will not use them again in my email .sig.</span></span></div><h3 style="font-weight: normal;"><span style="color: yellow;"><i>Reaching Common Ground</i></span></h3><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Wilander cites a poll that he took of 200+ developers and asked them to rate where security fell in their priority. Their rankings came out like this:</div><ol><li><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Functions and features as specified or envisioned </div></li>
<li><div style="margin-bottom: 0in;">Performance </div></li>
<li><div style="margin-bottom: 0in;">Usability </div></li>
<li><div style="margin-bottom: 0in;">Uptime </div></li>
<li><div style="margin-bottom: 0in;">Maintainability</div></li>
<li><div style="margin-bottom: 0in;">Security</div></li>
</ol><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">If you have done any development in the trenches, you probably are not surprised at these things. But I think Wilander let off one important rating. When I talk to developers and indeed in my former life </span></span><i><span style="font-weight: normal;">as </span></i><span style="font-style: normal;"><span style="font-weight: normal;">one, “schedule” would always come up as #1, and not overrunning the budget was always a close second or third. Perhaps meeting schedule and budget was just implied; I don't know as I haven't see the poll to which John refers. However, if nothing else, it does point so some other contributing forces as to why security gets ranked so low. (Surprisingly, this is often even the case when security software is involved, so these forces—probably coming from the business—seem to be universal, at least in the commercial sector.)</span></span></div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> I have often said that I believe that development is more difficult than security. Why? Well, for one, developers are expected to deal with the security aspect of their software <i>plus</i> all these other items in Wilander's list.</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Because of that, I think that my observation is true in the general case:</div><ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> “It's easier to teach a good developer about security than it is to teach a good security person how about software development.”</div></ul><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">So if I have to start training people about security (and I have done this with several), I always prefer to start with someone who is a good developer teach them about security rather than going in the other direction.</span></span></div><h3 style="font-weight: normal;"><span style="color: yellow;"><i>Back to Curphey's Blog</i></span></h3><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">Which brings me back, albeit in a circuitous way, to Mr. Curphey's astute observations.</span></span></div><div style="margin-bottom: 0in; margin-top: 0.08in;"><span style="font-style: normal;"><span style="font-weight: normal;">Mark states:</span></span></div><ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> “I had always hoped that the community would develop into a community of developers that were interested in security rather than a community of security people that were interested in software. I wanted to be part of a community that was driving WS* standards, deep in the guts of SAML and OAuth, framework (run-time) / language security and modern development practices like Agile and TDD rather than people seemingly obsessed by HTTP and web hacking techniques.”</div></ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Why <i>hasn't </i>this happened? Well, in my opinion, one reason is that an open source community's involvement in standards work is definitely at a disadvantage to special interest groups comprised of well-funded vendors who have a vested interest to develop such forward-looking work for the benefit of their respective companies. Involvement in these standards is takes a lot of time and usually there is a low reward, that being seeing people adopt your respective standard. Look how long it is taking the various OASIS WS-* standards to gain critical mass.</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Secondly,this sort of ambitious work requires a broad base of expertise. Let's take SAML, for instance. That requires expertise in XML, XSDs, encryption, and authentication protocols, and experience in writing specifications is highly recommended as well. That sort of breadth, beyond a surface level, is rare <i>in individuals</i>. However, a company sponsoring a specific standard need not rely a a single individual (even if they may have a single point of contact); they can afford to have several people participate. After all, why not? There frequently is a profit motive there. (This is especially true in standards that on the 2.0 or later revisions.)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Thirdly, people typically stay with what they are comfortable. So if their expertise is HTTP-based attacks, they stick with it until it no longer provides their meal ticket. And let's face it, when OWASP was started a decade or so ago, HTTP was pretty much all you needed to understand to get by. (Well, that plus a fundamental understanding of JavaScript.)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Mr. Curphey continues with</div><ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> “We can’t have security people who know development. We must have developers who know security. There is a fundamental difference and it is important.”</div></ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> I wholeheartedly agree with this. I think it aligns well with my above observation that it's easier to take a good developer and train her about security than vice-versa. If we fail to keep this idea in the forefront of our minds, we are bound to fail. My only addendum to Mark's comment would be to rephrase it to say that “we can't <i><b>only</b></i><i> </i>have security people who know development”. Those folks are still valuable. I think and hope Mark would concur.</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Curphey continues...</div><ul><div style="margin-bottom: 0in; margin-top: 0.08in;">“<span style="font-style: normal;"><span style="font-weight: normal;">Manage the Project Portfolio – When I look at the OWASP site today its hard to see it as anything else but a “bric-a-brac” shop of random projects. There are no doubt some absolute gems in there like <a href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API">ESAPI</a> but the quality of those projects is totally undermined by projects like the <a href="http://www.owasp.org/index.php/OWASP_Secure_Web_Application_Framework_Manifesto#tab=Project_About">Secure Web Application Framework Manifesto</a>. When I first looked I honestly thought this project was a spoof or a joke.”</span></span></div></ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> I see the same disorganization. In part, I think that's in part something that Wikis seem to encourage. Once they evolve beyond a certain critical mass, similar things get written down many times on many different pages unless there is an overall editor / project manager to manage it all. AFAIK, OWASP does not have this and it suffers for it. I think it also explains the lack of uniform consistency and quality across the various OWASP projects.</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Also, while I appreciate Curphey's candor, I appreciate even more Rohit Sethi's non-defensive response. When I read Rohit's comment to Mark's blog, I must say that while I'm sure it must have been a hard pill for him to swallow, he stepped up and did so like an honorable man. However, I do disagree in part with Curphey's assessment of the OWASP “Secure Web Application Framework Manifesto”. I don't think it is a <i>total</i> waste. In reply posted earlier today by Benjamin Tomhave, seems to have similar sentiment when Ben writes “but I hate to see the white paper lost. Why not also look at joining efforts with something like the Rugged Manifesto movement?”. There is something to be redeemed in almost every mess. If nothing else, it is useful to examine in more detail to see <i>why </i>it was deemed a failure. (I must admit I only took a quick 5 minute read through the whole manifesto, however, my overall sense was <u>not</u> that it lacked valuable information, but rather that it lacked appropriate organization along with a certain degree of incompleteness. If it were written in such a way that could be referenced <i>BY</i> <i>DEVELOPERS</i> (your audience) as a specification document, it could prove useful...especially for new frameworks that are only now getting underway. But if such a document is not well-organized and approachable <i><b>from the point of view of developers</b></i>, it will not get used. Period! (And don't even ask why 'Period' demands an exclamation point; I just like the sense of irony.)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Regarding Curphey's second point on “Industry Engagement and Communications”, I have no personal basis from which to speak, so I'll just keep my mouth shut on this one. (I can hear you all saying “Thank God!” :)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> To Mark's third point on “Ethics / Code of Conduct”, I think he is spot-on. Vendors use the “OWASP” word to sell the products more than ever. (“Successfully defends against the OWASP Top Ten attacks”, etc.) But unless OWASP is willing to take a stand and bite the hand that sometimes feeds it (Mark's second point), this will never change. In particular, unless OWASP is willing to litigate against those who take advantage of the OWASP name to pander their products, I don't see this changing at all. IANAL and thankfully, don't even play one on TV (or <i>YouTube</i> or that matter.), so that is up to the OWASP Board to decide, not me. (Hey, Jeff! Are you listening? What's your $.02 on this?)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> And finally to Mark's last point “Engaging Developers”. Mark writes:</div><ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> “Maybe Software Security is for developers and Application Security is for security people. The first persona is the <a href="http://www.curphey.com/2010/10/are-you-a-builder-or-a-breaker/">builder and the second persona the breaker</a>. ... Developers best understand what they need and want, security people best understand what they need and want.”</div></ul><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> No! I don't think so. There may be a continuous spectrum from builder to breaker, but if we treat these as <i>independent</i> goals, we will never get to where I think we all want to be, which is “secure software”. So they better have a common goal; they better both “need and want” the same things. Otherwise the whole security effort overall will fragment and fall apart. We need each other, and breakers and builders do have different means to achieve the same goal. But it had better be the same goal (well, assuming you breakers are “white hats”), and that goal is to improve software and systems security. Don't forget that!</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> <br />
</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Wow; I've blathered on much longer than intended. My original intent was to post this as a reply to SC-L, but at 4 pages, its a bit long for that. (Well, if you only learned one thing from this post, it's probably a side note observation: “Now I know why Kevin is not on Twitter”. ;-)</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;"> Send me your thoughts.</div><div style="font-style: normal; font-weight: normal; margin-bottom: 0in; margin-top: 0.08in;">-kevin</div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com4tag:blogger.com,1999:blog-8976089095047007543.post-35474280444824885702011-03-12T18:15:00.000-05:002011-03-12T18:15:08.488-05:00Signs of Broken Authentication (Part 2)<style type="text/css">
p { margin-bottom: 0.08in; }h3 { margin-bottom: 0.08in; }a:link { }
</style> <br />
<h3 style="color: red; font-weight: normal;"><i>Red Flag #2: Restricted Character Set for Passwords</i></h3><div style="margin-bottom: 0in;"><span style="font-style: normal;"><span style="font-weight: normal;">In the last post, we examined limiting password length as an authentication red flag. Today I want to look at another common red flag, that of restricting the allowed character set for passwords. </span></span>As a simple example, sometimes web sites will only allow alphanumeric characters in passwords.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">The scenario goes something like this... you register for an exciting new web site that all your friends are clamoring about, and you, being the clever type, try a password like 'G00d-bye!'. (One that clearly no one would <i>ever</i> be able to guess ;-). After confirming this as your new password, you click on the 'Submt' button, and the web site returns an error and informs you that "you have one or more invalid characters in your password; please try again”. (Thankfully, some of the more informative sites will <i>actually</i> tell you what characters that they <i>do </i>accept; how helpful is that, huh?)</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">After trying various other unacceptable passwords, you eventually discover that this site's developers have apparently read <a href="http://xkcd.com/">XKCD's</a> <a href="http://xkcd.com/327/"><i>Exploits of a Mom</i></a> and think they are preventing SQLi because they don't allow the evil “-” character in their passwords.<br />
<br />
The really "ingenious" sites also don't allow '<', because after all, someone might create a password whose value is something like “<script><i>insert_evil_javascript_here</i></script>” exposing a XSS vulnerability. (These same sites may reason that this is also good rationale to limit the password's length; make it short enough and no dangerous amount of script can be inserted.) They don't allow “:” for a similar reason, because after all, the <i>really</i> <i>clever</i> hacker may instead try to use “<b>javascript:</b><i>insert_evil_javascript_here</i><span style="font-style: normal;">”</span> for their password.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Or you might find that the developers disallow characters like '$' or '@' or '|'. They may do this because they have implemented their web site in Perl and their password handling is using either 'eval' or `` or system() or pipes to pass your password string through to some other back-end system for the actual authentication processing and those characters are problematic in such cases. (If so, they possibly have worse issues, like command injection, but this is only a contrived example, so we'll go with it, okay?)</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Pretty soon, these developers have had so much trouble with so many different special characters that they simply decide to disallow <i>all</i> special characters and instead they just check to make sure that you use one of their benign characters in your password, such as alphanumeric. (On the bright side, at least this approach leads itself to white-listing rather than black-listing.)</div><div style="margin-bottom: 0in;"><h4 style="color: yellow; font-family: Helvetica;"><i>Implications</i></h4></div><div style="margin-bottom: 0in;">But, “why is this a problem?” you ask. Well, because it greatly reduces the number of possible passwords of a given length. If <i>N</i> is the number of characters in the permitted password “alphabet” and <i>L</i> is the maximum length of the password, then there are only <i>O(N</i><sup><i>L</i></sup><i>)</i> possible passwords with that “alphabet”. (The exact number of possibilities of passwords with up to L characters chosen from an alphabet of size N is a bit larger since obviously we can chose passwords that are between the minimum length <i>m</i> and maximum length <i>L</i>. Working out the exact number of possible passwords is left as an exercise for the reader.)</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">If alphabetic (both upper and lower case), numeric, and special characters on the typical QWERTY keyboard are permitted, the size of the “alphabet” is 95 characters (including space, but excluding tab and newline which are very difficult to enter from a web browser and assuming I counted correctly :). If you exclude all the special characters, you are left with only 62 alphanumeric characters. If you use a minimal length password, which many of you probably do (and for many sites, that is perfectly reasonable; using 'HuH75^mn43,1@#' is probably fine for my bank, but a bit overkill for the <i>NY Times</i> site, where clearly all passwords should be either “WSJ_rules” or “WashingtonPost”, just to protest such nonsense), then an 8 character password works out on the order of <style type="text/css">
p { margin-bottom: 0.08i
</style>62<sup>8</sup> or 218,340,105,584,896 possibilities. By comparison, if we were to allow special characters in the password, then an 8 character password has <style type="text/css">
p { margin-bottom: 0.08in; }
</style>95<sup>8</sup> or 6,634,204,312,890,625 possibilities, which, if I've done my math right, is about 30.4 times more. This means, for instance, <i>if</i> an adversary were able to brute force all the possible 8 character <i>alphanumeric</i> passwords in one day, it would take that adversary roughly a month to brute force a password comprised of all possible alphanumeric <i>and</i> <i>special</i> <i>characters. </i>(In reality, if off-line dictionary attacks are viable at all, these numbers are not too far fetched using a fairly cheaply built high-end farm of GPUs. But that's a topic left for another day.)</div><div style="margin-bottom: 0in;"><h4 style="color: yellow; font-family: Helvetica;"><i>Remediation</i></h4></div><div style="margin-bottom: 0in;">So we see that restricting which characters may be used in a password is another red flag for authentication. But now you ask, "how do we fix this?". Well, first of all, we make one very important design decision. Once a user's password is submitted, we decide we will <i>never</i>, <i>ever</i> attempt to display it again. This is good on many different levels (especially for privacy reasons), but another major benefit is that we never have to worry about issues like XSS.<br />
<br />
I will outline one simple scenario that I prefer, but obviously there are several variations of this that will work as well.<br />
<br />
In your password handling code, which would cover not only your login page, but also your change / reset password pages as well, you immediately convert the password string to a byte array. (A char array will do as well [in languages, such as Java where these types are different], but byte arrays usually interface more easily with message digests or symmetric encryption APIs.) You should do this conversion as earlier as possible and you should use a specific<style type="text/css">
p { margin-bottom: 0.08in;
</style>—rather than the default—character set for the conversion. (Aside: I'd recommend UTF-8 since it is so widely supported; using the <i>native</i> default encoding is asking for trouble because if you ever change deployment architectures you likely could find yourself with a user store where older passwords no longer work on the new system.) Once you have converted it to a byte array, either hash the byte array (ideally using a suitably sized random salt) or encrypt it. Then encode it in some standard format for storing...base64 encoding is typical, and finally store it. Then all subsequent operations with the user's password is done via this (say) base64-encoded hashed or encrypted password which you have secured stored somewhere.<br />
<div style="margin-bottom: 0in;"><h4 style="color: yellow; font-family: Helvetica;"><i>Final Word</i></h4></div>One final word on this. A colleague and I have been experimenting with using a Web Application Firewall (WAF) to monitor some web sites. One thing that we noticed is that occasionally, the WAF will flag a password containing certain special characters (usually, single quote (') or hyphen (-), but occasionally '<') as an attempted SQLi or XSS. In almost all cases, these are false positives where end users are innocently trying to use these characters. For example, a user may try to enter "d0n't-ever-d0-th4t!" as her password, but the WAF thinks that this is an attempted SQLi attempt because of the presence of the single quote and/or hyphen. Unfortunately in the case of the WAF that we've been experimenting with, the default action of this particular WAF is to <i>block</i> such requests. Such default behavior, if allowed, is likely to frustrate users and your help desk, so it is easy to see how the site's developers might respond by simply not allowing such troublesome characters in passwords to start with.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">But IMHO, this is the wrong tact. Rather than trying to work around the symptoms, fix the problem where it is...the broken WAF rules. A wacky WAF is no excuse for dumbing down user's passwords!</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Next time I will discuss a much worse variant of this red flag that this particular blog post examined as well as the failure for authentication systems to provide automatic account lockout.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Until then,</div><div style="margin-bottom: 0in;">-kevin</div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com0tag:blogger.com,1999:blog-8976089095047007543.post-8177812026211073522011-03-10T00:40:00.000-05:002011-03-10T00:40:12.037-05:00Signs of Broken Authentication (Part 1)<style type="text/css">
p { margin-bottom: 0.08in; }h3 { margin-bottom: 0.08in; }a:link { }
</style> <br />
<div style="margin-bottom: 0in;">First a warning...this topic is one of my hot buttons issues, so my tone may be a bit more over-the-top and sarcastic than usual. (But for those of you at home with small children, I promise to refrain from cussing.)</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">OK, quick quiz... have you ever visited a web site where they want you to register with a user name and password, and when you finally get to the password field to choose your password you find that they really make you dumb down your password choices by restricting what characters you are able to use and/or how long you are allowed to make your password? </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Or maybe you have seen web sites that have don't use https for their login pages???</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Unless you've just crawled out from under a rock and have just discovered web browsers, you've all been there.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">However, unless you suffer from security-paranoia like me (it's all the fault of those NSA folks and their blasted little black helicopters; now where'd I put my tinfoil hat), these things probably don't bother you. Over the period of the next few days in a multi-part blog post (thanks Matt! ;-) I'm going to tell you why these things <i>should</i> concern you and how to spot "broken" authentication. (But until then, just remember, us security professionals are paranoid so that the rest of you don't have to be.)<br />
<h3 style="color: red; font-family: Times,"Times New Roman",serif; font-weight: normal;"><span style="font-size: large;"><i>Why This Is Important</i></span></h3></div><div style="margin-bottom: 0in;">Broken authentication on a web site is akin to a bank whose vault door has rusty hinges. Your money may be secure there, but you might want to think about taking your cash to the bank down the street. Likewise, if the authentication on a web site has poor security, it is likely that the security for rest of the site is even worse. That's because authentication is probably <i>the</i> major area that most developers try to pay very close attention to with respect to the security details. It is generally one of the few spots for which they may even have specific security requirements.</div><h3 style="color: red; font-family: Times,"Times New Roman",serif; font-weight: normal;"><span style="font-size: large;"><i>Red Flag #1: Maximum Password Length</i></span></h3><div style="margin-bottom: 0in;">Let's start with a restricted password length. Why do developers do that? The most obvious reason is that they are storing your password in some database somewhere in some fixed-size VARCHAR column. So they choose some minimum size size to make their SOX-compliance people happy (typically 6 or 8 characters) and choose a maximum length based on the maximum size that their database can accommodate. Not uncommonly, that size might be something like a power of two, so maximum lengths like 16 or 32 characters are common.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">“Isn't 16 or 32 characters long enough for a secure password?”, you ask. Of course it is, but that's not the point. The point is, if they <i>are</i> imposing a maximum length, I can almost certainly guarantee that they are <i>not</i> running your password through a secure, one-way hash such as SHA1 or SHA-256 before they are storing it. Most likely, the are just storing your password as plaintext, although if you are lucky, they <i>may</i> be encrypting it and storing the ciphertext for your password. (Probably not, but one can always hope.) Not hashing passwords is bad for a lot of reasons, but the biggest reason that you <i>as an individual</i> should be concerned about is someone stealing your password. Minimally, an attacker who captures your cleartext password can use it to access this particular site whenever he or she wants. And how many of you reuse your <i>same</i> passwords on multiple web sites? Uh huh. I thought so.<br />
<br />
Well, when your passwords are stored as cleartext, if their web site is susceptible to SQL Injection (SQLi)–a fairly common vulnerability, some hacker just might make off with their entire User table along with all of its cleartext passwords which some of you (you know who you are!) might just be using for your bank or 401(k) or your Facebook page, etc. (I can hear all of you now saying “Not me; I would <i><b>never</b></i> do such a thing.”<i><b> Liar!</b></i>) And of course, even if their site is safe against SQLi because their developers were smart enough to have read the <a href="http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP SQL Injection Prevention Cheat Sheet</a>, your passwords are <i>still</i> lying there in wait for a rogue DBA to grab them. (It happens; trust me. Google it if you don't believe me. I'll wait...)<br />
<br />
On the other hand, if one <i>hashes</i> passwords, preferably with a suitably sized salt (we won't be covering the reasons for that here, but Google for "salt" and "rainbow tables" if you are interested), then the hash (or hash plus salt) will always be some <i><u>maximum</u> <u>fixed</u> </i>size regardless of the length of the original password. In such cases, there is no reason to impose a maximum length on the user's password because the hash that's stored is of fixed length.<br />
<br />
So imposing a maximal length on a user's password is generally a good indication that that web site is not hashing your password and generally, that is a bad thing.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">(to be continued...)</div><div style="margin-bottom: 0in;"></div><div style="margin-bottom: 0in;">-kevin</div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com4tag:blogger.com,1999:blog-8976089095047007543.post-15246206826990212292011-03-04T18:36:00.000-05:002011-03-04T18:36:40.952-05:00ESAPI and the Padding Oracle Attack<span style="font-family: Arial,Helvetica,sans-serif;">For those of you wh</span>o don't read the OWASP blog (you should), the link below is, in part, what started all of this. I started out responding in an email to Jeremiah Grossman to a tweet to he had made to Jeff Williams about how quickly the ESAPI team had responded to the Padding Oracle Attack that Juliano Rizzo and Thai Duong had discovered in ESAPI. What started out a private email to a Jeremiah and a select few of the ESAPI team shortly thereafter ended up on the OWASP blog.<br />
<br />
Anyhow, without further ado, here is the link to the OWASP blog post:<br />
<blockquote><a href="http://owasp.blogspot.com/2011/02/esapi-and-oracle-padding-attack.html">ESAP and the Padding Oracle Attack</a></blockquote>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com1tag:blogger.com,1999:blog-8976089095047007543.post-17395126253734143472011-03-03T01:56:00.000-05:002011-03-03T01:56:18.173-05:00Answers to Hard Questions<style type="text/css">
p { margin-bottom: 0.08in; }
</style> <br />
<div style="margin-bottom: 0.08in;">There have been a few FOSS and work colleagues who have commented that I should start a blog. (You know who you are, so I won't embarrass you in public.) Each time, I have thought about it, I found it difficult to get started, but I figured that I'd better stop procrastinating lest I become extinct. (I hear it's much more difficult to blog once you're on the other side of the grass.)</div><div style="margin-bottom: 0.08in;">At some point, I promise to discuss ESAPI (and particularly the crypto-related packages), but I didn't want to dive right into that without some other lighter weight (says the old fat guy without any sense of irony—or perhaps just without any sense, period) material to start things off.</div><div style="margin-bottom: 0.08in;">Well, if you are reading this blog, you either probably have insomnia and are in desperate search of a cure (look no further!) or are someone who wanted me to embarrass myself in public (likely those same “someones” who wanted me to start a blog in the first place), or you were pointed here by a link that someone sent to you. (In the latter case, I apologize for your misguided friends. But like I always say sometimes, “With friends like them, who needs enemas?”)</div><div style="margin-bottom: 0.08in;"><style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style> </div><div style="margin-bottom: 0.08in;">Anyway, if you really want to know about my work history, etc., then you can find out by following the links to my LinkedIn, OWASP, and Google Code pages from my Personal Identity Portal at <a href="https://kwwall.pip.verisignlabs.com/">https://kwwall.pip.verisignlabs.com/</a>. But if you get <i>really</i> bored, don't blame me; sleeping pills for all my insomniac friends.<style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style> </div><div style="margin-bottom: 0.08in;">So, after babbling for almost <style type="text/css">
p { margin-bottom: 0.08in;
</style>¾ of a page, let me finally cut to the chase. What I really decided that I wanted to discuss was to attempt to answer the penetrating questions posed by Michael Kassner on his IT Security blog over at TechRepublic. His blog, “<a href="http://www.techrepublic.com/blog/security/brave-new-world-asking-hard-questions-about-security-user-rights-and-trust/5133?tag=nl.e036">Brave new world: Asking hard questions about security, user rights, and trust</a>”, posses the five following questions, which I will attempt pontificate and wax philosophical about without sounding <i><b>too much </b></i><span style="font-style: normal;"><span style="font-weight: normal;">like an @hole:</span></span></div><ol><li><span style="font-style: normal;"><span style="font-weight: normal;"> </span></span> <style type="text/css">
p { margin-bottom: 0.08in;
</style><em><span style="font-weight: normal;">Should access to the Internet be a privilege, a right, or…</span></em></li>
<li><em><span style="font-weight: normal;"> </span></em> <style type="text/css">
p { margin-bottom: 0.08in; }
</style><em><span style="font-weight: normal;">Should qualified organizations be allowed to remove malware from Internet-facing computers without the owner’s permission or knowledge?</span></em></li>
<li><em><span style="font-weight: normal;"> </span></em> <style type="text/css">
p { margin-bottom: 0.08in
</style><em><span style="font-weight: normal;">What guarantee do I have that a piece of open-source software has been adequately vetted by qualified and honest reviewers?</span></em></li>
<li><em><span style="font-weight: normal;"> </span></em> <style type="text/css">
p { margin-bottom: 0.08in; }
</style><em><span style="font-weight: normal;">Should a digital/electronic signature carry the same weight as a written signature?</span></em></li>
<li><i>How are we to be assured that electronic voting is trustworthy?</i></li>
</ol><style type="text/css">
p { margin-bottom: 0.08in; }
</style> <div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">So ready? Here goes... </span></span></em> <style type="text/css">
p { margin-bottom: 0.08in; }
</style> </div><div style="margin-bottom: 0.08in; margin-left: 0.49in;"><em><span style="font-style: normal;"><b>Question #1:</b></span></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> <i><span style="color: yellow;">Should access to the Internet be a privilege, a right, or...</span></i></span></span></em> </div><br />
<div style="color: blue; margin-bottom: 0.08in;"><b>Yes.</b></div><div style="margin-bottom: 0.08in;"> <style type="text/css">
p { margin-bottom: 0.08in; }
</style> </div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">OK, seriously. Anyone who has read my any of my emails right now are probably saying to yourself, “I don't know <i>who</i> you are, but you can't be the Kevin Wall that I know, because he can't possibly answer an open-ended question with a one word answer. For that matter, he can't even answer a T/F question with a single word.” OK, so you got me. But that's all I'm going to say about it, for now at least. Maybe more in a future blog if people are foolish enough to encourage this old dinosaur.</span></span></em></div><div style="margin-bottom: 0.08in;"> <style type="text/css">
p { margin-bottom: 0.08in; }
</style> </div><div style="margin-bottom: 0.08in; margin-left: 0.49in;"><em><span style="font-style: normal;"><b>Question #2:</b></span></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> <i><span style="color: yellow;">Should qualified organizations be allowed to remove malware from Internet-facing computers without the owner’s permission or knowledge?</span></i></span></span></em></div><style type="text/css">
p { margin-bottom: 0.08in; }
</style> <div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">To answer a question with a question, “Who selects the 'qualified organizations'?”.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Or to answer like a typical engineer or lawyer (NB: IANAL): "It depends". In most cases, I would answer “no”, if for no other reason that accessing someone's system without the owner's permission is </span></span></em><em><i><span style="font-weight: normal;">unauthorized </span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;">access by definition, which constitutes a federal offense. (Since IANAL, I won't bore you with the exact laws. I'll let any attorneys reading this bore you with those details as I have plenty of other things to bore you with.)</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">However, the more important reason that I would answer “no” is that there is no organization that is likely to be competent to do this (especially without significant human guidance) and there is a probably as much of a chance that they would hose your personal system as they would repair it. Plus, if they do screw it up, who is liable? In the general sense, this is just stupid and we shouldn't even be discussing it. In most cases, the cure is worse than the disease.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">So when <i>might</i> I answer “yes”? Well, I would answer yes, if all your personal computing system and it's malware is in the “cloud” so that in reality you are using someone else's CPU resources and storage. I would also answer “yes” if the computing equipment was donated as part of a service / use contract. This is not as far-fetched as it first may sound. Wireless providers are already giving away free, or almost free, smart phones with a 2 year contract. (At some point, the same will likely be true for tablet computers.) So if part of the contractual EULA stipulates that the service provider is permitted to attempt to remove malware from the device without prior notification, at least <i>legally</i> it would be OK. But in that sense, the user's has already signed over their permission; they just not may have granted permission or given notice for some </span></span></em><em><i><span style="font-weight: normal;">specific </span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;">incident. (Note that in this regard, it is not unlike the AV vendors who will attempt to remove malware, or if that is not possible, to put the infected files into a quarantine area.) But even then, I think that the “qualified organization” needs to be ready to accept liability if their means of removal makes some other piece of unrelated computing equipment (e.g., a router, a printer, another computer on the user's LAN, etc.) inaccessible.</span></span></em></div><div style="margin-bottom: 0.08in;"> <style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style> </div><div style="margin-bottom: 0.08in; margin-left: 0.49in;"><em><span style="font-style: normal;"><b>Question #3:</b></span></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> <i style="color: yellow;">What guarantee do I have that a piece of open-source software has been adequately vetted by qualified and honest reviewers?</i> </span></span></em><em><span style="font-weight: normal;"> </span></em> </div><div style="margin-bottom: 0.08in;"><em><span style="font-weight: normal;">HA! HA HA HA HA HA!!! </span></em><em><span style="font-style: normal;"><span style="font-weight: normal;">Come on man; are you serious??? Have you not ever read the warranty disclaimers and limitation of liabilities that come in some variety that with pretty much every piece of software that you have ever used, with it be proprietary or open source. You know, the sections that ARE WRITTEN IN ALL UPPERCASE SO THAT YOU WILL FEEL INTIMIDATED BY THE ATTORNEYS SHOUTING AT YOU?</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">If any software was properly vetted, it might be argued that developers need not have to hide behind the cloak of such legal gibberish. (And, BTW, my personal attorney told me that in the state Ohio, one cannot simply waive tort regardless of what the contract says. But YMMV, so talk your own attorney.)</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Personally, I think it is sad that we are in this state (no, not Ohio!). It started out as well-intentioned attorneys trying to protect the interests of their clients, which is what we should expect, but somewhere has gotten off-track to the extent that in some cases I believe it has encouraged sloppy software development practice.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">[Aside: There is some push back against this over at <a href="http://ruggedsoftware.org/">ruggedsoftware.org</a>. (That's “rugged” as in “sturdy and strong”, and not “rugged” as in in “roughness of surface”, although there's way too much of that sort of software out there too.) But frankly, no one (myself included!) yet has the balls to renounce the software warranty disclaimers and liability restrictions placed in every software license known to FOSS. In fact, when I even suggested it to one of the Rugged Software co-founders, he looked at me like “Are you nuts???”.]</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Software correctness is one of the most difficult things to get right. In a sense, I believe programmers make a comparable number of errors (as measured by some means of “error rate”) as humans do in any other complex endeavor which they attempt. However, at this point, computers are very different than humans. For the most part, humans grok the semantic meaning based on the surrounding context and thus get beyond the mistakes. As an example, if I wree to witre tihs setnecen lkei tsih yuo cna pborlaby sitll uendrsdtna it even though you find it a bit rough going. But if programmers were to make similar corresponding mistakes in their programs and that portion of the code is executed, it almost always results in disastrous consequences. We have yet to invent a computer or operating system that is based on “the do what we mean, not what we code”. In that sense at least, humans are much more resilient than software. (We do not want our "rugged software" to become "brittle software".) However, it is because of this complexity, most serious attempts at vetting software by qualified and honest reviewers using best practices still falls seriously short of hopes and expectations. This is not an indictment against open source developers; those developing proprietary commercial software have the same issues. There are some major exceptions to this rule (such as the space shuttle software that has been constructed in such a way to be have its correctness proven), but these exceptions are generally not cost effective and are several of orders of magnitude more costly to develop than does conventional code. So such vetted software is rare in commercial sectors and even rarer in open source development where almost all of the developers contribute their efforts for free.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">In part, this lack of quality in software—caused by many things, including not properly vetting—is “demanded” by consumers. For better or worse—after being trained by years of crapware from major software vendors—consumers don't scream for correctness; they scream for features. The same is true with respect to security vulnerabilities. As security researchers Ed Felten and Gary McGraw once said,</span></span></em></div><blockquote><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">“Given a choice between dancing pigs and security, users will pick dancing pigs every time.”</span></span></em><br />
</div></blockquote><div style="margin-bottom: 0.08in; margin-left: 0.49in;"><em><span style="font-style: normal;"><b>Question #4:</b></span></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> <i style="color: yellow;">Should a digital/electronic signature carry the same weight as a written signature?</i></span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Hmmm...a trick question? In some sense in many countries, they already do, as there are circumstances where both are recognized as legally binding. For example, in the USA, congress signed the “Electronic Signatures in Global and National Commerce Act (E-Sign)” act into law in June, 2000. See the Duke Law & Technology Review article “<a href="http://www.law.duke.edu/journals/dltr/articles/2001dltr0005.html">Are Online Business Transactions Executed By Electronic Signatures Legally Binding?</a>” for a better explanation than I could ever hope to give. So in that case, it is irrelevant as to what my opinion about it is (i.e., what it </span></span></em><em><i><span style="font-weight: normal;">should </span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;">be); it's the law of the land.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">[Note: I am only going to address "digital" signatures, not "electronic" ones, which could mean many different things, depending on whom you ask.]</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;"> </span></span></em><em><span style="font-style: normal;"><span style="font-weight: normal;">But, if what you are asking is one's professional opinion (dumb looks and all), as a information security professional, my answer is that dsigs </span></span></em><em><i><b>should NOT </b></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;">carry the same weight as handwritten signatures. I will try to explain my reasoning for this.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">A cryptographic digital signature requires a cryptographic key pair. One key is the “public” key and is used [generally by others] for validating signatures and the other key is the “private” key and is used for creating (i.e., signing) signatures. (Public and private keys are also used for asymmetric encryption, but if you are aware of that, try to forget about that for now as it will only confuse you. And also don't think about <span style="color: magenta;">pink elephants</span> either. ;-)</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">The cryptographic keys are always created as a <i>key pair</i> and one cannot be changed independent of the other without causing the whole signature process to fail in a detectable manner.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Now, enter our cast of characters, Alice and Bob. Alice has generated a key pair and has her private key on her PC or other personal computing device. Alice has also made her public key accessible to Bob. For simplicity, let's assume that she hands it directly to him on a flash drive. (Alice might also make her public key available to others via a public key server. It is, after all, a </span></span></em><em><i><span style="font-weight: normal;">public </span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;">key.)</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Alice then writes a contractual document that she digitally signs using her private key and sends both the contract and the digital signature to Bob, where Bob validates Alice's signature via the public key that Alice provided him. If the document's signature is valid, Bob knows that 1) the document has not been tampered with after it had been signed, and 2) it was signed with Alice's private key, and hence Bob has reason to believe that Alice "signed" the contract</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">So far, so good.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Now here is the crux of the problem. Can we state without question (say to the same degree that someone witnessing a person's handwritten signature can attest to) that <i>any</i> document signed by Alice's private key was signed by Alice herself?</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">The answer is “no, we cannot”. All we really know that it was Alice's </span></span></em><em><i><span style="font-weight: normal;">private key</span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> that signed said document, but we don't know if it was </span></span></em><em><i><span style="font-weight: normal;">Alice</span></i></em><em><span style="font-style: normal;"><span style="font-weight: normal;"> who actually initiated the signing. That is, we have a gap between Alice's <i>identity</i> as an individual and Alice's <i>private key</i>.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">The usual and often implicit assumption is that, since Alice's private key is supposed to be private, Alice is the only one having access to it. Therefore if a document is found signed with Alice's private key (as verified by Alice's corresponding public key), then by golly, it must have been Alice that signed it.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">But this assumption is erroneous. For example, what if Alice's PC were infected with malware and some evil black hat H4><0r used that malware to steal her private key. (What? You say it was her fault because she didn't keep the private key in an encrypted key store file that was protected by a pass phrase? My Lord! Have you never heard of keystroke loggers?)</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">So the digital signature analogy with handwritten signatures is actually closer to one witnessed indirectly, say via a delayed video feed, rather than one that was witnessed in person in real-time. Just like a delayed video field can be doctored to misrepresent someone, a private key can be stolen and abused by malware (completely unbeknownst to the user by the way) to sign any arbitrary document.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Now it's a whole lot easier to infect an ordinary citizen's PC / MAC / miscellaneous computing device with malware than it is to doctor a delayed video feed. Indeed, the number of malware infected PCs in the world at any given time clearly is in the millions and probably even higher by an order of magnitude or so. Compare that to how many videos (or even still photographs for that matter) are doctored each year, and you will see my point. So, IMNSHO, there is no way that we should hold an ordinary citizen, who has not been formerly trained in security practices, accountable for digital signatures that she may or may not have created. For B2B, maybe, but for C2B, no.</span></span></em></div><div style="margin-bottom: 0.08in; margin-left: 0.49in;"><em><span style="font-style: normal;"><b>Question</b></span></em><b> #5:</b><i style="color: yellow;"> </i><span style="color: yellow;"><em><span style="font-style: normal;"><span style="font-weight: normal;">How are we to be assured that electronic voting is trustworthy?</span></span></em></span></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Your last question (#4) seemed like a trick question (or possibly just an imprecisely worded one), so how about a “trick answer” for this one.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;"><b>Answer: </b>If the person whom you voted for won, you can trust it; otherwise, you cannot.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Seriously, in all honesty, it depends on what level of trust that you are looking for. If you are one who believes in conspiracy theories, then nothing that can be done will provide you with the assurance that you are seeking. If you are one who simple prefers the convenience of electronic voting and are not that into politics, it probably won't take too much to provide you with the warm fuzzies. The issue is that “trust” is not black or white, but rather shades of gray. Furthermore, different people prefer / demand different levels of grayness. So we can probably provide assurance for a select few, but never for all.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">So having spouted that pompous sounding bullshit, let me tell you my opinion (since you asked; beware of “dumb looks” though) of what I think it requires to get at least moving in the right direction.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">First of all, having a tangible, unalterable physical audit trail is mandatory. Most security folks, myself included, believe that this needs to be something like a digitally-signed paper trail where two identical copies are printed. (Or one copy and a trusted photocopier.) One copy goes into a lock-box at your voting precinct and the other copy, the voters take home with them. In the case of a contested election, this is the chain of evidence that is relied upon and is what eventually is recounted.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">Secondly, I believe that the whole electronic voting system, from voting machines to tabulators and everything in between, needs to be developed as open source. It does not have to be open source in the sense that the license provides a right to modify and alter nor need it even be free to use, but it is important that anyone who wishes must be allowed to examine the source code of the electronic voting system whenever they wish. And for good measure, I think that whatever particular software versions are used should be digitally signed by at least two independent escrow agencies who will hold the digitally signed source code (as well as the signed compiled binaries) in safekeeping.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">And lastly, I think there needs to be an open review process..an open RFC period if you will, where everyone has an opportunity to comment on the requirements as well as the design.</span></span></em></div><div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">If we do all those things, then perhaps some day we will get to a point that the majority of people will trust it. But unfortunately, the losing minority almost never will.</span></span></em></div><em><span style="font-style: normal;"><span style="font-weight: normal;"></span></span></em><br />
<div style="margin-bottom: 0.08in;"><em><span style="font-style: normal;"><span style="font-weight: normal;">FWIW, -kevin</span></span></em> <style type="text/css">
p { margin-bottom:
</style> </div><br />
<br />
<div style="margin-bottom: 0.08in;"> </div>Kevin W. Wallhttp://www.blogger.com/profile/07020090691046917645noreply@blogger.com6