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

A tool for recovering passwords from pixelized screenshots

github.com

Post reply on HN
Print view View original

101–110 of 130 posts

Re: A tool for recovering passwords from pixelized screenshots

#101

Post by oehtXRwMkIs »

nyanpasu64 wrote: post #85
manceraio wrote: post #47

Earlier quoted context omitted.

What about that bitcoin wallet that was blurred on TV and they managed to reverse engineer it? Cannot find source.

https://www.bbc.com/news/technology-41737248 > Two French hackers used their computer skills to reconstruct a blurred-out code on TV and claim bitcoins worth $1,000 (£760).

Funny they say bitcoins when 1 bitcoin was at least $1000 back then. I'm pretty sure the usual grammar rules apply so you can't use the plural unless you have at least 2 bitcoins. Super minor but interesting how a vastly deflated currency that is super divisible can mess with our usual language.

Re: A tool for recovering passwords from pixelized screenshots

#105

Post by tpoacher »

tpoacher wrote: post #50
diebeforei485 wrote: post #10

Earlier quoted context omitted.

This reminds of the Markup tool[1] on iPhone. People use it to redact from screenshots, but it was (is?) actually slightly transparent by default. [1] https://9to5mac.com/2018/03/13/ios-markup-reveal-redact-sens...

one of the "underhanded c" contest winners many years ago was an entry for a redaction tool, which drew black boxes on an image in such a way that the software developer could later effectively recover the redacted information easily, while still being able to claim plausible deniability. The trick was that it worked by producing a ppm file where pixels with single digits would become zeros, but double digits would b…

Here is the link if anyone's interested: http://notanumber.net/archives/54/underhanded-c-the-leaky-re...

Re: A tool for recovering passwords from pixelized screenshots

#106

Post by steerablesafe »

buran77 wrote: post #95
mleonhard wrote: post #69

Earlier quoted context omitted.

> 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 pixe…

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.

Re: A tool for recovering passwords from pixelized screenshots

#107

Post by buran77 »

steerablesafe wrote: post #106
buran77 wrote: post #95

Earlier quoted context omitted.

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 pixe…

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…

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.

Re: A tool for recovering passwords from pixelized screenshots

#108

Post by whatch »

pvorb wrote: post #40
xoa wrote: post #7

Earlier quoted context omitted.

> 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 ca…

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.

Why pixelate something that isn't real password?

Re: A tool for recovering passwords from pixelized screenshots

#109

Post by pvorb »

whatch wrote: post #108
pvorb wrote: post #40

Earlier quoted context omitted.

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.

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.

Re: A tool for recovering passwords from pixelized screenshots

#110

Post by KineticLensman »

davchana wrote: post #19
xorcist wrote: post #17

Earlier quoted context omitted.

There is still a risk to leak the length of the password. If the font is known and the size of the rendered text can be inferred that would limit the search space considerably.

Personal Snippet, if I want to hide/cross something I wrote on paper, I usually change letters to something else, like u to g, i to d, nothing preplanned, whatever comes in mind, before I cross line the text in forward slashes, backword slashes, & in horizontal lines.

I sometimes write down on paper my banking passphrase (from which the bank makes me select letters at specific position). Afterwards I overwrite it a few times with the alphabet and a few numbers and other random letters. It's totally unreadable.
Post reply on HN