[colug-432] Random Generator

[George Larson]

On Sun, May 25, 2014 at 11:33 PM, Chris Spackman <chris at osugisakae.com>wrote:

> Would it weaken the security significantly if we mixed the results
> with a similar process, conducted locally?
>

​I would highly recommend combining sources of 'random' data.  Any time
we're talking about security, we've to define a threat model or things get
entirely maddening.  In the post I made, it was largely a thought
experiment with a single real-world use.  The thought experiment was about
how to generate random data on an untrusted system so the threat model
includes being suspicious of the box you're using.  That's, of course, a
dicey situation because the threat model is still too vague.  Why assume
that they would have the means (and bother) to compromise your generated
data but then assume that they can't eavesdrop on whatever else you do?​
(e.g., keylogger)

The real-world use was that I was working on some code and wanted to put an
example in the comments of one way that someone *might* generate a
replacement salt for the default in the configuration.  As a user of many
distros including the BSD families, I try to avoid examples that use
paths.  While I would expect an Open

The salt was applied against passwords offered by the user, just to make
the hash more of a headache to brute.

Ultimately, you've to decide the value of what you're protecting and that
should dictate the inconvenience of your access.

To give an example, let's imagine that I have some printed single-use
passwords to a system.  To those passwords I've applied a completely
rudimentary cypher that prevents my printed list from being actual usable
passwords.

To illustrate, let's say that single-use password is '1234567890'.  I could
split the string in the middle and put the second half first, resulting in
'6789012345' and then I could add letters knowing that my password was
entirely numeric so alphas get discarded.  '6a78X901vv234P5T' would still
get me to my password, right?  I might set things up so that if there is an
attempt to access this system with incorrect passwords more than X times
then the originating IP is blocked, all external access is disabled for a
period of time and I am emailed about the activity.  If remote access were
my only method of entry then, at least, I would know when I could get back
in -- but this is the shortcoming of most of my thought experiments.
Without a definition of the system *and* the threat model then I get lost
in the infinitude of what-ifs.  XD

Also, if it is a system of your design then there's a lot to be said for
two-factor auth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20140526/c5952999/attachment.html