Hacker News Reader

Comment by bennettfeely | Hacker News Reader

This doesn't actually work, the value attribute of the input doesn't change as a user types something.

With that said, I still think there is a a big discovery yet to be made with browsers leaking users' history via the :visited selector. Only a few CSS properties can be set with it (all related to color). But if there was a way to detect the color difference or timing of the painting that would be a big deal.

Possibilities might be with mix-blend-mode, @property, or applying "slow" css properties like a blurry text-shadow dozens of times. I've played around with this a little but haven't found a crack yet.

View on HN

How about an extremely slow to render zalgo text, switching between opacity 0 and 1 depending on visited?

Nice idea. I just tried it - looks like alpha is ignored for colors specified in ::visited and the alpha of the non-visited color is always used.

well then, use white-on-white vs black-on-white, with subpixel rendering enabled and zalgo text this should still have a measurable performance impact

It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.

I’m confused. Are you saying a website might actually spit out your current password or what you had just entered when attempting to change it? The former should never, ever be the case; the latter shouldn’t be the case, although it does happen from time to time.

Attack scenario would be a website loading CSS that is controllable by someone malicious. This could be due to ad code or custom themes for part of the site. That CSS would include selectors that would trigger different remote image requests for different partial matches on the value of the input. Based upon what remote URLs were triggered, one could reconstruct all or part of a password.

But I get your point. The website should not know the plaintext of your password for an overlap check unless their security practices are really bad. And if they are that bad, hopefully it is a throwaway password anyway. A duplicate check could still be done with hashes, but partial hash leaks are NBD.

Personally, I've had this happen though on password change prompts, which makes me think that the website is storing the value I just entered temporarily in the session. That's still bad even if it isn't being persisted beyond that page post though.

They could store the hashes of all the prefixes of the password and send them to the client. It's almost as bad as sending the password, because it's easy to brute force the cleartext.

Please don't be evil. I use the visited feature every single day, and I would be pissed if browsers had to disable it because some jagoff hacked it.

Reply on news.ycombinator.com