Hacker News Reader

Comment by miki123211 | Hacker News Reader

It would be cool if it was possible to read the data not just by the ID, but also by the hash of the ID.

That would let us serve stuff like version information and links to the latest version, without the fear that somebody is going to reverse engineer our app and replace the data with something malicious.

We, as the app author, would have the full key, so we could read and write, whereas users would have nothing but the hash.

View on HN

That's a cool idea, I'd definitely like to add the ability to create a little store with more safety, and that totally works with the goal of simplicity. I'll give it a shot.

It's a cool idea, but the old anti-pattern about security through obscurity applies.

I never really understood this argument, obscurity add an obvious layer of protection, not impenetrable of course, but still valid. Why is this different than an API key for example?

Security through obscurity refers to relying upon keeping the details of the security mechanism secret. An API key itself is a secret, but the mechanism for how that key is generated and used is public knowledge.

In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.

If compromised, you can change an API key. The key is like a password, and keeping that secret is important.

Where the "obscurity" aspect comes in, as an example, can be through the mechanism used to generate and validate that key.

Let's say you decide you don't want to or can't store the keys, and don't want a full pki system (public/private keys or certificates), so go with: sha256(clientid + userid + "hardcoded secret"). Your security now 100% relies on no one knowing that algorithm. If someone figures it out, you need to release a new version of your software, invalidate ALL API keys, and for that effort you still haven't done anything to prevent the same thing happening again.

A good test of this is: if someone has your source code, can they break your security mechanism? If yes, you're probably relying on security though obscurity. By contrast, if you're using asymmetric encryption to generate keys, it doesn't matter if someone knows that: if they don't have the private key, they can't do anything. (This leaves aside the issue of storing your private key or other secrets in source code, but I'd describe that as an operational failure rather than a fundamental design problem).

If a cryptographic hash function is used, the security of this scheme doesn't rely on keeping the algorithm secret, though. Therefore, it's not security through obscurity. Of course, weaknesses could still exist (e. g. a too small input space because the ID that is hashed has too little entropy).

People get this wrong a lot.

Security only through obscurity is no security at all. The argument was generally made in the context of secret, proprietary encryption algorithms. In this context, it was frequently true - security reduced to reverse engineering.

But security isn't a thing. It is a property of a system. And many secure systems strategically employ obscurity for multiple purposes.

Reciting a mantra is a poor substitute for carefully considering your problem domain.

Right, but in the context of this application, there is NO OTHER security except the obscurity of the UUID or it’s hash. The mantra applies quite well here since an attacker could stumble upon a valid hash or UUID and then change the data.

The attacker could stumble upon a valid hash like they could stumble upon a valid password.

It is done, lmk if it works alright. The read only hashes should be visible beneath the data editing view on a new one.

Adding it to the homepage would be cool too ^^

How would you phrase it?

"write only link here"?

I really wanna keep the basic information visible and am not sure about about adding another line

i meant under "Access your data with:" something like "Or read old link:"

but you're right it can be discovered

Reply on news.ycombinator.com