Hacker News Reader

Comment by londons_explore | Hacker News Reader

This type of security is bad. Either something should be possible, and easy for anyone to do... Or it should not be possible, and protected by real cryptography.

Hiding something with ROT-13 just 'so it doesn't show up in grep' is a bad idea.

View on HN

Security isn’t a binary ecosystem. There’s varying degrees of criteria. Performance, functionality, as well as acceptable level of risk.

True, but this is "we put a big padlock picture so everyone thought it was secure" levels of security. That is just deceptive.

Isn’t this normally stored on an encrypted volume anyway? If the user cares about security even in the slightest, they’d be using FileVault, of course

So really, this type of encryption is defeating scanning/probing, not a dedicated attacker who knows where to look and why. In such cases the attacker is worried about gaining access to the walled garden first — where the protections are.

Filtering out amateurs seems to be a reasonable goal.

I think this is more like putting a lock on your door. It won't deter a locksmith or a dedicated attacker, it just filters out the low effort attackers.

Putting a lock on your door but also putting the key under your door mat.

Yeah, that's a thing people do.

I'd compare it to non-encrypted and signed pagestate in ASP.net or JSP, it works but it's completely untrustworthy. IMO this shouldn't be hard for apple to solve either, they can just create a key in keychain and use that to sign the file using the existing and standardized XML signing algorithm. That way any change to the file, even the XML will cause it to get discarded.

No, not really - fundamentally broken things like this one are worse than useless, because they degrade security by making it harder to understand the situation.

Respectfully, why would there be any valid use case for understanding the private format stored by this DB? In ideal circumstances it is private, is it not?

I don't mean understanding the database format; I'm talking about understanding the security model.

I actually think something like ROT-13 is fine in applications where obscuring it from humans is all you care about. It's serving the same purpose as the "Staff only" sign on that door in the restaurant. Does it somehow prevent you entering without an employment agreement? Would it stop a robber or thief? Nope. But since there's a sign you know that's the wrong way and will stay out of where you aren't wanted.

AES looks like security, ROT-13 is clearly not security, so there's no illusion.

Suppose a maintenance programmer is looking at logs around a weird issue, scrolling through hundreds of entries they happen to notice that the phase "FuckDonaldTrump" appears in the logs - huh, what? Oh, it's the password for the administrator user. Well, the way human memories work that password is stuck in their head now. They didn't try to learn the admin password but now they know it, whereas if the log said "ShpxQbanyqGehzc" well even though that's the "same" information your brain doesn't retain it automatically because it doesn't mean anything.

They're not trying to learn the admin password, and with ROT-13 they are less likely to accidentally do so, that's actually a benefit.

If data is to be used locally, it has to be encryptable and decryptable locally with just resources accessible locally, so it's pretty much not secureable from local software.

You can still secure things with local keys managed in eg. a keychain that checks the identity/entitlements/permissions of the caller before giving out the keys.

That just translates to a slightly longer exploit chain in practice. It's not a fundamental obsatacle.

A safe can be opened, so should safes not have doors?

It is often good to leave keys right next to a locked lock.

Reply on news.ycombinator.com