[Cryptography] encrypting bcrypt hashes

[Arnold Reinhold]

> On Mar 14, 2017, at 7:07 AM, Mark Steward <marksteward at gmail.com> wrote:
> 
> 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.
> 
> You also still need to salt or pepper, as permuting doesn't hide frequencies.
> 
> 
> Mark
> 
> 
> On 14 Mar 2017 04:24, "Tom Mitchell" <mitch at niftyegg.com <mailto:mitch at niftyegg.com>> wrote:
> On Mon, Mar 13, 2017 at 1:58 AM, Robin Wood <robin at digininja.org <mailto:robin at digininja.org>> wrote:
> >
> ....
> >>
> >> Again the security depends on the difficulty of exfiltrating such a large
> >> data set, not on a short key that that is relatively easy to steal.
> >
> 
> Also a single file would be opened by a very short list of processes.
> Access control lists apply.  Even advisory access control can be used to
> trigger alerts.
> 
> Also the number of active "open" states can also be watched.
> 
> So the OS services also come to play.
> 

I do suggest additional randomization in my Rock Salt talk ( https://www.researchgate.net/project/Rock-Salt ), 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.

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170315/012e57b3/attachment.html>