Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crypto Anchors: Exfiltration Resistant Infrastructure

diogomonica.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#21

Post by tptacek »

bigmac wrote: post #19
tptacek wrote: post #9

I am ambivalent about using HSMs to protect password databases, because if you're going to do that, you might as well simply introduce a minimalized authentication server (ie: something with an interface). It'll have approximately the same attack surface, it actually helps your architecture in other ways, and it precludes attackers from getting hashes in the first place (at least, the same way an HSM does with the HM…

This isn't only about HSMs or dedicated services. To anyone reading this thread: the key thing to understand here is: How do crypto-anchors help against attacks that allows `select *` from a database? A: Per-record encryption mediated by a dedicated microservice.

But there's really nothing "cryptographic" about an isolated authentication service. To drive the point home, and don't do this, but if you (1) used dedicated hardware to run it, (2) IP filtered the box down to just HTTPS, and (3) ran the service using Go, Rust, or Java Servlets, you probably wouldn't even need to use a good password hash.

I'm only talking about the AuthN problem, by the way. I'm not making a general argument against circuit breaker architectures.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#22

Post by bigmac »

tptacek wrote: post #21
bigmac wrote: post #19

Earlier quoted context omitted.

This isn't only about HSMs or dedicated services. To anyone reading this thread: the key thing to understand here is: How do crypto-anchors help against attacks that allows `select *` from a database? A: Per-record encryption mediated by a dedicated microservice.

But there's really nothing "cryptographic" about an isolated authentication service. To drive the point home, and don't do this , but if you (1) used dedicated hardware to run it, (2) IP filtered the box down to just HTTPS, and (3) ran the service using Go, Rust, or Java Servlets, you probably wouldn't even need to use a good password hash . I'm only talking about the AuthN problem, by the way. I'm not making a gener…

Folks need to worry about being able to protect more than just passwords. Engineers should be doing a good job of protecting SSNs, phone numbers, home addresses, etc. Crypto-anchoring can help for the general case of protecting sensitive information, not just passwords. `select *` shouldn't give anything in your infrastructure bulk access to sensitive information. The 'cryptographic' thing here is per-record encryption.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#23

Post by tptacek »

bigmac wrote: post #22
tptacek wrote: post #21

Earlier quoted context omitted.

But there's really nothing "cryptographic" about an isolated authentication service. To drive the point home, and don't do this , but if you (1) used dedicated hardware to run it, (2) IP filtered the box down to just HTTPS, and (3) ran the service using Go, Rust, or Java Servlets, you probably wouldn't even need to use a good password hash . I'm only talking about the AuthN problem, by the way. I'm not making a gener…

Folks need to worry about being able to protect more than just passwords. Engineers should be doing a good job of protecting SSNs, phone numbers, home addresses, etc. Crypto-anchoring can help for the general case of protecting sensitive information, not just passwords. `select *` shouldn't give anything in your infrastructure bulk access to sensitive information. The 'cryptographic' thing here is per-record encrypti…

I think tokenizing services are a very good idea in general. I just think there are easier and more effective ways to handle the AuthN problem.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#24

Post by ericb »

tptacek wrote: post #14
diogomonicapt wrote: post #11

Earlier quoted context omitted.

Don't disagree; I think what I actually tried to argue for was doing both: segregate data access to a new, minimal, service that also requires a key in an HSM to operate.

Given a servlet-only Java AuthN server with no interface other than "Authenticate", what is the likely attack that the AuthN server falls to but the HSM doesn't? From what I can tell, both the HSM and the Java servlet app have really just one major weak point, and it's shared: the management interface.

I may be reinventing something that is already done here, but it occurs to me you could also put canary accounts in your data (say one every 100 entries) and use it as a tripwire to alert ops the moment one is passed to the auth service.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#25

Post by jondubois »

The thing about security is that there is a point where you end up locking yourself out.

Locking your data to your hardware raises the question of what would happen if the hardware failed? Also at first glance this seems to introduce difficulties with scalability across multiple machines. Also it might make it difficult to switch between infrastructure providers.

The cost of this approach should be mentioned as a footnote.

Maybe the better solution is for society to support more small tech companies with smaller user bases that have fewer dissatisfied rogue employees to leak hashed passwords in the first place.

The root of the problem is not technical, it's political.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#26

Post by flipp3r »

zaroth wrote: post #5

Another form of "crypto anchor" is Blind Hashing which uses a large pool of random data to defend the hashes. An attacker would need to exfiltrate over 90% of the data before they could run an offline attack on hashes blinded by the data pool. The bigger the data pool, the more data an attacker would have to steal, and the more hashes/sec you can run. So while iterative/computational hashing is only secure if it is s…

This looks like a pretty good technique, that's coming from someone who has collected 240GB+ of user:password dumps.

I certainly wouldn't get 16TB of disks just for that if it were ever leaked.

Bummer(not for me :p) that you guys went the route of patenting it and keeping it proprietary & only available through an API.

I think it would be adopted in no time if it were open source, and I'd definitely like to see something like this available as a service on clouds like GCP/AWS/Azure/etc for my day job.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#27

Post by mcpherrinm »

jondubois wrote: post #25

The thing about security is that there is a point where you end up locking yourself out. Locking your data to your hardware raises the question of what would happen if the hardware failed? Also at first glance this seems to introduce difficulties with scalability across multiple machines. Also it might make it difficult to switch between infrastructure providers. The cost of this approach should be mentioned as a foo…

HSMs all have a way of enrolling multiple units into a shared state so that you can have them all be logically equivalent.

If possible, it's nice to keep an offline copy of your key material too. Maybe locked in a safe, gpg encrypted or something.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#28

Post by matt_wulfeck »

Personally, I think our current trend is very useful and should be pursued to the most extreme level:

1. Assume that attacker will get data X

2. Make what you keep in data X as useless and uninteresting as possible.

3. Hash data X with the most expensive and safest hash possible.

4. If you really can't do steps #2 and #3, warn your customers about what you are keeping and encrypt the heck out of everything.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#29

Post by hackcasual »

tptacek wrote: post #14
diogomonicapt wrote: post #11

Earlier quoted context omitted.

Don't disagree; I think what I actually tried to argue for was doing both: segregate data access to a new, minimal, service that also requires a key in an HSM to operate.

Given a servlet-only Java AuthN server with no interface other than "Authenticate", what is the likely attack that the AuthN server falls to but the HSM doesn't? From what I can tell, both the HSM and the Java servlet app have really just one major weak point, and it's shared: the management interface.

I've gone with this approach for a niche social networking site I'm building. The biggest benefit an HSM provides is vendor wrapped keys, which does simplify key management and allows you to lean more on your vendor to support key material confidentially. In my case I didn't feel the added cost and complexity was worth it.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#30

Post by jnwatson »

Cieplak wrote: post #20

If you're serious about preventing exfiltration, you'll do what the military does and use data diodes https://en.wikipedia.org/wiki/Unidirectional_network On a slightly tangent, people with physical access to a server can extract encryption keys from RAM by plugging into a PCI slot: https://github.com/ufrisk/pcileech

I've used data diodes. It isn't clear to me what is the high side in this case.
Post reply on HN