<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2017, at 7:07 AM, Mark Steward <<a href="mailto:marksteward@gmail.com" class="">marksteward@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><span style="font-family:sans-serif" class="">Something needs to be able to read that file, so there's not much difference to a peppered hash, and rate limiting at the data layer is much less useful for security than at the application layer.</span></div><div dir="auto" class=""><span style="font-family:sans-serif" class=""><br class=""></span></div><div dir="auto" class=""><span style="font-family:sans-serif" class="">You also still need to salt or pepper, as permuting doesn't hide frequencies.</span></div><div dir="auto" class=""><span style="font-family:sans-serif" class=""><br class=""></span></div><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" style="font-family:sans-serif" class=""><br class=""></div><div dir="auto" style="font-family:sans-serif" class="">Mark</div></div><br class=""><div class="gmail_extra" dir="auto"><br class=""><div class="gmail_quote">On 14 Mar 2017 04:24, "Tom Mitchell" <<a href="mailto:mitch@niftyegg.com" class="">mitch@niftyegg.com</a>> wrote:<br type="attribution" class=""><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 13, 2017 at 1:58 AM, Robin Wood <<a href="mailto:robin@digininja.org" class="">robin@digininja.org</a>> wrote:<br class="">
><br class="">
....<br class="">
<div class="quoted-text">>><br class="">
>> Again the security depends on the difficulty of exfiltrating such a large<br class="">
>> data set, not on a short key that that is relatively easy to steal.<br class="">
><br class="">
<br class="">
</div>Also a single file would be opened by a very short list of processes.<br class="">
Access control lists apply. Even advisory access control can be used to<br class="">
trigger alerts.<br class="">
<br class="">
Also the number of active "open" states can also be watched.<br class="">
<br class="">
So the OS services also come to play.<br class="">
<div class="elided-text"><br class=""></div></blockquote></div></div></div></div></div></blockquote><br class=""></div><div>I do suggest additional randomization in my Rock Salt talk ( <a href="https://www.researchgate.net/project/Rock-Salt" class="">https://www.researchgate.net/project/Rock-Salt</a> ), but I was trying to keep this simple for a transitional application. I envision the large file of pseudo-hash values to be kept in an isolated server, with only a restricted connection to the log in servers, a security appliance much like a HSM. Thus there would be no path from the internal or external network to the large file other than fixed format requests from the login server on a dedicated channel. I don’t see how this offers less security than conventional access controls.</div><div><br class=""></div><div>Arnold Reinhold</div><div class=""><br class=""></div></body></html>