Comment by xoa | Hacker News Reader

Comment by xoa | Hacker News Reader

Parent Full thread

>Why is pixelation preferable to a big black obliterating box?

From a security perspective it has zero advantages, but I guess some people like the aesthetics?

>To me, it seems like a lot of wasted time and effort and potential arms race between encoders and decoders and the risk of being exposed when you could just put a big black box over whatever you wish to obscure.

There doesn't need to be an arms race, one can just erase whatever needed to be hid, put fake random text over it and then pixelate that. Ie., a prettier "black box" but still the same core method as a black box. In principle doesn't even need to be any more work, it'd be easy enough to throw together a simple "pixelate erase" script that'd take a selection, apply average solid color and random text over it, then pixelate the result all in one automatated step.

The problem is if some people think any modification of the original information is ever good enough. Anything based on the original could leak information, so need to erase and then apply any desired aesthetics afterward.

Yep, just replace the original password for "password" and pixelate that, if it really must look like a real password. And make sure to never use "password" as a real password, but that's a different level of shooting oneself in the foot.

Or better yet, embed easter-eggs. Possibly insults to the people prying into your secrets, or possibly alternative announcements.

Or better yet, put "Itriedtodepixelizeyourpassword".

"Depix Error: Please report on GitHub"

"All Depix users are reported to the FBI."

"x is not in the depixers file. This incident will be reported."

https://xkcd.com/838/

Be sure to drink your ovaltine

Maybe replace it with a black strip and pixelate that

Why pixelate something that isn't real password?

To make it look like it was a password. Only people who depixelate it will notice what the actual string is.

I think this whole pixelation thing is just for making it look nice. I, personally, would just use something like asterisks without any pixelation.

> replace the original password for "password" and pixelate that, if it really must look like a real password

Or replace the original password for "password" and leave it at that.

> take a selection, apply average solid color and random text over it, then pixelate the result

Averaging the color leaks information. To avoid leaking info, destroy the pixels as the first step. Get colors from outside the selection.

What useful information could solid color and random text leak even if depixelized? I assume the average solid color is just so the new pixelized region doesn't stand out against the rest of the non-pixelized ones, being an average color.

Applying it to an HN comment the result would be a solid average of #F6F6EF (beige background) and #290027 (text), so a solid darker beige with some random black text over, all pixelized. How can any of this be used to recover the original text?

In principle it leaks information, so is always worse practice than not leaking. For example, one could imagine an edge-case where given a set of average-colour password images collected over time, for a password field that has a dynamic in its presentation that is exposed in the averaging, useful information could be discerned and used to supplement other attack vectors.

Say for example, the password field had one of those password strength colour indicators that subtly changed the background or font colour to indicate password strength, and the images were captured and obfuscated at that point. Information useful to an attacker would now be embedded in the colour average.

It could speed up bruteforce attacks. Imagine a targeted attack having both an "average color" of the rendered password, produced by known background and foreground colors and a known typeface and also having a strong cryptographic hash of the password, where the hash takes for example ~0.1s to calculate.

The attacker then before trying to hash a candidate password they can first calculate the average color of it to check if it even remotely matches, which can be much faster than the hash function.

Average color could be a rough predictor of password length too, depending on circumstances.

Ok, maybe I had a different interpretation of the scenario OP presented. I read the "solid block of average color" as simply an average of 2 colors, not a weighted average. So black text on white background would always result in rgb(128,128,128) (#808080) regardless of how many pixels of each color you had in the block. The only things that leaks are the color of the background and of the text but these are already known from the surrounding parts.

This makes sense for purely aesthetic reasons because the pixelized block will not stand out against the combination of background + text around it. A white page with black text would have a gray fuzzy area where it's pixelized.

If a weighted average is used and you can determine the fill factor of the text inside the box that would be some information leakage, as small as it may be.

Reply on news.ycombinator.com