<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 25, 2014 at 11:33 PM, Chris Spackman <span dir="ltr"><<a href="mailto:chris@osugisakae.com" target="_blank">chris@osugisakae.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5hz" class="a3s" style="overflow:hidden">Would it weaken the security significantly if we mixed the results<br>
with a similar process, conducted locally?</div></blockquote></div><br><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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)<br>
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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 <i>might</i> 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<br>
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">The salt was applied against passwords offered by the user, just to make the hash more of a headache to brute.<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
Ultimately, you've to decide the value of what you're protecting and that should dictate the inconvenience of your access.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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.<br>
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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 <i>and</i> the threat model then I get lost in the infinitude of what-ifs. XD<br>
</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Also, if it is a system of your design then there's a lot to be said for two-factor auth.<br>
</div></div></div>