Problem - Kevin Tafuro

This book doesn’t always force you to do the secure thing.
Some people would rather we take the approach of showing you one right way
to do the few things you should be doing in your applications. For example, we
could simply cover ways to create a secure channel, instead of talking about all
the different low-level cryptographic primitives and the many ways to use them.
We do provide a lot of high-level solutions that we’d strongly prefer you use. On
the other hand, we have consulted on so many real-world systems that we know
all too well that some people need to trade off the absolute best security possible
for some other requirement. The whole security game is about risk mitigation,
and it’s up to you to decide what your acceptable levels of risk are. We
have tried to accommodate people who may have nonstandard requirements,
and to teach those people the risks involved in what they’re doing. If we simply
provide high-level solutions, many people won’t use them, and will continue to
build their own ad hoc solutions without adequate guidance.
This book could be friendlier to Windows developers.
In general, we cover the native Win32 API, rather than the variety of other API
sets that Microsoft offers, such as ATLand MFC. It would simply be infeasible to
cover all of them, so we’ve opted to cover the one that everything else builds on.
We’re sorry if you have to go to a lower-level API than you might like if you want
to use our code, but at least this way the recipes are more widely applicable.
Much of the code that we present in the book will work on both Unix and Windows
with little or no modification. In these cases, we’ve favored traditional
Unix naming conventions. The naming conventions may feel foreign, but the
bottom line is that no matter what platform you’re writing code for, naming conventions
are a matter of personal preference.
If you thumb through the table of contents, you’ll quickly find that this book
contains a considerable amount of material relating to cryptography. Where it
was reasonable to do so, we’ve covered CryptoAPI for Windows, but on the
whole, OpenSSLgets far better coverage. It is our experience that CryptoAPI is
not nearly as full-featured as OpenSSLin many respects. Further, some of the
built-in Windows APIs for things such as SSLare far more complex than we felt
was reasonable to cover. Security is something that is difficult to get right even
with a good API to work with; an overly complex and underdocumented API
certainly doesn’t help the situation.
We’ve tried our best to give Unix and Windows equivalent coverage. However,
for some topic areas, one platform may receive more in-depth attention. Generally,
this is because of a specific strength or weakness in the platform. We do
believe both Windows and Unix programmers can benefit from the material
contained in this book.
There will still be security problems in code despite this book.
We have done our best to give you the tools you need to make your code a lot
better. But even security gurus occasionally manage to write code with much
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Preface | xix